The idea of writing automation in plain English — the way you'd write a Google Doc SOP — and having it actually execute is no longer a pipe dream. It's where AI tooling is right now, today, and it's changing how marketers, ops teams, and solo business owners think about workflow automation entirely. If you've been watching the Reddit threads light up around this topic, you already sense the shift. Here's what's actually happening, what works, and how to build something real with it.
A common question in the r/ChatGPT community right now revolves around a deceptively simple idea: what if you could write your automation steps in plain English — like a normal SOP you'd hand to a new employee — and have an AI agent execute them, step by step, visibly, in real time?
That's the core of what's being discussed. The framing matters a lot here. Traditional workflow automation tools (Zapier, Make, n8n) require you to think in nodes, triggers, and data mappings from day one. That's a meaningful cognitive barrier. The new paradigm being explored flips that: you describe what you want done in natural language first, and then either the AI interprets and runs it, or a translation layer maps your prose steps to executable actions.
Think of it like this: instead of building a Zap from scratch, you write:
That's an SOP. And increasingly, that SOP can become the automation — not just documentation of it.
Let's be honest about where things stand. The tooling is maturing fast, but it's not uniform. Here's a practical breakdown of what's available right now:
| Tool / Approach | Plain English Input? | Executes Steps? | Shows Live Progress? | Best For |
|---|---|---|---|---|
| ChatGPT + Custom GPTs | Yes | Partial (via Actions) | Partial | Drafting, research, light API calls |
| Claude (Anthropic) | Yes | Yes (with tool use) | Yes (streaming) | Agentic tasks, multi-step reasoning |
| n8n + AI node | Somewhat | Yes | Yes | Technical teams wanting visual + AI hybrid |
| Make (Integromat) | Limited | Yes | Yes | Non-technical users, established integrations |
| Custom Agents (API) | Yes | Yes | Depends on build | Production-grade, domain-specific automation |
The honest truth: if you want the closest thing to "write steps in plain English and watch them execute inline," you're currently looking at building with Claude's tool-use API, or using a platform like n8n that has added AI-powered step generation. Neither is plug-and-play for non-developers yet — but the ceiling is higher than most people realize.
Here's a methodology that works, drawn from actually building production agents like Buddy (our open-source Google Ads agent). The pattern applies whether you're automating ad account management, lead routing, or internal ops.
Before touching any tool, write your workflow as a Google Doc. Be specific. Include:
This document becomes your agent's system prompt skeleton. It's not wasted work — it is the work.
Not every step needs AI reasoning. Some steps are pure deterministic actions — "send email," "update CRM field," "pull report." Others genuinely benefit from language model judgment — "write a personalized follow-up based on lead's industry," "flag anomalies in this data," "decide whether this lead qualifies."
Map your SOP steps into two columns:
Over-relying on the LLM for every step is a common trap that adds latency and cost without benefit.
You have a real choice to make here, and it depends on your technical comfort and production requirements:
One of the most underrated parts of the Reddit discussion around this workflow style is the emphasis on watching steps execute in real time. This isn't just a nice UX feature — it's operationally important. If your agent is doing 12 steps and fails on step 9, you need to know exactly what happened at each prior step.
For production agents, build in:
In Buddy, we surface step execution status directly so that anyone running an account audit can see exactly what the agent checked, in what order, and what it found — before it makes any recommendations. This transparency is what makes agents trustworthy in a business context.
Let me ground this in concrete use cases from the marketing and advertising world, because that's where I've seen the most ROI from this approach.
The SOP for a manual account audit might be 15–20 steps: check campaign budgets, review impression share, flag keywords with high spend and low conversions, check Quality Scores, review ad copy performance, identify structural issues. Written as a plain-English doc, this becomes a system prompt. The agent calls the Google Ads API at each relevant step, runs analysis, and surfaces findings — in <5 minutes versus the 2–3 hours a manual audit takes. This is exactly the workflow Buddy executes.
SOP: New form submission comes in → enrich with Clearbit or Apollo → score based on ICP criteria → if score >70, route to AE Slack channel and create HubSpot deal → if 40–70, enroll in nurture sequence → if <40, tag as low-priority. This maps cleanly to a tool-use agent: enrichment API call, scoring logic (LLM or rules-based), CRM API calls, Slack webhook. Fully automatable with plain-English-to-execution tooling today.
Every marketing ops team has a reporting SOP buried in someone's brain. Extract it to a doc, build it as an agent: pull data from GA4, Google Ads, and HubSpot → calculate week-over-week changes → flag anything outside normal ranges → generate a plain-English summary → send to Slack or email. Teams that have built this report saving 3–5 hours per week of analyst time, consistently.
As practitioners often discuss, the gap between "demo impressive" and "production reliable" is real. Here's what to watch for:
LLMs can confidently make the wrong call at a decision branch, especially when the context window gets large or the instructions are ambiguous. Mitigation: be extremely explicit in your SOP about decision criteria. Don't write "if the lead looks qualified" — write "if the lead's company has >50 employees AND is in SaaS or eCommerce AND has filled out the budget field with a value >$5,000/month, route to AE." Specificity is your safety net.
APIs fail. Rate limits hit. Fields are null. Your agent needs to handle these gracefully — retry logic, fallback behaviors, and alerting when a step fails. Most demo-level agents don't include this. Production agents must.
Running a 15-step agent with Claude Sonnet or GPT-4o across 500 leads per day adds up fast. Profile your token usage per workflow run early. In practice, well-optimized agents with selective LLM use (only reasoning steps) run for $0.02–0.08 per workflow execution on most marketing use cases. Naïve implementations can run 10x higher.
If your workflow spans more than a few minutes or involves waiting for external events (e.g., "wait for email reply before next step"), you need persistent state. Simple agent loops don't handle this well. Look at durable execution frameworks like Temporal or Inngest if your workflows have this pattern.
The part of this Reddit thread that resonates most with me professionally is the emphasis on watching automation run live, step by step. This isn't just a developer debugging feature — it fundamentally changes the trust dynamic between teams and their automation.
When a marketing manager can see that the agent checked campaign budgets (✓), reviewed keyword performance (✓), flagged 3 keywords with CPA >2x target (✓), and then drafted recommendations — they're not just accepting a black-box output. They're validating a transparent process. That's the difference between automation that gets overridden because "I don't trust what it did" and automation that gets acted on because the reasoning is visible.
For anyone building agents for clients or internal stakeholders: invest in the UI/UX of execution visibility. It's not overhead — it's adoption strategy.
If this resonated and you want to move from concept to working automation, here's your concrete path forward:
The Google Docs–style automation paradigm is genuinely exciting because it closes the gap between "people who know what should happen" and "people who can make it happen automatically." That gap has traditionally required a developer or a no-code specialist as an intermediary. Increasingly, it just requires a well-written SOP and the right execution layer. That's a meaningful shift — and it's happening right now.