Hlib Storchak · 2026-07-15 · ~11 min readQuick answer
Add AI agents in three layers, data and signal, workflow logic, human judgment, and only move a workflow up a layer once it clears a gate: it works reliably by hand, then it works with a human reviewing every output, then it has earned the right to run with less supervision. Skipping straight to an autonomous agent on an unproven workflow is the single most common way these rollouts fail.
Why "just add an agent" breaks GTM stacks
Most GTM teams add their first AI agent the same way they added their first Zapier flow: someone finds a demo that looks good, wires it into whatever tool is nearest, and hopes it holds. That works for a low-stakes automation. It does not work for something that drafts outbound copy, scores leads, or writes to a CRM, because the failure mode is not "the zap stopped running." It is "the agent kept running, confidently, on bad inputs, for three weeks before anyone noticed."
I have watched this pattern often enough with clients that I stopped treating it as an execution problem and started treating it as a sequencing problem. The agent itself is rarely the issue. The issue is which workflow got automated first, and whether anyone checked it was solid before removing the human from it. This framework is the sequencing I actually use.
The framework at a glance
The framework has two axes. Three layers describe what an agent is doing. Three gates describe how much you trust it to do that thing without a person checking every output. A workflow moves right across the gates only after it has proven itself at the layer it currently sits in.
| Layer | What it does | Typical GTM examples |
|---|---|---|
| 1. Data and signal | Reads and enriches, no writes | Lead research, intent scoring, account summaries |
| 2. Workflow logic | Drafts and proposes, human approves | Sequence drafting, reply triage, list segmentation |
| 3. Judgment and escalation | Executes with defined limits, humans handle exceptions | Sending, CRM writes, meeting booking |
A team building its first internal GTM tool this way, whether with a packaged AI SDR platform or a coding agent like Claude Code wired into a CRM, tends to end up with something that survives contact with a real quarter. A team that starts at Layer 3 because that is what the demo showed usually ends up quietly turning the agent off within two months, then blaming the category rather than the sequence.
Layer 1: data and signal
This layer only reads. It pulls firmographic data, summarizes a call, scores a lead against your ICP, or flags a buying signal. Nothing it produces touches a prospect or a rep's calendar without a person looking at it first. This is the correct place to start for one simple reason: the cost of a wrong answer is a wasted look, not a bad email or a burned domain.
Most teams underrate how much value sits here. A research agent that reliably turns "20 target accounts" into "20 one-paragraph briefs with the right buying signal surfaced" saves real hours even if it never sends anything. It is also the cheapest place to learn your agent's actual error rate before you let it touch anything riskier.
Layer 2: workflow logic
This layer drafts. It proposes a sequence, triages a reply into "interested, not now, or wrong person," or segments a list by signal strength. A human still approves before anything goes out, but the agent is now doing the thinking, not just the fetching. This is where most of the actual time savings live, and it is also where most of the edge cases you will ever see start showing up, wrong triage calls, a segmentation rule that does not generalize, a draft that reads well but gets a fact wrong.
Why this layer matters most. Every edge case a workflow will ever throw tends to show up here first, while a human is still in the loop to catch it. Skip this layer and those same edge cases show up in Layer 3 instead, in production, unsupervised.
Layer 3: human judgment and escalation
This is the only layer where an agent executes without a human checking every individual output. Sending a sequence, writing a qualified lead to the CRM, booking a meeting. Getting here is not about the agent being smart enough. It is about the workflow having a low enough and well-understood enough error rate that letting it run unsupervised, inside defined limits, is a smaller risk than the cost of keeping a human in every loop. Escalation rules still route anything outside those limits, an unusual reply, a large account, a compliance-sensitive vertical, back to a person.
Gate 1: prove the manual workflow first
Before any agent touches a workflow, it needs to already work when a person does it by hand, with a documented process and a result you would defend. Kevin Payne makes this point bluntly in his own GTM Stack Maturity Framework: "you can't AI your way out of bad processes, you can only accelerate them." His version of this gate sets a concrete bar, 90%+ adoption of the current tool and an 85%+ data quality score, before layering anything agentic on top. I don't hold every client to those exact numbers, but the principle transfers directly: an agent automating a broken workflow just produces bad output faster and with more confidence than the human version did.
Gate 2: discovery before execution
Once the manual workflow is solid, the next gate is proving the agent's draft version at Layer 2, with a human reviewing every single output, for long enough to know the real error rate. Payne's framework again gives a useful marker here, around 50%+ daily usage by the team actually doing the work, alongside a documented list of the edge cases the agent hits. If reps are not using the drafts it produces, that is signal, not noise. Either the workflow is not actually helping or nobody explained why it should be trusted yet, and both are reasons to stay at this gate rather than push forward.
| Gate | What has to be true to pass | What passing looks like |
|---|---|---|
| 1. Manual proof | The workflow is solid and documented without an agent | High tool adoption, clean underlying data, a written process |
| 2. Supervised draft | The agent's Layer 2 output is reviewed and mostly accepted | Reps actually use the drafts, edge cases are logged, not surprising anymore |
| 3. Earned autonomy | Error rate and blast radius are both known and small | Logs show a stable pattern, escalation rules catch the exceptions that remain |
Gate 3: earn autonomy with logs, not vibes
The third gate is the one teams most often skip, because by this point the agent looks like it is working and the temptation is to just flip it to autonomous. Resist that. What actually justifies moving to Layer 3 is a log, not a feeling: a known volume of runs, a known acceptance or override rate from the humans who reviewed them, and a documented set of situations that reliably need escalation. If you cannot answer "what's our current error rate on this workflow, with a number" you are not ready to remove the review step, no matter how good the last ten outputs looked.
A worked example: lead research
Take a research agent that builds account briefs ahead of outbound. At Layer 1, Gate 1, it pulls firmographic and signal data into a brief format that a rep already trusts because they built the format themselves. At Gate 2, the agent starts drafting the "why now" line for each brief, and a person reviews every one for a few weeks, logging which drafts needed a real edit versus which were used as-is. At Gate 3, once the override rate on that "why now" line has been stable and low for long enough, the agent is trusted to draft it unsupervised for standard accounts, with anything above a size or industry threshold still routed to a person. Three months, not three days, and every step produced a number you could show someone before moving to the next one.
Signs you skipped a gate
A few tells show up reliably when a team jumped ahead. Reps quietly stop trusting the agent's output and start double-checking everything, which erases the time savings the tool was supposed to create. Nobody can answer what the agent's actual error rate is, because nobody was reviewing outputs closely enough at Gate 2 to know. And the workflow gets blamed as "AI doesn't work for this," when the real problem was giving it Layer 3 authority on a process that never passed Gate 1. Gartner's own 2025 forecast on this, cited in DevCommX's write-up on repeatable agentic AI practice, projects that over 40% of agentic AI projects will be cancelled before the end of 2027. Skipped gates are a large part of why that number is that high, not a limit of the technology itself.
Key takeaways
- Add agents in three layers: data and signal, workflow logic, then human judgment and escalation.
- A workflow only moves up a layer after it clears a gate: proven manually, then proven under supervision, then proven with logs.
- Most failed rollouts skipped straight to unsupervised execution on a workflow that was never proven at the layer below it.
- "What's our current error rate on this workflow" is the question that should gate every move to less supervision.
- The agent is rarely the actual problem. The sequencing usually is.
Where the Forge stack fits in this
I run this exact framework on my own stack, built around the Forge ecosystem, Salesforge for sequencing, Leadsforge for enrichment and list data, and Agent Frank for AI-led outreach execution. Agent Frank did not start at Layer 3. It started drafting sequences with a human reviewing every send, moved to supervised sending on a narrow segment, and only earned broader autonomy once the override rate on its drafts had been low and stable for a few full sprints. The Forge stack made that easier because the logging and review tooling needed for Gates 2 and 3 already exists inside it, but the gates themselves are not a Forge-specific idea. Any GTM stack, packaged or built with a coding agent, needs the same discipline or it hits the same 40%-cancellation odds Gartner is describing.
My take
The honest reason teams skip gates is that Gate 1 and Gate 2 are unglamorous. Nobody demos "we reviewed 200 drafts and logged the override rate" at an all-hands. They demo the autonomous version. But the autonomous version is the output of the boring work, not a substitute for it, and the teams I have watched succeed with AI agents in GTM are the ones willing to spend a quarter looking unimpressive before they look automated. If you are choosing between a packaged AI SDR platform and building your own with a coding agent, I go deeper on that specific decision in the build-vs-buy framework for GTM tooling in the AI era, but this sequencing question comes first regardless of which one you pick.
FAQ
What is the right first AI agent to add to a GTM stack?
Something at Layer 1, read-only research or enrichment, not something that sends or writes to your CRM. It has the lowest cost of a wrong answer and teaches you the agent's real error rate before anything riskier is on the table.
How long should each gate take?
Long enough to produce a real number, not a feeling. In practice that is usually weeks for Gate 1 documentation, several weeks of supervised review for Gate 2, and a full sprint or more of stable logs before Gate 3. Rushing any of these is the most common cause of a rollout that quietly gets turned off later.
What's the biggest reason agent rollouts fail?
Skipping straight to unsupervised execution on a workflow that was never proven manually or under supervision first. Gartner's 2025 forecast puts agentic AI project cancellation above 40% by the end of 2027, and skipped gates are a major driver of that number.
Do I need a coding agent like Claude Code, or can I use an off-the-shelf AI SDR platform?
Either can work. The three layers and three gates apply the same way to a packaged platform and to a custom build. Packaged tools tend to ship faster with governance built in, custom builds with a coding agent give you more control over exactly where each gate sits.
How does this framework relate to build vs buy?
They answer different questions. Build vs buy decides which tool does the work. This framework decides how much autonomy that tool has earned at any given point, regardless of whether it is a vendor's product or something you built yourself.