DEV Community: Sebastian Chedal

Anthropic’s Multi-Agent Blueprint: What Production Constraints Add

Sebastian Chedal — Mon, 11 May 2026 18:06:52 +0000

Anthropic’s engineering team published one of the cleanest write-ups available on how a multi-agent system actually works in practice. The post is about Claude Research, an orchestrator-subagent pattern built for breadth-first research. The architecture is optimized for a particular task class, and the price of admission is a roughly fifteenfold token cost compared to a chat conversation. That cost is the tradeoff the system makes on purpose.

Most production systems make different tradeoffs. They run under cost ceilings, accuracy SLAs, speed budgets, and error rates that the research context does not impose. The blueprint’s patterns travel — orchestrator delegation, parallel subagents, condensed-return artifacts, end-state evaluation — but the architecture that emerges from applying them under production pressure is rarely the architecture in the post. The choices look the same up close and different at the system level.

The blueprint is for breadth-first research, and the cost multiplier travels with it

Anthropic’s system is built for a specific kind of work: research where the question is large, the directions are independent, and the answer is worth a lot of tokens. The lead agent plans an approach, spins up subagents to explore in parallel, and reconciles their findings against citations. On Anthropic’s internal evaluation, a multi-agent setup with Claude Opus 4 as lead and Claude Sonnet 4 subagents outperformed single-agent Claude Opus 4 by 90.2%.

The number that matters more: multi-agent systems use about 15x more tokens than chat interactions. The cost multiplier is the price of admission to the architecture. If the task does not decompose into parallel directions, you pay it without earning it.

Anthropic is direct about the limit: “domains that require all agents to share the same context or involve many dependencies between agents are not a good fit for multi-agent systems today.” That is the boundary of where the architecture earns its keep. Tasks with tightly-coupled state, sequential dependencies, or shared mutable context will hit coordination overhead faster than they hit parallelism gains.

The first decision is whether the task is in the right shape for the pattern. If it is a research-style problem with independent directions, parallel subagents are doing real work. If it is a workflow with chained dependencies, a single agent or a deterministic pipeline with smaller agents inside it usually wins on cost and reliability.

Token budget, not prompt cleverness, is the dominant performance lever

Anthropic’s variance analysis is the more useful diagnostic. In their BrowseComp evaluation, token usage by itself explained 80% of performance variance. Tool-call count and model choice were the other two factors. Prompt phrasing, instruction style, and the things teams typically iterate on did not show up as primary drivers.

The implication is practical. When a single-agent system plateaus on a complex task, the first question is whether it is context-bound, not whether the prompt needs more polish. A polished prompt cannot exceed the model’s working context. A multi-agent system, with separate context windows for each subagent, can. That is the mechanism, more than better instruction-following or any cleverness in the orchestrator.

Multi-agent’s main contribution to performance is parallel reasoning across more aggregate context than a single agent can hold. If the task fits inside one agent’s effective working window, the multiplier is rarely worth it. If the task genuinely needs more context than one agent can hold and the directions are independent, parallelism earns the cost.

Orchestrator delegation is a four-part contract that prevents agentic drift

The orchestrator-subagent split looks simple from a diagram and gets complicated in practice. Anthropic’s contract for each subagent: an objective, an output format, guidance on which tools and sources to use, and clear task boundaries. Miss any of the four and the subagent drifts — not because the model is poorly behaved, but because the orchestrator did not specify enough for it to know what done looks like.

Effort-scaling is part of that contract. Anthropic’s prompts embed concrete rules: 1 agent for simple fact-finding, 2 to 4 subagents for direct comparisons, and more than 10 subagents for complex research. Without rules like these, the lead agent over-scales — spinning up subagents for problems a single call could answer — and the cost multiplier compounds against you.

Tool ergonomics is the other load-bearing piece. The contract is only as good as the tool surface it points to. Anthropic ran a tool-testing agent that exercised flawed MCP tool descriptions, identified the failure patterns, and rewrote the descriptions; future agents using the rewritten tools cut task completion time by 40%. The orchestrator’s instructions assume the tools they describe behave the way the descriptions claim. When tool descriptions are vague or misleading, every downstream agent pays the tax.

Order of operations: get the four-part contract right, embed effort-scaling rules in the orchestrator prompt, then audit your tool descriptions before iterating on anything else. The contract and the tools are upstream of every other lever.

Context handling is external-memory-first, not bigger-context-first

The instinct on context limits is usually to ask for a larger window. Anthropic’s architecture does the opposite. The lead researcher saves its plan to memory before context fills, because past 200,000 tokens the context window can be truncated and the plan needs to survive. The architectural choice is to externalize early, not to chase larger windows.

The artifact pattern earns its place here. Instead of subagents reporting findings back through chat-style returns — long, lossy, expensive on lead-agent tokens — they write to a shared filesystem and return a lightweight reference. The lead agent does not re-read every detail; it gets a pointer and pulls what it needs. The pattern is not unique to Anthropic, but their post implies it through the memory system; practitioners across the industry have been naming it the artifact pattern because it solves a specific failure mode: the game of telephone, where information loses fidelity each time it passes from subagent to lead.

Fresh-context resets between sub-tasks are a deliberate design choice. If state lives outside the agents, the agents do not need to carry it in their context windows. “Bigger context” also stops being the answer to most context problems; the right move when an agent struggles with a long task is usually to externalize state and reset.

Evaluation grades outcomes, not the path the agent took

Evaluation is where multi-agent systems get the strangest. The path the agent takes through a complex task is rarely the path you would have prescribed in advance. Anthropic’s guidance: “judge whether agents achieved the right outcomes while also following a reasonable process.” Outcomes are graded; paths are observed but not required to match a template.

The mechanism most teams reach for is LLM-as-judge with a structured rubric — factual accuracy, citation accuracy, tool efficiency — producing a 0.0 to 1.0 score per output. The score does not substitute for human review; it scales review across thousands of runs without reading every trace by hand.

For state-mutating agents, end-state evaluation is the cleaner framing. Ignore the path entirely. Compare the final environment state to the goal state. Did the document get written, the ticket get closed, the file get moved? If yes, the agent succeeded — even if the trace looks meandering. Letting the agent iterate over its own process tends to produce better runs than prescribing the process up front, because the right path is often not knowable in advance.

Scoring is necessary but not sufficient. Production agents need traces, audit trails, and the ability to investigate a failure that scored well on the rubric but cost too much or used the wrong tool. The governance layer for production agents sits underneath evaluation, supplying the visibility scoring alone cannot provide.

Production constraints reshape the decisions the blueprint leaves to defaults

The blueprint and production part company here. Anthropic’s research context has no fixed daily cost ceiling, no hard accuracy SLA, no sub-second response budget, no error-rate threshold tied to revenue. Most production systems have at least one, often all four. The architecture decisions a team makes under those pressures are not the decisions the blueprint defaults to.

A few of the gaps the blueprint leaves to the reader:

Long-running state across sessions. The Claude Research system is session-bounded. A research run starts and finishes. Production agents often need to operate across days or weeks: a content pipeline that watches for new briefs, an operations agent that monitors a system continuously, an integration agent that processes events as they arrive. State across sessions is a different problem than state within one.
Failure cascades when a subagent fails mid-orchestration. The blueprint describes the happy path. Production has to handle a subagent that times out, returns malformed output, hits a rate limit, or fails its tool call. The lead agent needs to know whether to retry, fail over, partial-result, or abort the whole run, and that logic is not in the blueprint.
Multi-model pinning. Anthropic uses one model family throughout. Production teams often need a specific model version pinned for a specific job — partly for accuracy stability across runs, partly for cost control, partly because behavior changes between model versions can break workflows that depended on the old behavior.
Runaway-spend protection. The 15x cost multiplier compounds quickly when something misbehaves. A subagent that recursively spawns or a tool that returns oversized results can burn through a daily budget in minutes. The blueprint does not address circuit breakers, budget caps, or per-run cost ceilings.
Stateful resumption. When a long-running agent fails, restarting from scratch is wasteful. Checkpointing so the agent can resume from its last decision point, not its first, changes the cost economics of long jobs significantly. The blueprint mentions resumption in passing but does not treat it as a first-class architectural concern.

One example of how production pressures push toward different choices: in a content pipeline that runs autonomous agents end-to-end, fixed downstream crons were replaced with completion-triggered orchestration so that downstream stages fire the moment the previous stage finishes, instead of waiting for a scheduled tick. That is not a choice the blueprint suggests, because the blueprint is not session-spanning; production constraints make it obvious. Different pressures, different decisions.

The general pattern across these gaps: the blueprint optimizes for a single bounded run with a research outcome as the deliverable, while production systems usually optimize for repeated runs with reliability, predictable cost, and operational containment as the deliverables. Those are not opposing goals, but they push the architecture toward different shapes. A research system can afford to retry an entire run when something goes wrong; a production system that does that on every failure burns its budget and its SLA. A research system can afford to use the strongest available model throughout; a production system often pins a smaller model for the subagent tier because the cost difference compounds across thousands of calls per week.

Read the blueprint as a high-quality reference architecture for the task class it targets. Treat the patterns as primitives (orchestrator delegation, parallel subagents, condensed-return artifacts, end-state evaluation) and let the production constraints you are actually operating under decide how those primitives compose. The architecture lives in the composition, with each pattern earning its place in context.

When not to go multi-agent, and the question that comes first

Before “should I use a multi-agent architecture?” comes a different question: what job am I trying to remove from human supervision?

Multi-agent systems earn their keep when they reduce work; they fail when they multiply things to manage. A team running a single agent that already does its job well does not need a multi-agent architecture; it needs a clearer success metric and maybe a better tool surface. A team that has identified a research-shaped problem with independent directions and budget headroom for the cost multiplier is in the right place for the pattern.

A few heuristics for when single-agent or deterministic-workflow architectures are usually the right call:

Tightly-coupled context. If every agent needs the same shared state and changes propagate across the system, the coordination cost will exceed the parallelism gain.
Sequential dependencies. If step B requires step A’s output and step C requires step B’s output, you have a pipeline, not a parallel workload. A pipeline of small agents is usually simpler and cheaper than an orchestrator-subagent decomposition for the same work.
Deterministic workflow surface. If the steps are knowable in advance and the failure modes are predictable, a deterministic workflow with self-improvement scoped to skill optimization will be more reliable than a general-purpose agent picking between dozens of tools.
Insufficient budget for the cost multiplier. If the daily or per-run budget cannot absorb the token overhead, the architecture is the wrong tool for the budget.

For mid-market teams, complexity is its own failure mode. Every additional agent is another component to manage, debug, monitor, and pay for. Lower-order simple agents nested inside larger loops often produce better outcomes than a general-purpose multi-agent system trying to do everything. The mistake to avoid is adding agents because the architecture diagram looks impressive; the goal is to remove jobs from human supervision, never to create more agents for a human to supervise.

Sharper than “single or multi”: if I did not need to supervise this work, and the agent did it as well as or better than a person doing it today, what would that unlock? When the answer is concrete — a person freed up for higher-value work, a process that runs overnight, a backlog that clears without intervention — the architecture that earns its keep is the one that delivers that outcome with the fewest moving parts. The shape of the answer often points at where you are on the autonomy spectrum and what the next step is.

Anthropic’s blueprint documents one such point well. For any team adopting it, the work is to know which pressure the system is being built under, and to let that pressure shape the architecture that emerges. Same patterns, different production constraints, different decisions.

Frequently asked questions

What is Anthropic’s multi-agent research system?

Anthropic’s multi-agent research system, used in their Claude Research product, is an orchestrator-subagent architecture for breadth-first research. A lead agent plans the research approach and saves its plan to memory; it then spins up parallel subagents to explore independent directions, each with its own context window and tool access. Subagents return condensed findings, often via a shared memory store rather than long chat-style returns, and the lead agent reconciles them into a final answer with citations. On Anthropic’s internal evaluation, this setup outperformed a single Claude Opus 4 agent by 90.2% on their research eval.

What is the orchestrator-subagent (orchestrator-worker) pattern?

The orchestrator-subagent pattern, sometimes called orchestrator-worker, is a multi-agent design where one agent decomposes a task and delegates pieces of it to other agents. The orchestrator does not do the work itself; it plans, dispatches, and integrates results. Each subagent receives an objective, an output format, guidance on which tools and sources to use, and clear task boundaries. The pattern fits tasks that decompose naturally into independent directions and where parallel exploration is faster than sequential execution. It does not fit tasks with tightly-coupled context or heavy dependencies between subagents.

When should I use a multi-agent architecture vs. a single agent?

Use multi-agent when the task is breadth-first, the directions are independent, the aggregate context exceeds what a single agent can hold, and the budget can absorb the cost multiplier. Use single-agent when the task fits inside one context window, when steps are sequential, when the workflow is deterministic enough to specify, or when the budget is tight. The blueprint itself flags shared-context and high-dependency domains as poor fits for multi-agent. Most production tasks land closer to single-agent or deterministic-pipeline shapes than to research-style multi-agent shapes.

How does Anthropic’s multi-agent system handle context limits?

Anthropic’s system handles context limits by externalizing state to memory rather than chasing larger context windows. The lead researcher saves its plan to memory before context fills, because the context window can be truncated past a certain length. Subagents write findings to a shared filesystem and return lightweight references — the artifact pattern — so the lead agent does not re-read every detail through chat-style returns. Fresh-context resets between sub-tasks are part of the same strategy: state lives outside the agents, so agents can reset without losing it.

How much more expensive is a multi-agent system than a single agent?

Anthropic reports that multi-agent systems use roughly 15x more tokens than a chat conversation on the same surface task. The multiplier is the cost of running parallel subagents with their own context windows and tool calls. If the task is breadth-first and decomposes into independent directions, the multiplier buys parallelism that exceeds a single context window. If the task does not decompose, you pay the multiplier without earning it. Production teams often add cost circuit breakers and per-run budget caps because the multiplier compounds quickly when something misbehaves.

What does Anthropic’s blueprint not cover about production agent systems?

The blueprint focuses on session-bounded research and leaves several production concerns to the reader: long-running state across days or weeks, failure cascades when a subagent fails mid-orchestration, multi-model pinning for accuracy stability and cost control, runaway-spend protection through circuit breakers and budget caps, and stateful resumption from a checkpoint instead of a full restart. These are not flaws in the blueprint; they are concerns that emerge when the same patterns are applied under production constraints — cost ceilings, accuracy SLAs, speed budgets, error rates — that the research context does not impose.

Building autonomous agent systems under production constraints is the work we do every day. If you’re evaluating multi-agent architecture for a real job and want a practitioner’s view on where the patterns earn their keep, our managed autonomous AI agents service is the closest place to start.

AI Agent Deployment: The Operational Decision at Each Stage

Sebastian Chedal — Fri, 08 May 2026 18:07:21 +0000

Most teams running an AI agent pilot are being asked the same question right now: what do we build next? The published guidance is a stack of vendor maturity models that name the stages without naming the decisions inside them, and the team ends up debating models, prompts, and platforms while the pilot stalls.

A March 2026 Digital Applied survey found that 78% of surveyed enterprises had at least one agent pilot running and only 14% had scaled an agent to production-grade, organization-wide operation.

The same dataset surfaced something that reframes the problem: organizations with production-scale deployments did not have larger AI budgets than the organizations whose pilots stalled. They allocated the budget differently. Less on model selection and prompt engineering, more on evaluation infrastructure, monitoring tooling, and operational staffing. The teams that crossed into production reallocated. They did not outspend.

That finding changes what the deployment stages are for. Each stage has one operational decision that either reinforces the misallocation or breaks it. Get the decision right and the next stage gets cheaper. Get it wrong and you spend the next quarter rediscovering the same problems at higher volume.

This article walks the four operational decisions: workflow scope at pilot, monitoring placement at single-agent production, shared-state ownership at multi-agent coordination, and completion triggers at autonomous orchestration. It also covers the shape of governance cost across the stages, when to stay one stage longer, and the mechanism we run at each stage in our own production pipeline.

The deployment problem is mostly an allocation problem

The Digital Applied survey is the first dataset we have seen that quantifies what production-scale AI agent teams did differently. It is not what most vendor decks would predict. The teams that made it across had comparable AI budgets to the teams that stalled. The difference was where the dollars went.

The blocking factors stalled organizations cited are mostly operational, not modeling. Output quality at volume, monitoring and observability, and organizational ownership are all the work that happens after a model is chosen, after a prompt is tuned, after the demo is approved. The single most-cited operational gap was monitoring and observability, named by 54% of stalled organizations as a blocking factor. That figure shows up again in the Dynatrace work cited later, and it is the one to anchor on: more than half of stalled deployments cannot see what their agents are doing.

The misallocation pattern is recognizable. A team finishes a successful pilot. The next quarter’s budget conversation centers on which model to upgrade to, which prompt strategy to standardize on, which platform to consolidate on. The evaluation harness, the monitoring layer, and the operational headcount are deferred to “after we get the architecture right.” By the time the architecture is settled, the budget for the deferred work is gone, and the agents are running in production without the operational scaffolding they need to scale.

Each of the four deployment stages has one decision that breaks this pattern. Each decision puts a load-bearing piece of operational scaffolding in place before the misallocation can compound. The decisions are not abstract. We have made each of them in our own production agent pipeline, watched the failure modes when we got each one wrong, and rebuilt accordingly.

Pilot stage: the decision is workflow scope

Most pilots are scoped for demo appeal. Someone picks a workflow that will produce a compelling video, the team ships an agent that handles the happy path, and the pilot is declared a success. Then production handoff begins, and integration complexity, the most-cited scaling gap in the Digital Applied data, surfaces all at once. The pilot was never scoped to the messy edges of the workflow it claimed to automate.

The pilot decision is workflow scope. Scope governs every downstream cost. Pick a workflow with a clean input boundary, a measurable success metric, and a defined incident response, and the next three stages inherit a workable foundation. Pick a workflow that looks good in a slide deck, and you are paying for that scope decision for a year.

The mechanism is to define exit criteria at pilot start, not at production handoff. Three concrete criteria, written down before the agent runs:

Task volume threshold. What rate of work does the agent need to handle to be worth running in production? If the answer is “we will figure it out,” the pilot is not scoped.
Quality measurement. What does a wrong answer look like, and how is it caught? The answer cannot be “the user will tell us.” Production agents cost money per run; you need a quality signal that does not depend on a human checking every output.
Incident response. When the agent fails, what happens? Who gets paged? What runs in its place? “We will roll back” is not a plan if the agent is the only thing producing the work.

If the pilot cannot answer those three questions, the next stage is going to be operational firefighting. Worth pairing this stage with an honest AI readiness evaluation across data, governance, and culture before you commit to scaling the agent.

Single-agent production: the decision is monitoring placement

The pilot’s quality gate was a human in the loop. Production needs a different gate, and “we will add observability later” is the dominant failure pattern at this stage. A separate Dynatrace survey reports that a substantial share of leaders still rely on manual methods to monitor agent interactions — not an artifact of small deployments, but the operating reality of organizations that already have agents in production.

The single-agent production decision is monitoring placement. It has to be set before the agent goes live, not bolted on after the first incident. Three layers belong in place at deploy time:

Traces. Every agent run produces a structured trace: inputs, tool calls, outputs, duration, cost. Without traces, you cannot diagnose a failure that did not raise an exception.
Evaluation harness. A reference set of inputs and expected behaviors that runs before any change to the prompt, the model, or the tooling. Without an eval harness, every change is a guess.
Cost circuit breaker. A spending threshold that alerts at one level and halts the agent at another. Agents fail in directions that traditional monitoring does not catch. They keep running, just badly and expensively. Our own production pipeline holds to a predictable daily AI infrastructure baseline only because the cost-defense layers were built before the agents were turned on, not after the first runaway.

The order matters. Traces are the diagnostic substrate. The evaluation harness sits on top, using traces to score behavior. The cost circuit breaker is the last-resort guard for the failure modes that the evaluation harness does not catch in time. Build them in that order, and the next stage, multi-agent coordination, has the diagnostic data it needs. Skip the order, and the next stage is debugged from log files. The per-layer architecture is in the cost circuit breaker article. It is the single piece of single-agent infrastructure we would not deploy without.

Multi-agent coordination: the decision is shared-state ownership

Multi-agent failures look different from single-agent failures. They are not crashes. They are agents stepping on each other’s work, losing track of items in flight, and producing results that contradict each other because each agent inferred the state of the system from a different source. The loss is operational drift rather than catastrophic failure, which is harder to detect.

The multi-agent decision is shared-state ownership. Most of these failures trace to a single cause: agents are assumed to be isolated when they are context-coupled. They touch the same work, but no one named the canonical source of truth.

The mechanism is to name one explicit state owner for each piece of shared context, and require every agent to read and write through it. A file, a table, a queue, a database row: the form does not matter. What matters is that there is one place where the system’s state lives, and no agent infers state from another agent’s output.

In our own pipeline, the canonical state lives in two structured files: one tracks the production status of every content item, and the other tracks topic-level metadata across the inventory. Every agent in the pipeline reads from those files at the start of its work and writes to them at the end. No agent guesses where the work is by reading another agent’s draft. That single architectural decision, a named state owner, eliminated an entire class of failure that had been showing up as “missing items” and “duplicate work” before we made it. The broader pipeline architecture is documented in detail, but the load-bearing decision at this stage is the state-ownership one, not the pipeline shape.

The reason this works: shared state is the point at which multi-agent systems either become a coordinated team or a set of agents producing parallel inconsistent outputs. The investment goes into one well-designed shared structure, not into many ad-hoc handoffs.

Autonomous orchestration: replace fixed schedules with completion triggers

By the time a system has multiple agents in production, the orchestration layer becomes the bottleneck. Variable-duration AI work breaks fixed-schedule orchestration. The symptom is items waiting between stages: a research stage finishes at 11:14am, but the writing stage runs at noon, so the item sits for 46 minutes for no operational reason. Multiply that across a dozen stages and the lag compounds.

The autonomous orchestration decision is to move from fixed schedules to completion triggers. Only the entry point of the pipeline runs on a clock. Every downstream stage fires when the previous stage signals completion. The plumbing is straightforward: a stage finishes, writes its output, and calls the next stage.

The numbers are concrete. Under our previous fixed-schedule design, a piece of work that could move through the pipeline in two to three hours was taking six to twelve. After replacing the fixed crons with completion triggers, the two-to-three-hour window held. The full design and the failure modes that drove it are in the completion-triggered orchestration piece.

One caveat that matters more than the orchestration win itself: completion triggers compound failures faster than fixed schedules do. A bug in stage three under fixed scheduling waits until tomorrow’s run to surface. A bug under completion triggering fires the next stage immediately, which fires the next, which can produce a cascade of bad outputs in minutes. So this stage’s decision has a dependent decision attached: pair completion triggers with anti-loop guards, retry caps, and the cost circuit breaker from the single-agent stage. The orchestration speed-up is real. So is the failure speed-up. Both have to be designed for at the same time.

The cost of governance is per-stage, and the curve is steeper than vendors imply

Governance dollars do not scale linearly across the four stages. They scale by what the stage requires you to monitor. A single-agent production system needs evaluation and alerting. A multi-agent system adds shared-state audit and per-agent identity. An autonomous orchestration system adds completion-trigger guards, recovery infrastructure, and an anti-loop layer.

The shape matters more than the dollar figure. Our own ranges are useful as a reference example, with the caveat that the reader’s numbers will differ based on agent count, workload, and model mix: across nine production agents and sixty-two scheduled jobs at the autonomous-orchestration stage, our daily AI infrastructure cost runs roughly $15-20. That is operational AI infrastructure cost. It is not the full cost of running the system. The curve shape matters more than the dollar figure.

What the curve looks like, by stage:

Single-agent production. Evaluation harness, alerting, traces, cost circuit breaker. The cost is mostly tooling and the operational time to maintain reference sets and tune thresholds.
Multi-agent coordination. Add shared-state audit and per-agent identity. The identity-visibility gap that surveys keep surfacing is theoretical until the multi-agent stage; once two agents share work, it becomes operational.
Autonomous orchestration. Add completion-trigger guards, recovery crons, and per-stage cost limits. This is where agents can do the most damage in the shortest time, and the governance investment reflects that.

The allocation thesis applies again here. Governance dollars belong in evaluation, monitoring, and identity. They do not belong in picking a different model. The per-control breakdown is in the agent governance practitioners guide, mapped to the production stages.

Most teams should stay one stage longer than the vendor pitch implies

Vendors are selling autonomy. Most organizations are mid-curve and are being pushed forward before the decisions at their current stage are settled. The published survey data on enterprise-wide mature adoption is consistently a small minority of the field; the much larger group is the one that has shipped some agents but has not finished the operational scaffolding around them.

Staying longer at a stage is not stalling. It is finishing the operational decision at the current stage before adding the next layer of failure modes. A team that has not settled monitoring placement at single-agent production will find the multi-agent stage harder, not easier. A team that has not named shared-state ownership in multi-agent will find autonomous orchestration produces faster cascades, not faster work.

The question worth asking at the end of a quarter is not “are we ready for the next stage?” It is “have we settled the operational decision at the current stage?” If the answer is no, the next stage is going to be debugged on top of an unsettled one, and the cost of that compound failure shows up later as the kind of stall that the survey data is measuring.

This is also where the conceptual maturity layer lives. The five levels of AI maturity name what each level looks like. The four operational decisions in this article name what to build at each level so the next one becomes possible. The two layers are companions, not duplicates. The decisions in this article are the work that has to happen for an organization to actually move up the maturity curve, rather than describing where they currently sit on it.

Where to go from here

If you have a working pilot, the next operational decision is not which model to upgrade to. It is which workflow to harden, where to place monitoring before the agent goes live, who owns shared state when two agents touch the same work, and how to replace fixed schedules with completion triggers when orchestration starts to drag. Those four decisions, made deliberately, are what the production-scale teams in the Digital Applied survey did with their reallocated budgets.

If you want a partner who has already made each decision in a running production system and can build the infrastructure for your team, our managed autonomous AI agents service runs the full operational stack: evaluation, monitoring, shared-state, orchestration, and governance, at a published price. The decisions are the same whether we run them or you do. The article above is the framework. The service is the implementation.

Frequently Asked Questions

How do I know when my AI agent pilot is ready to move to production?

The pilot is ready when three exit criteria are met: the agent reliably handles a defined task volume, there is a quality measurement that does not depend on a human reviewing every output, and there is a defined incident response when the agent fails. If any of those is missing, production handoff will surface the gap as an integration failure rather than a pilot finding. Production-scale teams in the Digital Applied data wrote those criteria at pilot start, not at handoff.

What’s the operational difference between single-agent and multi-agent deployment?

A single agent fails in directions that traditional monitoring catches: error rates, latency, output quality. Multi-agent systems fail through coordination drift. Agents lose track of each other’s work, step on each other, or produce inconsistent outputs because each inferred the state of the system differently. The operational shift is from instrumenting the agent to instrumenting the shared state the agents read and write through. If you cannot point to one canonical state owner that every agent uses, you are running multiple agents, not a multi-agent system.

What does AI agent governance actually cost at each stage?

The shape is more useful than the figure. At single-agent production, governance is tooling and operational time for evaluation and alerting. At multi-agent it adds shared-state audit and per-agent identity — closing the visibility and containment gap that Cloud Security Alliance research has documented across organizations running agents. At autonomous orchestration it adds completion-trigger guards and recovery infrastructure. The curve, with costs concentrated in evaluation, monitoring, and identity rather than in model and prompt, is the part that generalizes across teams.

How do I scale AI agents without ballooning ongoing costs?

Build the cost defense before the agents go live, not after the first runaway. Daily and per-job spending limits, alerting thresholds set lower than halt thresholds, and an evaluation harness that catches behavioral drift before it shows up as a budget overrun. Cloud Security Alliance research found that 92% of organizations lack full visibility into AI agent identities, and most doubt they could detect or contain a compromised agent — that visibility deficit is what makes runaway costs expensive to catch later. Build identity, audit, and cost-defense into the deploy step. Our daily AI infrastructure cost has stayed in a predictable range as we have added agents and jobs because the limits were in place before the volume was.

When should I add a recovery or anti-loop layer to my agent system?

At the autonomous orchestration stage, before the first completion-triggered run. Completion triggers move work faster, and they also propagate failures faster. A recovery layer of retry caps, anti-loop guards, and cost ceilings tied to the per-stage budget is the dependent decision that has to ship with completion triggering, not after it.

Why do most AI agent pilots never reach production?

The Digital Applied survey found that pilots stall within months on average. The blocking factors named (integration complexity, output quality at volume, monitoring deficit, organizational ownership, domain training data) are consistent with pilots scoped for demo appeal rather than for a workflow with measurable success criteria, scaled into production without monitoring placement decided, and operated without a clear shared-state owner. Each of those is the absence of a decision at the corresponding stage. The cumulative result is the pre-production failure rate that maturity-model coverage keeps surfacing.

Agent Memory & Knowledge Systems Compared (2026 Guide)

Sebastian Chedal — Mon, 04 May 2026 18:07:06 +0000

Most companies deploying AI agents hit the same wall about two months in: the agent forgets everything between sessions, can’t read the company’s actual knowledge (strategy docs, pricing logic, customer notes), and has no clean way to write what it learns back to the team’s knowledge base for human review. The toolkit for solving this is strong, but the question that matters for a mid-market team is different from the question developers ask. It isn’t “which API surface is cleanest.” It’s “how does a company actually maintain its knowledge, feed it to agents, let agents add to it, and keep humans in the loop?”

As of April 2026, there are five named systems worth comparing (Mem0, Zep, Letta, Cognee, and Cloudflare Agent Memory) plus a sixth path: maintaining knowledge as plain markdown and giving agents read/write access through a semantic search index.

In this article:

The five questions to ask before you pick a memory system
What’s off the shelf in 2026 — and what you can build yourself
Mem0, Zep, Letta, Cognee, and Cloudflare Agent Memory, compared on the same scaffolding
The markdown-vault path nobody else writes about
A 4-step workflow for letting agents propose knowledge updates that humans review
A decision framework matched to mid-market deployments

System	Architecture	License	Bidirectional Sync	Best For
Mem0	Vector + graph + KV	Apache 2.0 / managed	Partial (API only)	Personalization, returning end-users
Zep / Graphiti	Temporal knowledge graph	Open source / managed	Partial (API only)	Entity + time queries, CRM agents
Letta	Tiered RAM/disk (agent-managed)	Apache 2.0 / managed	Weak	Long-horizon agents, unlimited memory
Cognee	Vector + knowledge graph from docs	Open core / managed	Partial (doc curation)	Unstructured document ingestion
Cloudflare Agent Memory	Typed (Facts/Events/Instructions/Tasks)	Managed only (private beta)	Partial (shared profiles)	Teams already on Cloudflare
Markdown vault + search	Files + semantic index	Infrastructure cost only	Strong (humans edit directly)	Full ownership, humans as first-class authors

The memory problem every mid-market deployment hits in month two

The first month of an agent deployment usually goes fine. Then three things start happening at once.

First, the session reset. The agent forgets yesterday’s conversation and the user re-explains context every time. By week three, people are typing the same paragraph of background into the prompt every morning.

Second, the knowledge gap. The agent doesn’t know the company’s pricing logic, brand voice rules, approved vendor list, or customer service notes. Those documents live in Notion, Obsidian, Google Drive, an internal wiki, or scattered Slack threads. The agent has no path to any of them.

Third, the learning leak. The agent figures something out during a session (a customer preference, a corrected spec, a new policy detail) and the moment the session ends, that learning is gone.

These three failures are usually framed as a context-window problem. They aren’t. They’re an organizational-knowledge problem. The question is not “how does the agent’s brain hold more information,” it is “where does the company’s knowledge live, who maintains it, and how does the agent participate in that loop without quietly rewriting things humans haven’t reviewed?” Every system below is a different answer to that question.

The five questions to ask before you pick a memory system

A buyer needs a self-diagnostic, a short list of questions to score against any candidate. Five questions cover the field:

1. Context management. How does the agent decide what fits in its working memory right now? Some systems keep the last N messages, some retrieve relevant memories on every turn, some compress conversations into running summaries. The right answer depends on how long your sessions are.

2. Connected knowledge body. Where does the agent’s knowledge come from, and who maintains it? If the only knowledge the agent has is what users say during sessions, the system is closed-loop. If the agent can read the company wiki, customer records, or a curated knowledge graph, it’s connected. Mid-market deployments almost always need the connected version, because the team already has its knowledge somewhere and the agent needs to plug into it.

3. Automatic vs engineered memory. Does the system decide what to remember on its own, or do you tell it explicitly? Automatic extraction is faster to deploy and harder to audit. Explicit memory is slower to set up and easier to control. Most mid-market teams want explicit at first and automatic only after they trust the system’s judgment.

4. Human-agent merge. Can humans read what the agent has learned, edit it, and contribute to the same knowledge base outside the agent loop? The agent should not be the only writer to its own memory. The human team needs a seat at the same table, ideally using normal tools (text editors, wikis, IDEs) rather than a separate “memory dashboard.”

5. Current limits. What does this system not do today? Every memory system has gaps. Some don’t handle entity changes over time, some don’t support multi-tenant scoping, some are private beta with no published pricing. Naming the limits before you commit saves the second deployment from fighting the first one’s blind spots.

These five run as a checklist against every system below.

The 2026 landscape — what’s off the shelf, what you build yourself

There are two paths through this market.

Off the shelf. Opinionated APIs and managed infrastructure. Integration time is days. Trade-offs are vendor lock-in, less control over how memory gets extracted and stored, and pricing models that are usually opaque until you scale. The named players are Mem0, Zep (with its open-source component Graphiti), Letta (formerly MemGPT), Cognee, and Cloudflare Agent Memory.

Build it yourself. Maintain the company’s knowledge as files, usually markdown, in a versioned folder. Index them with a local semantic search tool. Give agents a query interface and, optionally, a write-to-a-review-folder interface. Integration is longer up front, you own the operational complexity, and no vendor will support you. The advantages: knowledge stays portable, humans use normal tools to maintain it, and the cost is essentially infrastructure-only.

There’s also an architectural axis that cuts across both paths. Memory systems tend to fall into one of three patterns:

Vector-only. Embed everything, retrieve by similarity. Fast, simple, weak on temporal and relational queries.
Vector plus knowledge graph. Embed for similarity and extract entities/relationships for graph traversal. Better for “who owns what” and “what changed when” questions.
Tiered or agent-managed. The agent itself decides what to keep in working memory and what to page out to longer-term storage. More flexible, harder to reason about.

Vectorize’s 2026 framework comparison introduced this taxonomy in clean form, and it’s a useful overlay when reading the rest of this article.

The five systems, compared

Mem0 — the personalization memory layer

Mem0 is a vector + graph + key-value memory layer designed to give assistants and support agents persistent, scoped recall about end-users. Best for chatbots, support agents, and deployments where the same users return repeatedly.

The architecture combines three storage layers (vector, graph, key-value) with a four-scope memory model: user_id, agent_id, run_id, app_id, plus an optional org_id. Memories are extracted automatically from conversations and stored against whichever scopes apply. According to Mem0’s State of AI Agent Memory 2026 report (citing the ECAI 2025 paper, Chhikara et al.), Mem0 scores 66.9% on the LOCOMO benchmark at 0.71s median latency using around 1,800 tokens per conversation, versus a full-context baseline of 72.9% at 9.87s and around 26,000 tokens — roughly 14x the token cost for under 6 points of accuracy. The graph-enhanced variant (Mem0g) scores 68.4% at 1.09s. Mem0 publishes both the benchmark and the comparators, so treat absolute numbers as vendor-favorable; the latency and token-cost gaps are directionally useful regardless.

On the five questions:

Context management: retrieves relevant memories per turn, scoped by user/agent/run/app/org.
Connected knowledge body: partial. Mem0 holds what users say; pulling the company’s existing knowledge in is custom work.
Automatic vs engineered: automatic extraction by default, with explicit add/update APIs available.
Human-agent merge: weak. Humans can call the API, but the workflow is developer-shaped, not knowledge-worker-shaped.
Current limits: no native human-review workflow. The four-scope model is the closest the field gets to multi-stakeholder memory but it’s still agent-centric.

License: Apache 2.0 with around 48,000 GitHub stars per dev.to’s 2026 framework roundup. Atlan’s 2026 comparison also notes Mem0 has raised $24M in funding and holds SOC 2 compliance. Repo: github.com/mem0ai/mem0. Managed cloud has a free tier; production pricing is usage-based.

Zep / Graphiti — the temporal knowledge graph

Zep models memory as a temporal knowledge graph: facts have a time dimension, so “Alice owned the budget until February, then Bob took over” is a first-class query rather than a string-similarity guess. The open-source component is Graphiti; Zep Cloud is the managed product on top.

The temporal dimension matters most for production CRM and project agents, anywhere entities change relationships over time and the agent needs “what’s true now” separated from “what was true six months ago.” Zep groups conversations into episodes, summarizes them, and indexes the resulting graph. It scores 63.8% on LongMemEval per Atlan’s comparison, the strongest published number for temporal queries, versus Mem0’s 49.0% on the same benchmark.

One trade-off worth flagging: DevGenius’s builder comparison reports that immediate post-ingestion retrieval often misses correct answers because Zep’s graph processing runs in the background; correct answers tend to surface hours later once the graph catches up. The same piece notes Mem0’s published critique that Zep’s memory footprint can exceed 600,000 tokens per conversation versus Mem0’s ~1,800. That critique comes from Mem0, but the order-of-magnitude gap is consistent across third-party reports.

On the five questions:

Context management: episode-grouped, summarized, retrieved with temporal awareness.
Connected knowledge body: partial. Strong inside the graph it builds, weak at pulling external markdown or wiki content in without custom ingestion.
Automatic vs engineered: automatic extraction, explicit graph editing available.
Human-agent merge: weak. Humans interact with Zep through Zep’s tools, not their own.
Current limits: retrieval delay until graph processing completes. No native human-review workflow.

License: Graphiti is open source; Zep Cloud is usage-based. Around 24,000 GitHub stars per the dev.to roundup. SOC 2 compliant per Atlan.

Letta (formerly MemGPT) — OS-inspired tiered memory

Letta models agent memory after an operating system. Main context is RAM (what’s in the prompt right now). Archival memory is disk (long-term storage the agent can search). The agent itself decides what pages in and out via tool calls. Originally published as MemGPT, the project rebranded in 2024 and continues under the same architecture.

Best for long-running agents that need effectively unlimited memory and where you’re willing to trust the agent with its own paging decisions: research assistants, coding assistants on multi-week projects, deployments running hundreds or thousands of turns. The trade-off is that “the agent decides what to remember” is harder to audit than “the system decides on rules you wrote.”

On the five questions:

Context management: tiered RAM/disk model with agent-driven paging.
Connected knowledge body: partial. Archival memory can hold ingested documents, but you’re operating Letta’s storage, not the company’s existing knowledge base.
Automatic vs engineered: agent-managed, a third path between fully automatic and explicitly engineered by the operator.
Human-agent merge: weak. Humans can call the API; no native co-edit workflow.
Current limits: auditing what the agent chose to remember (and discard) is harder than with explicit-rule systems.

License: Apache 2.0, around 21,000 GitHub stars per the dev.to roundup. Managed cloud available; self-hosted deployment is well-documented.

Cognee — knowledge graph from unstructured data

Cognee is the closest existing system to “feed the company’s documents in and let the agent reason over them.” Its pipeline ingests raw documents, conversations, and external sources, extracts entities and relationships, builds a knowledge graph, and retrieves by graph traversal combined with vector search. The entry point is unstructured documents (not conversation logs) and the graph is the primary retrieval surface, which makes Cognee strong for institutional knowledge and weaker for fast conversational personalization. Best for research-heavy agents and deployments where the inputs are messy documents rather than clean conversations.

On the five questions:

Context management: graph traversal plus vector retrieval; long-form document support is the strength.
Connected knowledge body: stronger here than the conversational-memory peers. Ingestion is the design center.
Automatic vs engineered: automatic extraction with configurable pipelines.
Human-agent merge: partial. Humans curate the input documents, but Cognee’s representation of them is opaque to non-engineers.
Current limits: no native human-review workflow on agent-added knowledge; managed-service pricing not transparent at the time of writing.

License: open core with around 12,000 GitHub stars per the dev.to roundup. Managed cloud available.

Cloudflare Agent Memory — the April 2026 entrant

Cloudflare announced Agent Memory in private beta on April 17, 2026. It’s the most significant new entrant this year, shipping as a managed service running on Workers, Durable Objects, and Vectorize.

Five operations (ingest, remember, recall, forget, list) cover the API surface. Ingestion runs as a two-pass pipeline at 10,000-character chunks with two-message overlap, with an eight-check verifier filtering extracted memories before they land. Memories are typed into one of four classes: Facts (atomic stable knowledge), Events (timestamped happenings), Instructions (procedures), and Tasks (ephemeral). A profile model can be shared across multiple agents and humans, the closest any managed service gets to a multi-stakeholder memory layer. Cloudflare also committed publicly that customer memory is exportable (“your memories are yours; every memory is exportable”), which most managed services don’t.

On the five questions:

Context management: typed retrieval (Facts/Events/Instructions/Tasks) with verifier-gated ingestion.
Connected knowledge body: partial. Designed primarily for conversational and event-driven inputs; document ingestion is supported but not the design center.
Automatic vs engineered: automatic with a strong verifier in the loop.
Human-agent merge: the shared-profile model gestures toward this, but the example in the launch post is “two agents share memory,” not “humans write the source of truth.”
Current limits: private beta with no published pricing; Cloudflare-ecosystem dependency; production proof points are weeks old, not years.

License: managed service, no open-source release. Pricing: not yet published as of April 2026. Best fit: teams already on Cloudflare who want the lowest-friction managed memory layer and are comfortable being early adopters.

The build-it-yourself path: markdown vault plus semantic search

A folder of markdown files plus a local semantic search index is a legitimate competitor to all five managed paths above, especially for mid-market companies that already maintain knowledge in Notion, Obsidian, or git repos. This is one of the patterns we’ve watched work in practice — see how production agent teams handle memory in practice for the operational shape.

The pattern is simple. Maintain company knowledge as plain markdown in a versioned folder (an Obsidian vault, a git repo, a GitHub wiki, a Notion export). Index it with a local semantic search tool. Give agents read access through a query tool that returns matching files (or excerpts) with provenance. Optionally, give the agent write access to a designated subfolder where new notes go for human review before promotion into the canonical base.

The advantages stack up quickly. Knowledge stays portable: no vendor owns your facts, and migrating to a different agent platform means changing the query tool, not exporting and reformatting a database. Humans edit knowledge using normal tools (text editors, Obsidian, IDEs, GitHub PR review), so there’s no separate “memory dashboard” anyone has to learn. The same knowledge base feeds multiple agents and the team simultaneously. Cost is infrastructure-only.

The pattern has a documented public example. A February 2026 walkthrough at eastondev.com describes configuring an agent platform’s Obsidian-vault skill to sync conversation memory as Markdown notes with bidirectional links and structured directories (session logs in one folder, knowledge base in another). When Perplexity is asked about bidirectional human↔agent knowledge sync in 2026, that walkthrough is the project it cites: the only documented end-to-end pattern at the time of writing. For a longer-form view of the same shape, see how a real production pipeline uses memory across multiple stages.

Tools that fit this lane: Obsidian for the markdown editor and graph layer; a local semantic search index combining BM25 and vector search over the vault; LangMem or LlamaIndex memory modules when you want a memory abstraction pairable with a markdown backend instead of a SaaS layer.

When this path is the wrong answer: temporal entity tracking is non-trivial to build (use Zep), agent-managed paging across very long sessions is also non-trivial (use Letta), and if you genuinely don’t want any infrastructure to operate, the managed services exist for a reason.

The bidirectional sync question — how knowledge flows both ways

Most teams treat agent memory as one-way. The agent reads from some knowledge, operates on it, and the work product evaporates. The systems that actually work in production close the loop: agent reads, operates, writes back to a holding area, human reviews, knowledge gets promoted into the canonical base. Four steps, all of them necessary.

Step 1: Source of truth lives with humans. The canonical knowledge base, the place where the company’s strategy, pricing, customer details, and policies actually live, is something humans maintain primarily. An Obsidian vault, a Notion workspace, an internal wiki, a git repo of markdown files. Whatever it is, the humans on the team are the authoritative authors. This principle of building your own knowledge base rather than letting it live inside a vendor’s database is what makes the rest of the workflow possible.

Step 2: Agent reads with provenance. When the agent answers a question or makes a decision, it cites which document (or which memory record) the answer came from. No “trust me” responses. Provenance is non-optional, because without it humans can’t audit what the agent is doing.

Step 3: Agent writes to a review queue, not the source of truth. When the agent learns something new (a customer corrected a fact, a project changed scope, a pricing exception was approved) it writes that new note to a pending/ or inbox/ folder. Never directly to the canonical base. The agent’s job is to propose, not to publish.

Step 4: Human review promotes or rejects. A periodic review pass (daily for high-velocity environments, weekly for most) either promotes the agent’s proposed notes into the canonical base or rejects them. The canonical base only grows under human authority. The review interface is whatever the team already uses: a folder, a Pull Request, a Notion page with a checkbox.

How each system maps to these steps tells you the most about whether it’s a fit:

Mem0: step 2 strong (four-scope provenance), step 1 partial, steps 3 and 4 require custom work.
Zep: step 2 strong (episode-level provenance), step 1 partial, steps 3 and 4 require custom work.
Letta: step 2 harder (paging decisions aren’t always traceable), steps 3 and 4 require careful tool wrapping.
Cognee: step 1 strongest (document ingestion is the design center), step 2 partial, steps 3 and 4 require custom work.
Cloudflare Agent Memory: typed classification and shared profiles gesture at multi-stakeholder memory; step 4 is the gap.
Markdown vault plus semantic search: step 4 is just “humans editing a folder” or “merging a Pull Request.” That’s where this path quietly wins. Steps 1–3 require operational discipline rather than a vendor.

No system natively implements step 4. All of them assume the agent has authority to update memory directly. The systems that come closest do so by accident (Cloudflare’s shared profiles, Mem0’s scoped models) not by design. The markdown-vault path makes step 4 a workflow choice instead of a feature request.

A decision framework for picking the right system

Read the framework as “if your situation is X, start with Y”:

Already on Cloudflare and want low-friction managed: Cloudflare Agent Memory (private beta; confirm access first).
Adaptive personalization for end-users (chatbot, support, returning users): Mem0.
Entities and relationships change over time (“who owned this account in February”): Zep / Graphiti.
Long-horizon agents needing effectively unlimited memory: Letta.
Ingesting unstructured documents, reasoning over a knowledge graph: Cognee.
Full ownership, portability, humans as first-class authors: markdown vault plus semantic search.
Already on LangChain/LangGraph or LlamaIndex: use their memory modules first; revisit only if you outgrow them.

Most mid-market deployments end up combining a markdown vault for canonical knowledge with one of the off-the-shelf layers for transient session memory. The vault holds what the team owns; the SaaS layer holds what the agent needs to remember about an active conversation. That split keeps canonical knowledge portable while letting the agent operate at the speed users expect.

Open problems in the field

The agent-memory category is roughly eighteen months old as a distinct discipline. A few caveats apply across all six paths above. No system natively implements the human-review-promotion gate; all assume the agent has authority to update memory directly. LOCOMO and LongMemEval are useful but easy to overfit (Cloudflare’s launch post says so directly) so treat scores as directional. Most managed services route conversation extraction through their own LLMs — fine for some businesses, a deal-breaker for others. None publish per-query pricing in a way that lets a buyer model real-world cost ahead of time. Cloudflare publicly committed to memory export; most others have not. Voice agent memory is a distinct emerging sub-problem.

The market gap is wide enough that one of the major systems will likely close it within twelve months.

FAQ

What is the best AI agent memory system in 2026?

There isn’t a single best. Mem0 leads on personalization and benchmark scores. Zep / Graphiti leads on temporal queries. Letta leads on long-horizon agent-managed memory. Cognee leads on unstructured-document ingestion. Cloudflare Agent Memory is the most significant new managed entrant. For deployments where humans need to be first-class authors of the knowledge base, a markdown vault plus a semantic search index is often the right answer.

Is Cloudflare Agent Memory open source?

No. Cloudflare Agent Memory is a managed service in private beta as of April 17, 2026, running on Workers, Durable Objects, and Vectorize. Cloudflare has committed publicly to making customer memory exportable, but the service itself is closed-source.

What’s the difference between Mem0 and Zep?

Mem0 is optimized for personalization, remembering things about end-users across sessions, with a four-scope memory model (user_id / agent_id / run_id / app_id). Zep is optimized for temporal knowledge, tracking how entities and relationships change over time using a knowledge graph. Mem0 is faster on retrieval; Zep is more accurate on “what was true when” questions. Per published benchmarks, Mem0 leads LOCOMO and Zep leads LongMemEval.

Can I use Obsidian as memory for an AI agent?

Yes. The pattern is to maintain company knowledge as markdown in an Obsidian vault, index it with a local semantic search tool, and give the agent a query interface. Optionally, give the agent write access to a review folder where humans promote or reject new notes. A February 2026 walkthrough at eastondev.com documents one full implementation.

How do I let an AI agent update my company’s knowledge base?

Don’t let it write directly. Use a four-step bilateral sync workflow: humans maintain the canonical knowledge base, the agent reads with provenance, the agent writes new learnings to a review folder (not the canonical base), and a periodic human review promotes or rejects them. None of the major managed memory systems implement step four natively, which is why the markdown-vault path is often the easiest fit.

If you don’t want to build this

If your business is hitting the memory wall and you don’t want to evaluate six options and stand up the bidirectional review workflow yourself, that’s the kind of work we do. We can run the memory architecture and the human-review workflow with you, so the canonical knowledge stays yours and the agent participates in the loop you already trust.

What MCP, A2A, and UCP Mean for Your Website in 2026

Sebastian Chedal — Sat, 02 May 2026 18:06:58 +0000

If you run a website in 2026, you have probably watched three different articles about MCP, A2A, and UCP scroll past in the last two weeks and wondered whether any of it changes what you should be doing this quarter. The short answer is yes, but probably less than the headlines suggest, and not in the direction the headlines point. The agentic protocol stack is real infrastructure that is now mainstream conversation, and most of the work the average website owner needs to do about it can be done in an afternoon.

Three sources published the same underlying observation within roughly two weeks of each other. Backlinko released a six-protocol primer on MCP, A2A, NLWeb, WebMCP, ACP, and UCP, framing them as “what robots.txt and XML sitemaps were to 2005 Google.” Addy Osmani, Google Cloud’s Director of Engineering, published an Agentic Engine Optimization framework along with an open-source audit tool. Conductor analyzed 13,770 domains and 17 million AI responses and named the resulting visibility layer “the parallel surface.” Three independent signals, same conclusion. Agentic protocols are now part of how websites get discovered, queried, and (eventually) transacted with by AI agents on behalf of their users.

This article is the version for the person who runs a website and wants to know which of these protocols matter for their site, which ones they can ignore, and what is reasonable to actually do about any of it before the end of the quarter.

What “Protocol-Ready” Means

Protocol-ready means an AI agent can discover, query, and (where it makes sense) transact with a website through a standardized interface, instead of scraping HTML and guessing at structure. That is the whole definition.

The closest historical parallel is the one Backlinko reaches for and gets right. Their verified framing: “Think of how robots.txt and XML sitemaps became table stakes for search crawlers. Agentic protocols are shaping up to be that for AI agents.” Robots.txt was a quiet text file that turned into existential SEO infrastructure within three years of nobody caring about it. The trajectory of the agentic protocol stack looks similar, though earlier on the curve.

The signal that this is now mainstream rather than speculative is convergence. DigitalApplied’s ecosystem map reports 97 million MCP downloads as of March 2026. Backlinko’s count of the PulseMCP directory has more than 10,000 MCP servers live as of early 2026. Conductor’s 2026 benchmark finds AI referral traffic averaging around 1% of total website traffic and growing roughly 1% per month. The 1% number is small, but the growth rate is the part to watch. The infrastructure has reached the volume where ignoring it stops being defensible, even if acting on it is still optional for most sites.

For the content-side companion to the infrastructure questions in this article, see our agentic SEO practitioner guide, which covers what to publish so AI agents can actually use it.

The Three Protocols That Matter Now (and the Three to Watch, Not Build For)

Backlinko enumerates six protocols. The count is correct as a taxonomy, and misleading as a buying recommendation. For 2026 website-scale decisions, three deserve real attention. Three more are worth tracking and nothing more.

Build for now

MCP (Model Context Protocol). The agent-to-tools layer. Anthropic launched MCP in November 2024, and it is now governed by the Agentic AI Foundation under the Linux Foundation. The standard has been adopted by OpenAI, Google, and Microsoft. If your business has any internal system you would want AI tools to query (a product catalog, a CRM, a CMS, a support knowledge base, an inventory database), an MCP server is the standard interface for exposing that system to agents. It is the only protocol on this list that has cleared “is this real” status. If you have nothing for an agent to query, you do not need MCP.

A2A (Agent-to-Agent). The agent-to-agent layer. Google launched A2A in April 2025 with more than 50 technology partners, including Salesforce, PayPal, SAP, Workday, and ServiceNow. The Linux Foundation now maintains it under Apache 2.0. A2A becomes relevant when a website operates more than one agent that needs to coordinate with another agent (yours or someone else’s). Most websites are not running multiple agents yet. If you are running one agent or none, A2A is informational. If you reach three or more by the end of 2026, you will need it.

UCP (Universal Commerce Protocol). The agent-to-commerce layer. Sundar Pichai announced UCP at NRF 2026, co-developed by Google and Shopify with launch partners including Target, Walmart, Wayfair, and Etsy, plus 20+ additional partners including Mastercard, Visa, Stripe, and American Express. UCP runs on top of OAuth 2.0 and PCI-DSS, with MCP and A2A bindings built in. UCP launched less than 14 weeks after OpenAI and Stripe announced ACP, the competing OpenAI-led commerce protocol. The two protocols overlap. UCP has the broader retailer coalition; ACP has live distribution inside ChatGPT. If your site sells products and you are picking one to keep on your radar today, UCP is the safer bet on coalition breadth.

Watch, do not build for yet

NLWeb. A natural-language interface for websites, created by R.V. Guha, who also created RSS, RDF, and Schema.org. Heavy pedigree. Early adopters include TripAdvisor, Shopify, Eventbrite, O’Reilly, and Hearst, announced at Microsoft Build 2025. Interesting long-term. Most websites do not need it yet.

WebMCP. A Google-and-Microsoft W3C Community Group proposal, with an early preview shipping in Chrome in February 2026. Pre-standard. Worth watching, not worth implementing this quarter.

ACP (Agent Commerce Protocol). OpenAI and Stripe’s commerce protocol. Live in ChatGPT Instant Checkout since September 2025, with 900 million weekly ChatGPT users and a reported 4% merchant fee per Opascope’s synthesis. Real, but overlapping with UCP. If you only have budget for one commerce protocol implementation, the broader-coalition standard wins on portability.

Run This on Your Own Site: A Five-Point Readiness Check

Most websites only need to act on two or three of the five questions below. The point of running through all five is to know which two or three those are.

1. Structured-data baseline. Schema.org coverage for Organization, Product, Service, FAQPage, and Article at minimum. If your structured data is incomplete, no protocol implementation will compensate, because agents still need the structured signals underneath. Run Osmani’s agentic-seo audit tool against your own domain. The tool runs ten checks across five categories (Discovery, Content, Token Efficiency, Agent Context, AI Usability) and scores out of 100. Free, public, fifteen minutes. Run it against a competitor’s domain in the same session if you want a calibration point.

2. Content recency check. Amsive reported that 50% of AI-cited content is less than 13 weeks old. If your last cornerstone publish was six months ago, fix that before anything else. Recency is the precondition; protocols are the amplifier. Cornerstone-content cadence is a bigger lever for AI visibility right now than any single manifest decision.

3. /.well-known/ manifest decision. There are three possible manifests, and not every site should publish all three. A UCP manifest at /.well-known/ucp is relevant if you sell products online. An LLMs.txt file is relevant for content-heavy sites that want to expose a curated reading order to AI agents. An agents.md file at the repository root is relevant if your site or codebase is going to be navigated by coding agents. Most sites need one or two of these, not all three. Decide what to publish, not all of it.

4. MCP tool exposure decision. Do you have an internal API, database, or system an agent should reach? If yes, an MCP server wrapping that system is the right pattern. If no, and most brochure-site businesses are in this category, skip MCP entirely this quarter. There is no point building infrastructure for agents to use when there is nothing for them to use it for. If you do expose an internal system, build a cost circuit breaker pattern in front of it before going live. Runaway agent calls produce surprise bills.

5. Citation baseline. Before any protocol work, measure where your site is currently being cited in AI answers across Perplexity, ChatGPT, Gemini, Claude, and Google AI Mode. Conductor’s 2026 AEO/GEO Benchmarks, built on 13,770 domains and 17 million AI responses, give you the industry calibration. AI referral traffic averages around 1% of total and is growing roughly 1% per month. If you do not measure where you are cited today, you cannot tell whether anything you do tomorrow is working.

Five questions, answerable in an afternoon. Most websites only need to act on two or three of them.

When you can skip this entirely. Sites with fewer than 50 indexed pages, sites in regulated verticals where agent transactions are not yet legal (regulated financial advice, healthcare prescribing, anything that requires a licensed human in the loop), and sites whose current content strategy is not producing anything citable in the first place. The structured-data and content-recency checks above will surface this quickly. If both fail, fix those first; the protocol questions can wait.

Where This Is Going (and What to Do About It)

The trajectory is directionally certain and short-term modest, and that is the framing to take into your next planning meeting. Backlinko, Pipe17, and the Google Developers Blog all published their protocol primers in Q1 2026. Search Engine Journal, SEMrush, and Ahrefs will follow this year. Conductor has already named “the parallel surface of visibility” as the canonical 2026 framing. Protocol-readiness is going to show up as a normal RFP requirement on a 12-to-24-month horizon, not a “by July” deadline. The current AI-referral share is small. The growth rate is the part that compounds.

What is reasonable to do now if you run a website. Run Osmani’s agentic-seo tool on your domain (15 minutes). Audit your cornerstone content recency (1 hour). Decide whether you have an internal system that would benefit from MCP exposure (most websites do not, and “no” is a perfectly reasonable answer). If you sell products online, put a calendar reminder to revisit the UCP manifest question in Q3, when the retailer adoption curve will be clearer. None of this is a multi-quarter program. It is afternoon-scale work for most sites, and skip-entirely work for many of them.

We are a technology studio that builds autonomous AI systems. The readiness work in this article sits in front of the platform layer we run for clients with bigger needs (clients running production agents, exposing internal systems through MCP, or building multi-agent workflows that coordinate over A2A) at Fountain City’s managed autonomous AI agents.

FAQ

What is MCP (Model Context Protocol)?

MCP is the standardized interface AI agents use to talk to tools and data sources. Anthropic launched MCP in November 2024, and it is now governed by the Agentic AI Foundation under the Linux Foundation, with adoption from OpenAI, Google, and Microsoft. According to Backlinko’s count of the PulseMCP directory, more than 10,000 MCP servers are live as of early 2026. Practically, if you have an internal system an AI tool should query, an MCP server is the standard wrapper.

What is UCP (Universal Commerce Protocol)?

UCP is the agent-to-commerce protocol announced by Google and Shopify at NRF 2026. Launch partners include Target, Walmart, Wayfair, Etsy, Mastercard, Visa, Stripe, and American Express, with 20+ additional partners endorsing the standard. UCP runs on OAuth 2.0 and PCI-DSS and includes MCP and A2A bindings. It exists so AI agents can complete purchases on behalf of shoppers using a standardized handshake instead of brittle scraping.

What is the difference between MCP, A2A, and UCP?

MCP connects agents to tools and data. A2A connects agents to other agents. UCP connects agents to commerce checkout. Different layers of the same stack, and most websites only need one or two of them.

What does “protocol-ready” mean for a website?

Protocol-ready means an AI agent can discover, query, and (where it makes sense) transact with the site through a standardized interface, instead of scraping HTML and guessing at structure. Concretely: structured-data coverage in place, recent cornerstone content, the right /.well-known/ manifest published, and (if internal systems are involved) an MCP server with auth and rate limits.

Is this the same as GEO or AEO?

Adjacent, not identical. GEO (Generative Engine Optimization) and AEO (Answer Engine Optimization) are about optimizing content to be cited by AI engines. Protocol readiness is the infrastructure layer underneath that. The standardized interfaces agents use to discover, query, and transact with a site. The five-point readiness check covers both, because the questions overlap.

Does my site need all six protocols?

No. For 2026 decisions, three matter (MCP, A2A, UCP), and three are worth tracking but not building for yet (NLWeb, WebMCP, ACP). Most websites only need one or two of the build-for-now three. The five-point readiness check is the way to figure out which.

When can I skip this entirely?

Sites with fewer than 50 indexed pages, sites in regulated verticals where agent transactions are not yet legal, and sites whose current content is not producing anything citable in the first place. If the structured-data and content-recency checks both fail, fix those first; the protocol questions can wait.

Claude Code and Codex Together: Driver/Worker Orchestration in Production

Sebastian Chedal — Fri, 01 May 2026 18:12:58 +0000

The pattern that has held up across complex refactors, full WordPress migrations, and ground-up SAAS rebuilds is hierarchical: Claude Code (Opus 4.7) is the driver. Codex (GPT-5.5) is the worker. Claude Code plans, calls Codex to do the heavy execution, gets the results back, reasons over them, decides what’s next.

The version stamps matter for an article like this. Opus 4.7 launched April 16, 2026. GPT-5.5 launched April 23, 2026. The framework we currently run on top of them — BEADS with Metaswarm v0.11.0 — landed mid-April.

The Quick Verdict

Workload	Where it lives	Why
Planning, architecture, ambiguous specs	Claude Code (driver)	Long-context coherence, self-verification sub-agents
Long terminal runs, mechanical execution	Codex (worker)	Sustained 45+ minute runs, ~72% fewer output tokens
Reasoning over returned work, integration, review	Claude Code (driver)	Review is folded into the driver’s loop, not a separate step
Single-tool work that fits in one context window	Either, alone	Driver/worker overhead doesn’t earn its keep

Benchmark anchors: Lushbinary, April 2026, cross-checked against FwdSlash.

What Each Is Specifically Better At (April 2026)

Where Claude Code (Opus 4.7) Wins

Practitioners running both consistently describe Claude Code as the tool for the thinking work: the ambiguous problem, the large codebase, the architecture decision that will outlast the session. Chandler Nguyen’s follow-up post in late April put it plainly after weeks of running both: “Codex took the coding seat and Claude Code took everything else.” The “everything else” covers planning, comprehension, reviewing what came back from the worker, deciding when something is actually done.

The benchmarks line up with that read. Opus 4.7 leads on SWE-bench Pro at 64.3%, SWE-bench Verified at roughly 87.6%, CursorBench at 70%, and GPQA Diamond at 94.2%. Two operational features show up in daily use beyond what those numbers capture: CLAUDE.md persistent project context (so the agent re-loads architecture decisions across sessions), and what Chandler called the killer feature, the harness spawning verification sub-agents without being asked. On long sessions, especially over 90 minutes of continuous work on the same problem, it holds the thread better than alternatives we’ve tested.

Claude Code’s token consumption is roughly 3-4x higher than Codex CLI on equivalent tasks. The harness is doing more (context preloading, sub-agent spawning, automatic verification passes) and you pay for that in tokens. For deep work, the cost is justified. For high-volume mechanical transformations, it isn’t. That gap is most of why the driver/worker split makes sense.

Where Codex (GPT-5.5) Wins

Among practitioners running both, Codex is where the long execution lives. It runs hard for stretches Claude Code wouldn’t sustain. Chandler’s experience report describes Codex working 45+ minutes continuously without losing the thread. The cloud-container architecture lets you fire-and-disconnect: hand off a task, close the laptop, come back when it’s done. That sustained-run profile is the operational reason it works as a worker. The driver doesn’t have to babysit it.

GPT-5.5 leads on Terminal-Bench 2.0 at 82.7%, OSWorld-Verified (computer use) at 78.7%, GDPval at 84.9%, and Tau2-bench Telecom at 98.0%. OpenAI says 85%+ of the company uses Codex weekly across engineering, finance, comms, marketing, data science, and product. They run it because it executes.

Token efficiency is where the gap compounds at scale. GPT-5.5 uses roughly 72% fewer output tokens than Opus 4.7 on equivalent coding tasks. When the worker is doing the bulk of the volume (terminal runs, mechanical transformations, parallelizable sub-tasks) that efficiency is what makes the dual-tool monthly bill defensible.

Note: An interactive chart comparing benchmark scores appears at this point in the original article. View the chart on fountaincity.tech.

The Harness Effect (Why This Comparison Is Mostly About the Harness, Not the Model)

Matt Mayer ran the same model through two different harnesses on identical tasks: Claude Opus scored 77% in Claude Code and 93% in Cursor. Same model, same tasks, sixteen percentage points from the harness alone.

CORE-Bench reproduced the pattern more dramatically. Claude Opus scored 42% with a minimal scaffold and 78% inside Claude Code’s full harness. Thirty-six points of capability appeared from the wrapper, not the weights. Nate’s Newsletter reported the same gap in independent testing: a 36-point spread on identical tasks driven entirely by harness differences.

The harness has four components, per Jonathan Fulton’s architectural breakdown: a loop that decides when to call the model again, a context manager that handles compaction and memory, a tool registry with descriptions and schemas, and an approval system that intercepts tool calls. Codex and Claude Code converge on similar architectures here. The differences that drive the harness effect are subtler: how aggressively each one summarizes context, how many parallel sub-agents it manages, what the default tool descriptions look like, how the system prompt is structured.

If 16-36 percentage points of capability come from the wrapper rather than the weights, then nesting harnesses (putting one inside another in a driver/worker topology) is a way of stacking those gains, not averaging them. The driver gets the planning and integration capability of one wrapper. The worker gets the terminal autonomy and token efficiency of another. The combined system is bigger than either side, and the cross-harness review that emerges from the topology is what catches the bugs neither single harness sees.

How We Run Them Together: Driver/Worker Orchestration

The pattern is hierarchical, not parallel. Driver/Worker Orchestration: Claude Code drives. Codex executes when the driver delegates. Results return up to the driver. Working alternatives include the Planner-Driver Pattern and the Orchestrator/Worker Harness.

Layer	What happens	Why this side
Driver keeps (Claude Code)	Planning, codebase comprehension, architecture decisions, deciding what to delegate, deciding when the task is done	The driver’s job is to hold the whole picture. Long-context coherence and the self-verification sub-agents make it the right tool for the work that has to remember why earlier decisions were made.
Driver delegates to worker (Codex)	Long terminal runs, mechanical transformations, parallelizable sub-tasks, anything where 45+ minute uninterrupted execution and lower per-token cost are the right shape	The worker doesn’t need to hold the whole picture. It needs a scoped task, the ability to run hard for an hour, and the discipline to report back cleanly. Codex’s terminal autonomy and token efficiency fit that shape.
Worker returns to driver	Codex reports results, diffs, test outcomes, and any unresolved questions back up. Claude Code reads the returned work in its own context, reasons over it, integrates it, decides next steps	Review is implicit in the topology rather than a separate “cross-model review pipeline step.” The driver always re-reads the worker’s output before merging it into the plan; cross-harness coverage is a side-effect, not a manual step bolted onto the end.

The driver’s loop never closes. Claude Code spawns Codex, waits for it to finish, then re-engages with the returned work. The next task usually emerges from reasoning over what came back, not from a pre-planned queue. That’s why the topology compounds. Each worker run sharpens the driver’s plan; each driver decision changes the next thing the worker gets asked to do.

Shared context, separate context files. Claude Code reads CLAUDE.md at the project root; Codex reads from ~/.codex/skills/. Both have to know the same conventions or the worker’s output won’t fit cleanly back into the driver’s plan. Chandler’s cross-pollination workflow is the practical answer: have Codex study your existing Claude Code skills and produce equivalents under ~/.codex/skills. Same conventions, two file formats. The Skills standard is converging across both tools, but as of April 2026 you’re still translating between formats.

The cleanest version of this runs Codex from inside the Claude Code session, through an orchestration framework that handles the spawn, wait, and return. The worker doesn’t see the user; it sees the driver. The user sees only the driver. That’s what makes the loop close: Claude Code is the only thing the engineer interacts with directly.

The worker reports structured results: diffs, test results, log excerpts, unanswered questions. The driver reasons better when the worker’s return packet is shaped for reasoning rather than just for human review. This is mostly a matter of how the framework prompts the worker. Most orchestration frameworks now support structured return packets out of the box.

The Orchestration Framework Layer (BEADS+Metaswarm and the 2026 Ecosystem)

The driver/worker topology runs through a framework: the substrate that handles spawn, context handoff, structured return, and session bookkeeping so the driver can pick up where the worker left off. As of April 2026 we run on BEADS with Metaswarm v0.11.0. Metaswarm provides the multi-agent orchestration layer; BEADS handles persistent issue tracking, context priming, and semantic summarization across sessions, exposed as a Claude Code plugin. It’s what we use today. It’s not what we’ll necessarily use next month.

Framework choice is fluid in a way that didn’t exist before agentic coding. Switching between Metaswarm and an alternative is a per-project decision now, not a per-company one. You can scaffold one system, test a different framework on the next sprint, and migrate gradually if the new one earns it. The pattern (Driver/Worker Orchestration) is what holds across framework swaps.

The wider 2026 ecosystem at the harness/framework layer:

BEADS + Metaswarm: our current stack. Metaswarm’s session hooks defer to the standalone BEADS plugin for context priming and decision tracking, which means the driver can survive context compaction without losing the thread.
Archon: described in April 2026 research as the first open-source harness builder for orchestrating Claude Code and Codex together. Worth a look if you want to build your own multi-tool flow rather than wire up shell scripts.
Citadel: agent orchestration harness for Claude Code and Codex with parallel agents in isolated worktrees, four-tier intent routing, and persistent campaign memory across sessions. The closest in scope to BEADS + Metaswarm if you want a different shape on the same problem.
HumanInLoop: open-source strategy harness on top of Claude Code — DAG-based multi-agent coordination with cascade safety, focused on telling each agent what to build and why before delegation. Different angle on the orchestration question.
awesome-harness-engineering: the canonical GitHub corpus on harness patterns. First read for anyone trying to understand what’s actually being built at this layer.

The Codex CLI repo sits at 67k GitHub stars; Claude Code at 114k. The community of practice around both is active enough that the driver/worker topology is being independently rediscovered week by week. Most teams who run both for more than a month end up at some version of it.

Where We’ve Run This (Three Production Categories)

The pattern doesn’t pay for itself on small tasks. Three workload shapes earn it.

Complex code refactoring. Multi-file refactors across a large codebase, where the architecture decision drives a series of mechanical transformations downstream. The driver holds the architecture and the invariants the refactor has to preserve. The worker does the long mechanical pass, file by file, returning diffs and test results. The driver re-reads each return, catches the cases where the mechanical transformation broke an architectural assumption, and either fixes them in-place or sends the worker back with a tightened spec.

WordPress site and server migrations. Building or migrating an entire WordPress site, including the underlying server. The work is a mix of architectural decisions (theme structure, plugin selection, server topology) and long mechanical execution (block migration, content import, server provisioning, deployment scripts). The driver/worker split fits naturally: Claude Code reasons about the architecture and the migration order, Codex executes the long terminal sessions and reports back. Some of these runs go for hours.

Ground-up SAAS rebuilds. Re-platforming an existing SAAS system with upgraded security, statefulness, and reliability. The driver holds the new architecture, the security model, the state-handling decisions. The worker rebuilds modules, runs migration scripts, executes the long test passes that catch regressions. The combined session has been the highest-leverage version of the pattern we run.

The economics across these three categories: teams running this report roughly 80% higher result quality versus single-tool runs of comparable shape, with substantially more code shipped per session and a lower per-task cost (because the worker is doing the volume on the more token-efficient model). Wall-clock per session is slightly slower than single-tool runs would be (the driver/worker handoffs add a few minutes each cycle), but you do other work while the worker runs, so wall-clock isn’t the right unit. The longest single combined run we’ve executed start-to-finish was just under four hours. None of those numbers are A/B-clean; they’re what we see in practice across these three workload shapes.

The same pattern runs on our content side. Our multi-agent content pipeline runs on the same driver/worker structure at a monthly cost equivalent to roughly 3 hours of a mid-level engineer (a planning agent that delegates execution to specialized workers and integrates the returned work). Different domain, same topology. The agent team running that pipeline is structured around the same driver/worker logic at a higher level of abstraction.

What This Costs (At Team Scale)

Scale	Monthly tooling spend	Reference point
Solo developer (driver + worker)	$120-$400	Claude Max $100-$200 + ChatGPT Plus $20 or Pro $200
4-engineer team	$480-$1,200	4× Claude Max + shared/individual ChatGPT seats
Our internal pipeline (10+ agents)	~$450-$600	Cost equivalent to roughly 3 hours of a mid-level engineer per month

A mid-level engineer fully loaded runs $150K-$200K/year, which is $12K-$17K/month. The 4-engineer dual-tool stack pays for itself with single-digit hours of replaced work per engineer per month. The only published case study at large company scale we’ve seen is Anthropic’s own Rust C-compiler internal study: roughly 2,000 sessions, ~$20K total cost, on a 100K-line codebase. That’s vendor-published economics on a single-tool engagement, useful as a reference shape for what large-scale agentic work costs.

The driver/worker version of the bill comes out lower than running everything on Claude Code, because the worker is doing the volume on the more token-efficient model.

A 90-Day Team Adoption Playbook

The driver/worker pattern is teachable, but it doesn’t install itself. Teams that adopt it cleanly tend to follow some version of this rollout.

Weeks 1-2: Get one engineer fluent on the driver

Pick the driver first. Claude Code is the safer default for the driver role for most teams, because the planning, comprehension, and review work is what the driver does and that’s where Claude Code currently leads. Get one engineer fluent before involving anyone else. Set up CLAUDE.md for your codebase. Don’t add the worker yet. The point of this phase is for the engineer to internalize what work the driver actually does and what work it should hand off.

Weeks 3-4: Add the worker inside the driver’s harness

Same engineer now adds Codex as the worker. Pick a framework (BEADS+Metaswarm, Archon, or roll your own) that handles the spawn-and-return mechanics. The single calibration question this phase answers: what work should the driver delegate, and what should it keep? The answer is codebase-specific. By end of week 4, the engineer should have a one-page allocation document that captures it. Run cross-harness review on every non-trivial PR by virtue of the topology, not as a separate step.

Weeks 5-8: Roll out to the team

Other engineers adopt the driver first, then add the worker. Publish your CLAUDE.md, your ~/.codex/skills, and your framework configuration in the repo so the team inherits the same context. Hold a weekly 30-minute review: what did the driver/worker flow catch that single-tool would have missed? What did the framework get in the way of? Adjust the framework config rather than the topology. The topology is the whole point.

Weeks 9-12: Measure and decide on the framework

Three numbers to track. Token cost split between the two harnesses (worker should be doing meaningfully more of the volume; if it isn’t, the driver is over-keeping). Pull requests per engineer per week (delta from before adoption). Regression catch rate (driver re-reads of worker output should catch things that single-tool runs would have shipped). At the 12-week mark, the decision is usually about the framework, not the topology: keep BEADS+Metaswarm, swap to Archon, or move to whatever has appeared in the months since this article was written. The topology survives the framework swap.

Common Pitfalls

Treating the worker as a peer. The point isn’t redundancy or parallel allocation. The worker doesn’t see the user, doesn’t hold the architecture, doesn’t decide when something is done. Treating it as a peer collapses the pattern back into the parallel version that doesn’t compound.
Skipping the result-integration step in the driver. The whole topology depends on the driver re-reading the worker’s output before integrating it. If you let the worker’s diffs auto-merge, you’ve removed most of the value.
Over-anchoring on the framework. Framework switching is cheap now. Pick one, run with it, swap it when something better lands. Don’t build the team’s entire workflow around any specific framework’s idiosyncrasies.
Ignoring token-cost monitoring. Both harnesses can spike unexpectedly. Set thresholds and alerts; the cost-control pattern is detailed in the cost circuit breaker post.

When You Should Not Use Both

The driver/worker pattern earns its overhead on a specific shape of work. Outside that shape, single-tool is the right answer.

If your work fits in one context window or sits cleanly in one category, pick the matching tool and go deep. Driver/worker pays off when the work is large enough that the driver has something to hand off; on small focused tasks or uniform workloads, the handoff overhead exceeds the gain. If your work is 100% terminal-heavy ops, Codex alone is fine. If it’s 100% deep architectural reasoning over a small codebase you can hold in your head, Claude Code alone is fine.

Teams without operational discipline for the handoff topology should skip the second tool until they have it. Running two harnesses without the driver re-reading worker output is just running two harnesses; you get the cost of both with the catch rate of one. The structural discipline matters more than the tool count.

If your team is on one tool and shipping fine, the upgrade priority is probably not adding the second tool. It’s getting better at the one you have. The harness-effect data above (16-36 percentage points hidden in better harness configuration) suggests most teams have meaningful headroom on their current tool before they need a second.

Where Fountain City Fits

We run Driver/Worker Orchestration in our own pipeline and on client engagements. We teach it through agentic coding training for development teams and agencies. When teams want the orchestration built and operated for them rather than learning to run it themselves, that’s the work behind managed autonomous AI agents (also see our agentic development service for build-only engagements). The same driver/worker logic shows up in other agent applications too — see how the pattern shows up in agentic SEO for a different domain example.

If you want to run this yourself, you have what you need. If you want help, that’s the conversation we have.

Frequently Asked Questions

Is GPT-5.5 better than Claude Opus 4.7 for coding?

Neither is uniformly better. Opus 4.7 leads on SWE-bench Pro (64.3% vs 58.6%) and on architecture-heavy benchmarks (CursorBench 70%, GPQA Diamond 94.2%). GPT-5.5 leads on Terminal-Bench 2.0 (82.7%), OSWorld-Verified (78.7%), and Tau2-bench Telecom (98.0%), and uses ~72% fewer output tokens on equivalent tasks. The right answer depends on what shape of work dominates your team. For mixed workloads, the answer is to use both, with Claude Code as the driver and Codex as the worker, per the topology described above.

Should I use Codex or Claude Code if I can only afford one?

If your work is heavily terminal-based, ops-heavy, or token-cost-sensitive, pick Codex. If your work is architecture-heavy, involves long multi-file refactors, or requires sustained reasoning over ambiguous specs, pick Claude Code. Solo developers with mixed workloads typically default to Claude Code for the planning sophistication and add ChatGPT Plus ($20/mo) only when they hit a workload Claude Code is poor at, at which point they’re effectively running the driver/worker pattern at a small scale.

Can I use Claude Code’s CLAUDE.md context with Codex?

Not directly. Codex reads from ~/.codex/skills/. The practical workaround is the cross-pollination pattern: ask Codex to study your CLAUDE.md and your Claude Code plugins, then generate equivalent skills under ~/.codex/skills. The Skills standard is converging across both tools, so over time this is becoming more portable, but as of April 2026 you’re still translating between formats.

What is the harness effect, and why does it matter for the driver/worker pattern?

The harness effect is the capability gap between the same model running in two different harnesses. Matt Mayer’s research found Claude Opus scoring 77% in Claude Code and 93% in Cursor on identical tasks, with 16 percentage points coming purely from the harness. CORE-Bench found a 36-point gap in similar testing. The implication for the driver/worker pattern: nesting harnesses stacks the harness gains rather than averaging them. The driver gets one wrapper’s planning capability; the worker gets another’s terminal autonomy and token efficiency. That’s what makes the topology compound rather than dilute.

Are there open-source alternatives to Claude Code and Codex?

Yes. OpenCode is the most prominent: open-source with an apply_patch tool tuned for Codex-model performance. Archon is the open-source harness builder for orchestrating multiple coding agents. The Skills standard (Anthropic-originated, now multi-tool) makes cross-tool portability practical. The awesome-harness-engineering GitHub repo is the canonical inventory. We currently run BEADS+Metaswarm on top of Claude Code as the driver and Codex as the worker; the framework choice is fluid.

How long does it take a team to adopt the driver/worker workflow?

Roughly 90 days from cold start to measured rollout. Two weeks for the first engineer to get fluent on the driver alone. Two more weeks to add the worker and calibrate the delegation pattern for that codebase. Four weeks of team rollout. Four weeks of measurement before deciding whether to keep the framework or swap it. The full playbook is in the section above.

Last updated: April 2026. Both Codex and Claude Code update frequently, and the framework layer (BEADS+Metaswarm, Archon, OpenCode, others) moves faster than either model. We’ll refresh this article as Opus 4.8 and GPT-5.6 land, and as the framework choice changes.

Agentic Engineering Is Here: What Karpathy’s Naming Means for Your AI Investment

Sebastian Chedal — Tue, 28 Apr 2026 18:12:15 +0000

Your team adopted AI coding tools six months ago. Are they actually faster?

If the answer is ambiguous, you’re in good company. The productivity claims for AI-assisted development have ranged from 55-88% improvement (early Copilot studies) down to negative results for experienced engineers working on codebases they know well. The gap between those numbers isn’t a measurement error. It describes two different situations, and the difference shapes every AI investment decision.

In February 2026, Andrej Karpathy gave this gap a name. He proposed retiring the term “vibe coding” and replacing it with something more precise: agentic engineering. Within weeks, monthly searches for the term grew from a few hundred to nearly 3,000. The naming stuck because the discipline behind it has its own skills, failure modes, and quality standards, distinct from both traditional software engineering and from casual AI prompting.

What Karpathy Actually Said (And Why the Language Matters)

Karpathy’s framing:

“Agentic because the new default is that you are not writing the code directly 99% of the time, you are orchestrating agents who do and acting as oversight. Engineering to emphasize that there is an art & science and expertise to it.”

Two things are happening in that sentence. First, the default mode of working has changed: instead of a developer writing code, a developer is directing agents that write code and then reviewing what comes back. Second, that orchestration takes expertise. It is not just a different interface for the same work. It’s a different discipline with its own skills, failure modes, and quality standards.

Vibe coding was the early name for “give the AI a rough idea of what you want and see what it generates.” It worked well for prototypes, demos, and things that didn’t need to survive contact with reality. Agentic engineering is what you need when the output has to actually hold up.

When a field gets a name that distinguishes craft from carelessness, it usually means the field is serious enough to have developed standards. That’s now true of this one.

The Productivity Paradox Business Leaders Need to Understand

The productivity claims for AI-assisted development have ranged from 55-88% improvement (early Copilot studies from 2023-2024) down to zero or negative. A METR study from mid-2025 found that experienced open-source developers were approximately 20% slower when using AI tools on their own codebases. The study ran 16 developers across real repositories averaging 22,000 GitHub stars, not toy projects.

Research by Yegor Denisov-Blanch at Stanford puts the median productivity lift at 10-15%, not the 55-88% figure that circulated in early coverage.

These numbers don’t contradict each other. They describe different situations. The high-end figures came from developers using AI on unfamiliar tasks: generating boilerplate, writing documentation, producing code in languages they knew less well. The lower or negative figures came from experienced developers working on complex codebases they already understood deeply. There, AI interrupted their flow more than it accelerated it.

Addy Osmani’s practitioner analysis states it directly: “Agentic engineering disproportionately benefits senior engineers. If you have deep fundamentals, you can leverage AI as a massive force multiplier.” The inverse is also true. Developers who use AI to skip fundamentals accumulate invisible debt. Code that demos fine fails six months later when something needs to change and nobody understands the underlying structure.

According to IBM’s coverage of the Stack Overflow 2025 Developer Survey, 84% of developers use or intend to use AI-assisted programming, but only 3% say they “highly trust” AI-generated output. The people closest to the tools are the least convinced by them. Seasoned engineers reported the lowest rate of high trust (2.6%) and the highest rate of high distrust (20%). The developers who are best positioned to use these tools well are also the most skeptical of what the tools produce. That caution is itself a core agentic engineering practice.

ROI from agentic engineering depends far more on the skill of the orchestrator than on the cost of the AI tools. A senior engineer or a team that has put in the deliberate practice required will get dramatically different results than someone who installed an AI extension and called it done. Tool cost is nearly irrelevant. The human running the system determines the outcome.

Two Things People Call Agentic Engineering (That Are Very Different)

The term is being used for two distinct applications. They share a methodology but produce different value and require different evaluation criteria.

The first meaning is the one Karpathy coined: an engineering team using AI agents to write, test, and refine code. The human developer orchestrates the agents, reviews outputs, sets standards, and owns the final system. This applies to software product teams building applications.

The second meaning is newer and gets far less coverage: agents performing specific business functions end-to-end. Content production, research, data analysis, customer operations, process automation. No code is being written. Business work is being done. The orchestration discipline is the same, but the domain is operational rather than technical.

If you’re evaluating a software development firm’s claim to “do agentic engineering,” you should be asking about their code review processes, their testing methodology, and how they handle agent-generated code that fails quietly. If you’re evaluating a vendor claiming to use agentic engineering for business operations, you should be asking about their quality gates, their output validation processes, and what their failure response looks like.

The skills required are also different. Agentic engineering for software development requires deep engineering fundamentals. Agentic engineering for business operations requires deep domain expertise in whatever function the agent is performing, plus the architectural knowledge to design systems that catch their own errors.

What Agentic Engineering for Business Operations Actually Looks Like

Most coverage of agentic engineering is developer-facing. The same discipline applies to ongoing business operations, and one worked example is the pipeline that produced this article.

The article you are reading started as a content brief produced by our SEO research agent. The brief contained a target keyword cluster, a competitive analysis of the top ten SERP results, and a set of source links to anchor factual claims. The brief is the spec. Without it, the writing agent would be generating content from vibes, not from data. The task is designed before the agent touches it.

Once the brief was approved, the writing agent loaded it along with the company’s brand voice rules, positioning documents, and recent article history. The agent writes a first draft, but the draft does not go to the human yet. It passes through a self-review stage where the same agent evaluates the draft against the voice guide, checking for banned patterns (guru framing, AI-sounding repetition, dramatic setups), verifying that every specific claim has a source, and flagging sections that feel thin. The review generates a report.

Anthropic’s research on multi-agent harnesses surfaces the same pattern: when an agent is asked to evaluate work it produced, it tends toward confident self-approval rather than honest critique. Their engineering team published a reference architecture for this exact challenge, a planner, generator, and evaluator in sequence, and their finding was blunt: agents that generate content “confidently praise” their own output even when quality is mediocre. The solution is architectural: separate the generator from the evaluator so they’re not the same system assessing its own work.

In our pipeline, the structural answer to this problem is adversarial review. After self-review, the draft goes to a separate review stage that evaluates it from a different angle: not “does this match the voice guide” but “does this article add something new that a reader couldn’t get from the other nine results on the SERP.” A single agent reviewing its own work will miss things. Two stages with different evaluation criteria catch more. The generator and the evaluator have to be structurally separate.

Once the review passes, the human editor, Sebastian in our case, reads the final draft. He approves, requests changes, or rejects. The human owns the output even though an agent produced the draft. The approval is not a formality. Articles come back with revision instructions regularly, and the revision loop runs until the human is satisfied.

The article then moves through art direction (image generation based on brand visual guidelines), deduplication checking (ensuring this article doesn’t repeat the same proof points as the last three published pieces), and finally publication to WordPress. At each stage, defined quality gates determine whether the article advances or goes back. The article doesn’t flow forward because someone clicked approve. It flows forward because it passed a mechanical check.

This is one article. The same pipeline runs dozens of pieces per month. The same architectural shape, spec, generate, review, gate, publish, runs our software development pipeline, our SEO research, and the systems we build for clients. The vocabulary changes (“article” instead of “PR,” “editorial review” instead of “code review”), but the engineering posture is identical.

For longer worked examples, see our case studies on the Voice Intelligence Platform (telephony + AI orchestration, zero human-written code) and the Hydraulic 3D Simulation (18,000 lines of physics code, $360 in API spend).

Agentic engineering for business operations is orchestration design. The AI capability matters, but the system design, how tasks move, how quality is assessed, how errors get caught before they propagate, is where the engineering lives.

The 5 Signs Your Team (or Vendor) Is Actually Doing Agentic Engineering

Five markers separate professional practice from label adoption:

They start with a spec, not a prompt. Agentic engineering requires designing the task before AI touches it: what inputs, what outputs, what quality criteria, what failure modes. If someone jumps straight to prompting without this design phase, that’s vibe coding with extra steps, not agentic engineering.
They review every output every time through a defined process, not spot-checks. Systematic validation. The human owns the output even if an agent created it. A team genuinely doing agentic engineering will have a clear answer to “what is your output review process.” A team that isn’t will talk about how good the AI is.
They have quality gates, not just outputs. Results pass through defined criteria before moving to the next stage. Automated tests, structured review rubrics, or a validation step that must pass before handoff. If every stage produces output that flows directly to the next stage without validation, that’s a pipeline, not engineering.
They can explain what went wrong. Production agentic systems fail. The failure stories are the proof of production experience. A practitioner running real systems can tell you how a specific run failed, why it failed, and what changed in response. If someone has no failure stories, they have no production systems.
Their agents do boring work reliably. The best agentic systems are optimized for repeatability, not just capability. A system that produces impressive output occasionally is a demo. A system that produces good-enough output consistently is engineering. If every run requires significant cleanup, it’s not there yet.

These questions work for evaluating internal teams and vendors equally. The answers reveal whether someone has worked through the hard parts of production deployment, or is still describing what the technology is theoretically capable of.

What This Means for Your AI Budget in 2026

Agentic engineering is not a tool you buy. It’s a capability you build, hire, or contract for. The AI subscriptions are a small part of the cost. The capability to orchestrate, validate, and run systems reliably is where the investment goes. Three paths get you there:

Build the capability in-house. This requires hiring engineers who understand both the domain and the orchestration layer. Practitioner analysis suggests consistent productivity gains require roughly 30-100 hours of deliberate practice per person. This is not something that comes from onboarding documentation. Expect a real ramp time before the investment returns measurable value. The payoff, when it arrives, compounds: a senior engineer running agentic workflows can handle workloads that would otherwise require multiple people. The risk: if that engineer leaves, the capability leaves with them. For companies with thin technical teams, this is the strongest argument for the other two paths.

Train your existing team. Structured training on agentic development, how to design tasks, validate outputs, and build quality gates, accelerates the learning curve significantly. This is what our agentic coding workshops are built to do: take developers who understand their domain and give them the orchestration discipline that makes their AI use productive rather than risky. Training distributes the knowledge across the team rather than concentrating it in one person, which mitigates the key-person risk.

Contract with a team already running production systems. This is the lowest-risk path if the need is immediate. The cost is real, but you’re paying for operational depth, not just AI access. The key question to ask any vendor: “Show me a production system you’ve been running for more than six months. What failed, and what did you fix?” The answer tells you more than any capability list. If you’re evaluating this path, our agentic development services are built on production systems that have been running and failing and improving for well over a year.

Production agentic systems for business operations are not expensive to run once they’re built. The AI infrastructure cost is a fraction of what the equivalent human work would cost. The investment is in building and validating the system, not in running it. A well-designed agentic system runs at a fraction of the cost of manual execution. This holds only after the engineering work is done correctly.

The Consensus Behind the Name

Karpathy’s naming didn’t create this paradigm. It named something that was already developing. What makes early 2026 a meaningful moment is that three independent signals converged on the same conclusion within weeks of each other.

Karpathy named the discipline from the practitioner developer community. Separately, Anthropic published a reference architecture for multi-agent systems, the planner/generator/evaluator design they developed through running production multi-hour autonomous coding sessions. And Cloudflare launched their Agents Week, announcing infrastructure specifically designed for agentic workloads, built on the premise that agents require one-to-one compute isolation that the container model can’t provide efficiently at scale.

The model creator named the discipline. A leading AI lab published its reference architecture. A major infrastructure provider built the plumbing for it. When those three things happen independently in the same month, the paradigm is established rather than emerging.

Whether agentic engineering is established is no longer the question. How quickly your organization needs to develop or access the capability is, and which of the three paths fits your current team and timeline.

FAQ

Is agentic engineering the same as vibe coding?

No. Vibe coding describes generating code through informal prompting without systematic validation: the AI builds something, you hope it works. Agentic engineering describes orchestrating AI agents with professional discipline: designing tasks before executing them, validating outputs systematically, and maintaining human ownership of results. Vibe coding produces prototypes. Agentic engineering produces systems that hold up.

What skills do you need to do agentic engineering?

For software development: deep software engineering fundamentals plus the discipline to design, validate, and own AI-generated outputs. For business operations: deep domain expertise in whatever function the agent is performing, plus architectural knowledge of how to build multi-agent systems with reliable quality gates. In both cases, senior-level mastery of the underlying domain is the prerequisite. AI amplifies that expertise; it doesn’t substitute for it.

How long does it take to see productivity gains from agentic engineering?

Practitioner research suggests 30-100 hours of deliberate practice before consistent gains appear. That’s per person, per domain. The gains compound over time: once the orchestration patterns are internalized, the productivity differential between AI-augmented and non-augmented work becomes substantial. Expecting immediate returns from minimal onboarding will produce disappointment, not results.

Can agentic engineering be applied to business operations, not just software development?

Yes. This is the use case that gets least coverage. Agents can perform specific business functions end-to-end: content production, market research, data analysis, customer operations, knowledge management, process documentation. The orchestration discipline is identical; the domain expertise required shifts to match the function. We design and deploy these systems, and the methodology is the same as for software: spec the task, validate the output, gate the handoffs.

What’s the difference between agentic engineering and AI automation?

AI automation describes rule-based or AI-assisted workflows where the logic is predefined and the AI fills in specific tasks within that logic. Agentic engineering involves agents that make judgment calls, handle exceptions, and operate across long-horizon tasks with minimal handholding. The boundary is blurring, but the distinction is useful: automation executes defined steps; agentic engineering handles the steps that aren’t fully defined in advance.

How do I evaluate whether a vendor is actually doing agentic engineering?

Ask for their failure stories. Ask how their output review process works and who is accountable for results. Ask what their quality gates look like. A vendor running production agentic systems will have specific, concrete answers, including what broke, when, and what changed. A vendor who has adopted the terminology without the practice will describe capabilities and architectures. The difference in response texture is usually clear within a few questions.

Two AI Subscriptions and 150GB of Government Data: What the Mexico Breach Means for Every Business Running AI

Sebastian Chedal — Sat, 25 Apr 2026 18:07:25 +0000

Between December 2025 and February 2026, one person used two consumer AI subscriptions to breach nine Mexican government agencies, steal about 150GB of sensitive data, and expose roughly 195 million taxpayer records. No malware team. No nation-state. No custom infrastructure. A single operator, a Claude account, a ChatGPT account, and about six weeks.

The forensic detail matters because it rewrites the threat model every business running AI agents is operating under. Gambit Security’s investigation logged 1,088 attacker prompts that generated 5,317 AI-executed commands across 34 sessions, with Claude producing about 75% of the remote commands. The underlying vulnerabilities were conventional, the kind any patch cycle could have closed. What was new was the speed and the operator. That’s what this article is about.

In this article:

What actually happened in the Mexico breach, in plain language
Why HawkEye’s “persistent average attacker” concept changes the threat model for every AI deployment
Three lessons from the breach that apply directly to any business running agents
Five governance steps you can put in place this week, from a team running 9 production agents
What the EU AI Act’s August 2026 deadline means for the window you have to act

What Actually Happened

The campaign opened on December 27, 2025 with a social engineering move. The attacker contacted Mexican federal agencies claiming to be a legitimate bug bounty researcher. Once inside the network perimeter, they fed Claude a 1,084-line “hacking manual” that coached the model on operating stealthily, deleting history files, and acting as an elite offensive researcher. When Claude hit guardrails, the attacker rephrased. When it refused entirely, they switched to ChatGPT for the same task. Cross-platform evasion turned out to be trivial.

Over six weeks, the operation compromised the federal tax authority, the electoral institute, four state governments, a water utility, and a financial institution. At the tax authority (SAT), the attacker accessed 195 million taxpayer records and stood up a fake tax certificate service for monetization. In Mexico City, they used a scheduled task to install a persistent key, then took control of roughly 220 million civil records. In Jalisco, they seized an entire 13-node Nutanix cluster hosting health records and domestic violence victim data.

The scale is what the forensic report makes concrete. The attacker wrote a 17,550-line Python script (BACKUPOSINT.py) that piped stolen data through the OpenAI API for analysis, producing 2,597 structured intelligence reports across 305 internal servers. Gambit counted 400+ custom attack scripts, 301 in Bash, 113 in Python. Twenty tailored exploits targeted twenty specific, known CVEs. None of these are new categories of vulnerability. The CVEs existed before AI. The patches existed before AI. What didn’t exist before AI was a single person converting them into a working intelligence pipeline in six weeks.

As Paubox put it in their summary, “AI didn’t just assist, it functioned as the operational team: writing exploits, building tools, automating exfiltration.”

The Persistent Average Attacker

HawkEye’s analysts coined a phrase in their writeup that’s worth sitting with. In the final paragraph of their breach analysis, they wrote:

“Security teams that are still calibrating their defenses around what an elite attacker can do need to recalibrate around what a persistent, average one can now accomplish with AI assistance.”

The concept is the intellectual contribution of this incident. Security programs are built around threat tiers: script kiddies at the bottom, organized crime in the middle, advanced persistent threats at the top. Resources flow to defending against the top tier, because the top tier is assumed to be where creative exploitation, novel tooling, and team-level output live. The Mexico breach inverts that. A single person with a $20/month subscription produced team-level output. The operator wasn’t elite. They were patient.

The supporting data is consistent across independent sources. Arkose Labs surveyed 300 enterprise leaders and found 97% expect a material AI-agent-driven security or fraud incident within 12 months, with nearly half expecting one within six. Google’s Cybersecurity Forecast 2026 reports that more than 80% of employees use unapproved AI tools at work, with fewer than 20% using only company-approved AI. Bessemer’s 2026 analysis cites IBM’s Cost of a Data Breach Report showing shadow AI breaches cost an average of $4.63 million, about $670,000 more than a standard breach.

None of those numbers describe a sophisticated adversary. They describe ordinary people with consumer AI tools operating at scales that used to require teams.

Three Lessons From the Breach

Three patterns in the Mexico incident generalize to any business running AI.

1. AI Tools Can’t Tell Authorized From Unauthorized Use

Claude didn’t know it was helping an attacker until the conversation pattern tripped a safety heuristic. When it refused, the attacker rephrased. When Claude refused again, the attacker moved the same task to ChatGPT. This is an important thing to internalize: model safety training is probabilistic, and an operator who treats guardrails as obstacles to route around will, given enough tries, route around them. Model vendors are aware of this and Anthropic actually kicked the attacker off twice. The attacker just came back with a new account.

For businesses, the implication is not “pick a safer model.” Every major provider has the same property. The implication is that model-level safety is one layer among several, and it cannot be the only layer. Anything you rely on a model refusing to do should also be something your infrastructure refuses to execute.

2. The Vulnerabilities Were Old. The Attack Speed Was New.

The twenty CVEs the attacker exploited were standard. They had patches available. The government agencies had the same profile any mid-market company has: a backlog of known vulnerabilities, limited patching bandwidth, and the assumption that exploitation of conventional bugs is slow enough to catch in a review cycle. What AI changed was the compression of the exploit-to-exfiltration timeline. A vulnerability assessment to working exfiltration path now fits in a single afternoon instead of a multi-week project.

If your organization runs a mature vulnerability management program, the pace of that program may no longer match the pace of attack. If your organization runs an immature one, the gap is worse. The practical consequence is that “we’ll patch it in the next cycle” is no longer a defensible answer for anything that’s both exposed and exploitable.

3. A Single Operator Produced Team-Level Output

The 305 servers, 2,597 intelligence reports, and 400+ attack scripts would, pre-AI, require a team. Here they came from one person. This compression of attacker capability is permanent. It is not a one-off. The playbook is now public, which means the technical barrier to repeating it is how quickly a motivated operator can read a few forensic writeups.

For defense, this means the traffic profile of an attack may no longer match the expected signature of a solo actor. An alerting system that triages “probable bot scan,” “probable insider error,” and “probable team-scale operation” needs to rethink the middle category. A lot of future incidents will look like team-scale operations conducted by one person.

What This Means If You’re Running AI Agents

There’s a clean asymmetry between how this breach is usually read and how business leaders deploying agents should read it. The usual reading is “attackers are using AI, so I need better defensive AI.” The more useful reading is that the breach is a preview of what an ungoverned agent inside your own environment can do when something goes wrong, whether that something is a compromised prompt, an embedded malicious instruction in a document, or a confused integration.

A production AI agent is, by design, an operator. It has credentials, it acts on systems, it chains tool calls, and it’s fast. If an attacker can use consumer AI from outside your perimeter to compromise government networks, the risk profile of an AI agent you’ve already placed inside your perimeter, connected to production systems, is not smaller. It’s the same capability, pointed inward.

Three risk categories are worth naming for any business running agents:

Agents as targets. Prompt injection, tool-call hijacking, and data exfiltration through an agent’s own legitimate channels. The attacker doesn’t breach your perimeter, they submit a support ticket.
Agents as amplifiers. An agent with broad permissions plus a compromised instruction equals an internal Mexico breach at compressed speed. This is the scenario Bessemer’s analysis highlighted when citing McKinsey’s “Lilli” AI platform being compromised by an autonomous agent in under two hours.
Shadow agents. The Google statistic (80% of employees using unapproved AI) translates directly into people standing up agents with personal accounts, connecting them to company data through browser extensions, MCP servers, and SaaS integrations, with no IT visibility.

Arkose’s survey is worth reading alongside this. 57% of organizations have no formal governance controls for AI agents. Only 6% of security budgets are allocated to AI-agent risk. The gap between expected incidents (97%) and allocated resources (6%) is the gap every mid-market security program is quietly running today.

Five Things to Do This Week

We run 9 production AI agents at Fountain City on a documented governance architecture that costs us roughly $450 to $600 per month to operate. The specific thresholds, circuit-breaker design, and trip logic are documented in our cost circuit breaker article, and the broader hardening stack lives in our AI agent security hardening guide. The five items below are the concrete governance moves that map directly onto the failure modes the Mexico breach illustrated, written for a business leader who has an agent program and wants to tighten it this week.

1. Inventory Every Agent, Tool, and AI Subscription

You can’t govern what you haven’t counted. The inventory is not just the agents IT approved. It’s every browser extension using OpenAI, every Claude subscription on a corporate card, every Zapier flow with an AI step, every sales rep using a “just for notes” AI notetaker that is, technically, a recording and transcription agent connected to your meetings. If the Google statistic holds in your company, the real count is four to five times whatever IT has on its list.

A week-one inventory doesn’t need to be perfect. It needs to exist, be dated, and get reviewed.

2. Put a Spending Cap on Everything That Calls an API

The Mexico attacker had no spending cap. If they had, the 5,317 commands and 2,597 intelligence reports would have tripped a halt well before the breach completed. Runaway cost is the most reliable early signal of misuse, whether the misuse is a bug, a compromised prompt, or an insider experimenting outside policy.

Our thresholds are documented in the cost circuit breaker article linked above. The exact numbers matter less than the fact that they exist and enforce. If your current architecture can’t halt an agent on spend, that’s a week-one fix.

3. Pin Models and Keep Low-Cost Models Out of Critical Roles

Model selection is a security decision, not just a cost decision. Pin specific model versions to specific tasks, so a capability change in the model doesn’t silently expand what your agent can do. And don’t let the cheapest models run anything critical. Lower-tier models are more prone to pattern errors and more susceptible to prompt injection, which means giving them access to production systems or sensitive data is a policy decision that should be made explicitly, not by default.

General rule: the model tier should be calibrated to the blast radius of the task, not to the price list.

4. Require Comprehensive Audit Trails

The Mexico breach was discovered in part because the attacker’s own conversation logs were publicly accessible from a misconfigured server. That’s the low bar. The high bar is: every prompt into every production agent, every tool call it makes, every data source it touches, every output it produces, logged in a form that supports both real-time anomaly detection and after-the-fact forensics.

This is boring, expensive, and non-negotiable. If a future incident traces back to one of your agents, the first question will be “show me what it did.” The answer “we don’t have logs going back that far” is the answer that becomes the press quote.

5. Separate Agent Permissions by Task

The government agencies gave broad system access to accounts that ended up compromised. The lesson is the oldest one in security, just applied to a new class of principal. Each agent should get only the permissions it needs for its specific job. Read-only where read-only works. Per-environment scoping where cross-environment access isn’t required. Timeouts on sessions so a compromised agent doesn’t have an unlimited runway.

Least privilege isn’t just for employees anymore. An agent is an actor with credentials. Treat it as one.

The Window Is Closing, But Not for the Reasons You Think

The urgency here is that the Mexico breach is now a template. Every forensic writeup, every reconstruction of the attacker’s workflow, every public conference talk about the incident shortens the distance between “motivated operator” and “working offensive pipeline.” The technical floor has dropped.

The regulatory floor is rising at the same time. Full enforcement of the EU AI Act lands in August 2026. For any business with European exposure, that’s a hard date by which “we were still figuring out governance” stops being an acceptable answer. For US-only businesses, the state-level regulation following EU precedent will run on a similar timeline, measured in quarters not years.

The companies that will scale AI agents safely are the ones that treat governance as part of the build, not part of the cleanup. The rest will be case studies. You probably already know which one you want to be. The question is whether you have your inventory done, your spending caps live, your models pinned, your logs complete, and your permissions scoped, by the end of the quarter.

If you want a second set of eyes on where your program sits against this threat model, our AI Risk and Security Assessment is the structured version of the conversation we’re having in the second half of this article. It covers inventory, spending posture, model selection, logging depth, and permission scoping against your actual deployment.

Frequently Asked Questions

Was the Mexico breach carried out by a sophisticated hacker?

No. According to Gambit Security’s forensic analysis, the operation was run by a single individual with no identified nation-state or organized crime connection. The attacker used consumer Claude and ChatGPT subscriptions, exploited twenty known CVEs with existing patches, and relied on AI to generate the custom tooling. The significance of the incident is that it didn’t require sophistication.

Can consumer AI tools like Claude and ChatGPT be used to attack my business?

Yes, but the pattern to worry about is not “AI creates novel vulnerabilities in your systems.” It’s “AI dramatically compresses the time from discovering a conventional vulnerability in your systems to exploiting it.” The defensive implication is that patching cadences, alert latencies, and vulnerability management cycles that were adequate at pre-AI attacker speed may no longer be adequate at post-AI attacker speed.

What is the “persistent average attacker” and why does it matter?

The phrase comes from HawkEye’s analysis of the Mexico breach. It describes an operator who is not elite, not backed by a team, and not using novel techniques, but who is patient and equipped with AI. The reason it matters is that most security programs are calibrated around sophisticated adversaries. The Mexico incident demonstrated that an ordinary person with consumer AI tools can now produce team-level output. Defenses calibrated only for the top of the threat pyramid will underprotect against the much larger population that just got an order-of-magnitude capability boost.

How much does AI agent governance actually cost?

Less than people assume. Our own governance stack (logging, cost circuit breakers, model pinning, audit trails) runs at a small percentage of total operating cost across the agents we run in production. Governance is a small line item, and a small fraction of the cost of even a minor incident. IBM’s 2025 data, cited by Bessemer, puts shadow AI breaches at about $4.63 million per incident on average.

Does a small or mid-size business need to worry about this?

Yes. Mid-market companies typically have more ungoverned AI usage than enterprise, with fewer resources to detect misuse. The Google statistic (80% of employees using unapproved AI) holds across company sizes, which means the inventory problem is proportionally worse at smaller organizations that don’t have a dedicated AI governance function. The good news is that the first three of the five governance moves above are operational, not technical, and can be started this week without any new tooling.

What’s the single most important thing to do right now?

Inventory. You can’t cap spend, pin models, log activity, or scope permissions for agents you don’t know exist. Every governance move downstream depends on knowing what’s running. Start there, and the rest of the program has somewhere to attach.

"Build, Don't Buy" AI Agents: A Practitioner's Guide to Replacing SaaS

Sebastian Chedal — Thu, 23 Apr 2026 18:09:18 +0000

The Build vs. Buy Question Has Changed

Two signals landed in the same week. A CIO.com report showed enterprises spending $280 million annually on 600+ SaaS applications. And a solopreneur documented 33 custom AI agents running her entire business for $10-20 a month.

Enterprise and solo operators arrived at the same question independently: why am I paying for software I barely use when I could build exactly what I need?

The old rule was simple. Buy software for anything that isn't your core competency. It was good advice when building meant hiring a development team, managing servers, and maintaining code. But AI agents have shifted the economics. A custom agent that does one job well can now cost less to build and run than the SaaS subscription it replaces.

That doesn't mean "always build" is the new rule. It means the decision framework has changed, and most of the content out there is either a vendor selling you their platform or a dev shop selling you a build engagement. What follows is the practitioner's version, based on building these systems for clients and running them internally.

The SaaS Replacement Decision Framework

Build-vs-buy is a decades-old IT decision. Lemkin's 90/10 rule is directionally correct for the AI agent era. The CIO.com enterprise analysis focuses on spend optimization at scale. Both frameworks answer "should I consider replacing SaaS with agents?" What they don't answer is: which specific tools should I replace, and in what order? That's the practitioner gap. The four factors below are what we use to evaluate every SaaS tool in a client's stack. They're derived from the same economic logic as Lemkin's rule and the CIO analysis, but refined by what we've actually seen in production builds.

Factor 1: Feature Utilization Rate

Large enterprises run 600+ SaaS applications. Mid-market companies maintain smaller stacks, but the pattern is the same: for any given tool, the typical team uses 10-15% of available features. You're paying for a content platform with 200 features when you need 12 of them. A custom agent built around those 12 features costs a fraction of the subscription and does exactly what your workflow requires.

The trigger: if your team has never opened half the tabs in a tool's interface, that tool is a replacement candidate.

Factor 2: Data Lock-in Exposure

Some SaaS tools hold your data in formats that make leaving expensive. CRM systems with years of interaction history. Project management tools where your entire operational knowledge lives in proprietary fields. A client's entire sales history lives in a CRM's proprietary deal stages. Migrating that data to a new system means manually remapping three years of pipeline data, custom fields, and automation triggers. The longer you stay, the more leverage the vendor has on pricing, and a custom agent that processes and stores data in formats you control eliminates vendor lock-in entirely. This factor weighs heavier the more proprietary data the tool accumulates.

Factor 3: Integration Friction

Count how many Zapier connections, middleware layers, or custom API bridges you maintain to keep your tools talking to each other. Each integration is a maintenance surface and a failure point. One client maintained six Zapier connections and a custom webhook to keep their CRM, invoicing, and website analytics in sync. When one connection broke, the downstream data was silently wrong for two weeks before anyone noticed. When three SaaS tools need a middleware layer to work together, the total system cost includes the tools, the middleware, and the engineering time to keep the connections running.

A purpose-built agent that handles the entire workflow natively eliminates the integration layer. The savings compound as the number of connected tools grows.

Factor 4: AI Readiness of the Vendor

This one comes from Jason Lemkin at SaaStr: "If it's February 2026 and your product has zero AI features, that's your signal to start building." A SaaS tool that hasn't shipped meaningful AI capabilities by now is running on legacy architecture. That vendor is either unable or unwilling to evolve. Your custom replacement will outpace them within months.

But there's a nuance. Some vendors have shipped AI features, but they're shallow. A CRM that added "AI-powered insights" that's really just a GPT wrapper over your data. A content platform that added "AI writing" that produces generic copy with no access to your brand voice rules, no integration with your knowledge base, and no connection to the rest of your content workflow. The useful version of AI readiness is a spectrum: no AI features at all (clear replacement candidate), bolted-on AI (checkbox feature, not workflow-integrated, limited utility), and deeply integrated AI (core to the product, meaningfully changes how you use the tool). Only the third category is a strong argument for keeping the SaaS tool. The second is actually the most dangerous, because the vendor can claim "we have AI" while the actual capability is superficial, and the buyer feels locked in because "they're working on it."

Score each tool against these four factors. Two or more red flags and the tool belongs on your replacement shortlist. Gartner projects 35% of current SaaS tools will be replaced or absorbed by 2030, and the companies making that shift are the ones evaluating their stacks methodically rather than reactively.

The Framework in Practice: A Real Build Decision

A client needed a data intelligence platform that provides full customer journey analytics across five interconnected systems: HubSpot (CRM, deals, marketing), QuickBooks (invoicing, revenue), WooCommerce (e-commerce orders), website analytics (visitor behavior, forms, repeat visits), and ad platforms (LinkedIn/YouTube retargeting with UTM tracking).

The feature list was ambitious: complete customer journey visualization across every touchpoint, individual customer journey flow charts, path-to-product analysis (what journey leads to a specific product purchase), UTM source-to-sale attribution, action-to-conversion analysis (which behaviors predict purchase), ML prediction on future customer actions, and conversational BI that lets you talk to the data in natural language with charts and tables generated in chat.

The build uses Grist (open-source, self-hosted spreadsheet/database) as the data layer, connecting to all five systems through APIs, with AI agents handling conversational analytics and prediction. The project is in final testing, with most main features built.

Before building, we researched what the SaaS equivalent would cost.

No single SaaS platform covers the full scope. The client would need 2-4 platforms combined. A lean mid-market stack (Mixpanel or Amplitude, HubSpot Pro, a BI/chat layer) would run roughly $5,000-$20,000+ per year depending on event volume and seats. A revenue/marketing ops stack (HubSpot Enterprise, attribution tool, BI/chat layer) would cost roughly $15,000-$60,000+ per year. An enterprise journey suite (Adobe Customer Journey Analytics or Qualtrics XM/CX) would cost $25,000-$200,000+ annually, often much higher with implementation. And setup effort for the SaaS route: 60-150+ hours for cross-system implementation that unifies QuickBooks, HubSpot, WooCommerce, website events, UTMs, and retargeting touchpoints. The hard part isn't clicking buttons in the product. It's identity resolution, naming conventions, backfills, event design, data QA, and reporting logic.

The client never built this capability before because the SaaS route was unaffordable.

Scored against the four factors:

Feature utilization: Low. No single SaaS tool covers the full scope (journey analytics, CRM, invoicing, attribution, conversational BI, ML prediction). The client would use a fraction of each platform and still have gaps.
Data lock-in: High risk. Customer journey data fragmented across 2-4 vendors in proprietary formats. Leaving any one of them means losing part of the customer picture.
Integration friction: Extreme. The SaaS research estimated 60-150+ hours just for cross-system identity resolution and data integration. Each platform connection is a maintenance surface.
AI readiness: Weak in mid-market tools. Conversational BI and ML prediction are either premium add-ons, require separate platforms, or don't exist in the tools that cover the other needs.

All four factors flagged red. The framework predicted that building would win on every dimension.

The actual build cost: under $10,000 for design, development, and testing. Monthly operating cost under $150 (hosting at roughly $100/month plus AI tokens at roughly $50/month after the first month stabilizes; first month token costs are higher at roughly $200 during setup and tuning). Annual operating cost: roughly $1,800/year.

The comparison is stark. Year 1: roughly $11,500 total (build + operating) versus $11,000-$35,000 for the leanest SaaS option (subscription + 60-150 hours of setup labor at $100/hour). The enterprise SaaS route ($25,000-$200,000+ annually plus implementation) doesn't bear comparison. Year 2 onward: roughly $1,800/year versus $5,000-$20,000/year in SaaS subscriptions, which will have increased by then. The gap widens every year.

The client now has full customer journey analytics, conversational BI, ML prediction, and cross-system attribution, capabilities that in the SaaS world either don't exist in the mid-market tier or require $25,000+ enterprise suites. The custom build connects all five systems natively through a single data layer, eliminating the middleware and identity-stitching overhead that makes the SaaS route expensive.

What to Build First: The Replacement Sequence

The biggest mistake in SaaS replacement is starting with the highest-stakes tools. Companies that try to replace their customer support platform or CRM first tend to stall. The implementation is complex, the failure consequences are visible, and the team hasn't built any operational muscle for running custom systems.

A better sequence:

Tier 1: Internal tools you touch daily. Reporting dashboards, research workflows, content production, internal knowledge bases. These affect only your team. If something breaks, the customer never sees it. This is where you learn how to operate custom agents with minimal risk.

We followed this progression ourselves. Our first custom agents replaced internal content production workflows — research aggregation, draft generation, cross-article quality checks. The stakes were low enough to learn from every failure, and the operational patterns we developed there became the foundation for everything we build for clients.

Tier 2: Customer-adjacent tools. CRM enrichment, lead scoring, proposal generation, support triage that routes to humans. These touch customer data but don't face customers directly. Failures are catchable before they reach anyone external.

Tier 3: Customer-facing tools. Portals, communication interfaces, interactive tools. Only attempt these after you've operated Tier 1 and Tier 2 systems long enough to understand the maintenance patterns. SaaStr's Jason Lemkin replaced a sponsors portal that had been costing $5,000-$10,000 annually, but he did it after months of building internal tools first.

The principle is straightforward: start where the cost of failure is lowest and the learning value is highest.

What NOT to Build: The Keep List

The honest answer to "build or buy" includes a list of things you should never build, even when the technology makes it possible.

Compliance and regulatory tools. SOC2 audit trails, GDPR consent management, HIPAA documentation. The value of these tools is the vendor's legal and compliance team maintaining them as regulations change. Building your own means hiring that compliance expertise permanently.

Payment processing. Stripe, payment gateways, financial transaction systems. The security, fraud detection, and regulatory requirements make this a permanent cost center with no upside in building custom.

Identity and authentication. SSO providers, multi-factor auth, credential management. The attack surface is enormous and the liability is existential. Let specialists handle this.

Platform-native tools where the platform IS the value. If your entire sales operation runs on Salesforce, building a Salesforce replacement isn't a SaaS substitution. It's a business migration. These are different decisions with different economics.

Tools where vendor-managed security is the product. Email security, endpoint protection, network monitoring. You're paying for the vendor's threat intelligence and response team, not just the software.

SaaStr's "90/10 rule" is directionally correct: buy 90% of your tools, build the 10% where custom agents deliver disproportionate value. The framework above helps you identify which 10%.

The Agency Dimension: Build Once, Deploy for Ten Clients

The article so far frames build-vs-buy as a single-company decision. But agencies face a second dimension: should I build agent capabilities I can resell to my clients?

The economics are fundamentally different. An agency that builds a custom research agent for one client can deploy variants for ten clients. A $15,000 build that serves 10 clients at $500/month each pays for itself in three months and generates recurring revenue after that. The build cost amortizes across the client portfolio in a way that makes no sense for a single company.

The alternative is reselling a SaaS platform with agency branding. That makes the agency a middleman adding margin, not a builder creating proprietary value. When the SaaS vendor raises prices or changes features, the agency has no control. A custom build gives the agency full control over pricing, features, and the client relationship.

We see this pattern directly in our work. Agencies come to us because they want to offer AI agent capabilities to their clients without being dependent on a SaaS platform they don't control. The build-vs-buy framework applies the same way, but the breakeven math is faster because the build serves multiple revenue streams.

The Middle Ground: No-Code Agent Platforms

The choice isn't strictly binary. No-code agent platforms (Relevance AI, CrewAI, and similar tools) sit between full custom builds and off-the-shelf SaaS. They work well for simple, single-agent workflows with standard integrations: a research agent that queries public data, a content summarizer that processes feeds, a lead qualifier that works within your existing CRM.

They break down when you need multi-agent coordination, custom quality gates, deep integration with your specific data systems, or workflows that span multiple business domains. That gap, complex, multi-system, domain-specific agent work, is where custom builds operate. The four-factor framework still applies. If a no-code platform covers your needs without the lock-in and friction problems, it's a valid option. If it doesn't, you're back to the build-vs-SaaS decision.

The Real Economics: Build Costs vs. SaaS Subscriptions

Most cost comparisons in this space are unreliable. Enterprise vendors claim building costs $8.3 million over three years. Solopreneurs claim $10 a month in API costs. The reality depends entirely on scale and scope.

Cost Factor	Solopreneur	Mid-Market	Enterprise
Build Cost (one-time)	$0 – $500 (DIY)	$6K – $18K	$50K+
Monthly Operating	$10 – $50 API	$600 – $4K managed	$5K – $15K+
SaaS Equivalent	$100 – $500/mo	$2K – $10K/mo	$50K – $280K/yr
Breakeven Timeline	Immediate	3 – 9 months	6 – 18 months

The solopreneur numbers come from Kim Doyal, who runs 33 custom agents on $10-20 a month in API costs and reports a 75-80% reduction in time spent on repetitive work. These figures assume the builder is also the operator with technical skills, which is a different model from a mid-market team hiring an implementation partner. The mid-market numbers reflect what agentic development actually costs when an implementation partner handles the build and ongoing management. Enterprise ranges are directional, drawn from Clustox and industry benchmarks.

The critical number for mid-market buyers: at $2,000 a month in SaaS spend being replaced, an $18,000 build pays for itself in nine months. A $6,000 build breaks even in three. These numbers don't account for the value of owning your system, no vendor lock-in, no price increases, no feature changes you didn't ask for. The agent does exactly what you need and nothing else.

There's also a cost trajectory working in favor of custom builds that most comparisons miss. SaaS pricing only goes up. A tool that costs $500/month today will cost $600/month in two years because vendors raise prices. Custom agent API costs go down every six months as models get cheaper and more efficient. A custom agent that costs $200/month today will likely cost $120/month in two years. The cost crossover widens over time, not narrows. This is one of the strongest long-term arguments for building.

Three Mistakes That Kill SaaS Replacement Projects

Mistake 1: Replacing Customer-Facing Tools First

A company replacing their customer support chatbot before they've ever run a custom agent internally is making the highest-stakes bet with the least experience. When the agent produces an incorrect response, the customer sees it. When it goes down, the customer notices. Start with internal tools where failures are private and learning is cheap.

Mistake 2: Building What You Don't Understand

If nobody on your team can articulate why your current tool's workflow exists, a custom agent won't fix that. Agents automate processes. If the process itself is unclear, the agent will automate confusion faster. Before building a replacement, document the workflow the tool supports. Every step, every decision point, every exception. If you can't write it down, you can't automate it.

Mistake 3: Ignoring Maintenance Compounding

Jason Lemkin's most important observation from building 20+ custom tools: "Every app you build is an app you now have to maintain." Each custom system adds to your maintenance surface. API providers change their interfaces. Models update and produce different outputs. Edge cases accumulate.

Analysis from Clustox puts the numbers in sharper focus: first-year costs for AI-built systems run roughly 12% higher than initial estimates once you factor in code review overhead and a testing burden that's 1.7 times the norm. AI-generated code carries roughly double the code churn rate of traditional development, and by year two, cumulative maintenance costs can reach four times traditional levels as technical debt compounds. These figures are drawn from Clustox's build-vs-buy comparison for AI tools, which aggregates data across multiple enterprise deployments.

The mitigation: either budget for ongoing maintenance from day one, or work with an implementation partner who handles the maintenance surface for you. The second option converts an unpredictable engineering cost into a predictable monthly fee.

[Interactive chart on the original post.]

How to Get Started

The gap between "this sounds right" and "we actually replaced a SaaS tool" is narrower than it looks, but only if you approach it methodically.

Week 1: Audit your stack. List every SaaS tool your team uses. For each one, note the monthly cost, how many features your team actually touches, and whether it integrates cleanly with your other tools. Most teams discover 3-5 obvious candidates within an hour of honest assessment.

Week 2: Score the top candidates. Run your shortlist through the four-factor evaluation. Utilization rate below 20%? Data locked in proprietary formats? Middleware required to connect it? No AI features shipped? Two or more flags and the tool moves to the replacement list. Cross-check against the Keep List — if it falls in a "never build" category, leave it regardless of the score.

Week 3-4: Build one agent. Pick the highest-scoring internal tool. Define exactly what the replacement needs to do, not everything the SaaS tool does, just the specific workflows your team relies on. The build itself is faster than most people expect. Simple internal agents that handle reporting, research aggregation, or content workflows can be operational in days, assuming either an internal developer or an implementation partner doing the build. For teams without technical resources, "days" means days of working with a builder, not days of building yourself. For context on evaluating build partners, the comparison guide covers what to look for.

Month 2-3: Operate and measure. Run the custom agent alongside the SaaS tool for 30 days. Track the actual API costs, the time your team spends on oversight, and any edge cases that surface. Compare against the SaaS subscription cost. The real numbers will be different from projections — they always are — but the gap between "projected" and "actual" is where your operational learning lives.

After 30 days of measured operation, you'll know whether the economics hold and whether your team can sustain the maintenance. That knowledge is worth more than any vendor comparison chart.

Making the Decision

The decision tree is simpler than most guides make it:

Score the tool against the four evaluation factors (utilization, lock-in, integration, AI readiness)
If two or more factors flag high risk, the tool is a replacement candidate
Check the Keep List. If the tool falls in a "never build" category, keep it regardless of the score
Place replacements in the right tier (internal → customer-adjacent → customer-facing) and sequence them accordingly
Build one agent first, operate it for 30 days, and measure real costs against projections before committing to the next build

The companies that succeed at this aren't the ones that replace everything at once. They're the ones that pick the right first replacement, learn from operating it, and expand methodically.

If you're evaluating whether custom agents make sense for your stack, the agentic development page covers how we scope and price these builds, and the implementation guide walks through the build process from a practitioner's perspective. For context on what an AI agent actually is and how it differs from conventional automation, that's a good starting point. And for a broader view of the AI implementation services available, the services overview has the full picture.

FAQ: Build vs. Buy AI Agents

How long does it take to build a custom AI agent to replace a SaaS tool?

Simple internal tools — a reporting dashboard, a research workflow, a content production pipeline — can be built and deployed in days. Customer-facing systems with integrations, error handling, and monitoring typically take two to six weeks. Multi-agent systems that coordinate several workflows take longer, often one to three months from scoping to production. The complexity of the workflow being replaced matters more than the technology involved.

What SaaS tools are companies replacing with AI agents in 2026?

The most common categories are content production tools, CRM enrichment and lead scoring, research and competitive intelligence platforms, internal reporting dashboards, and customer support triage. These share a pattern: the SaaS tool provides broad capability, but the team uses a narrow slice of it. That narrow slice is exactly what a purpose-built agent handles well. Gartner projects 40% of enterprise applications will embed task-specific agents by the end of 2026, up from less than 5% in 2025.

How much does it cost to build a custom AI agent?

For a solopreneur using AI-assisted development, the build cost can be near zero with $10-50 a month in API costs. For a mid-market business working with an implementation partner, expect $6,000-$18,000 for the initial build plus $600-$4,000 a month for managed operation and API costs. Enterprise multi-agent systems start at $25,000 and scale with complexity. See the cost comparison table above for breakeven timelines against typical SaaS spend.

Can a small team build AI agents without developers?

For internal tools, yes. AI-assisted development approaches let non-developers describe workflows in natural language and generate working agents. Kim Doyal runs 33 agents without a development background. For production systems that handle customer data or integrate with critical business processes, engineering oversight matters. The build itself may use AI-assisted development, but someone needs to validate security, error handling, and edge cases.

What happens if the AI agent breaks?

Every custom system needs monitoring and fallback plans. Agents should fail gracefully — alerting a human rather than producing incorrect outputs silently. The maintenance reality is real and quantifiable: first-year costs run roughly 12% above initial estimates (per Clustox's analysis), and by year two, cumulative maintenance can reach four times traditional levels. Budget for ongoing maintenance or use a managed service model. This is the single biggest factor most build-vs-buy analyses underestimate.

Is it cheaper to build or buy AI in 2026?

It depends on the tool and your utilization rate. If you're using 80%+ of a tool's features, buying is almost certainly still the right choice. If you're using 10-15% and paying full price, building the slice you actually need will likely cost less within the first year. Run the four-factor evaluation from this guide against each tool in your stack. The answer will be different for every tool.

Agent Memory Architecture: From Scratch Pad to Institutional Knowledge

Sebastian Chedal — Tue, 21 Apr 2026 18:07:25 +0000

Every AI agent starts each session from zero. No memory of yesterday’s decisions, no record of what worked, no access to what the agent next to it learned last week. For a one-off chatbot conversation, this is fine. For agents running 10 to 20 sessions per day across months of production work, it’s the difference between a useful system and an expensive one that keeps relearning the same lessons.

This article covers the 5-layer memory architecture we built for a production system of 7 autonomous agents. Not a framework proposal or a database vendor pitch. An architecture running in production with real extraction benchmarks.

The five layers: journals, process-thinking extraction, trackers, knowledge files, and a shared library. Each solves a different part of the AI agent memory problem.

In this article:

Why vector stores, conversation history, and single knowledge bases fail as agent memory
The 5-layer memory system: journals, extraction, trackers, knowledge files, and shared library
The extraction bottleneck and why a self-check gate improved extraction yield by 8x from the same document and model
How agents share knowledge without polluting each other’s context
What we still haven’t solved

Why AI Agents Need More Than a Vector Store

The standard advice for giving AI agents memory boils down to three approaches, and all of them break in production.

Vector stores give you flat retrieval with no hierarchy. Search for “completion rate” and you get fragments from 10 different journal entries, a pricing discussion, and a project retrospective, with no classification, no deduplication, and no routing. Conversation history grows without bound. A week of 10 sessions per day produces 70 sessions of noise. The model spends its attention budget on irrelevant transcripts instead of the three decisions that matter. Context rot, where an enlarged context window filled indiscriminately with information degrades reasoning quality, is a real engineering problem.

Single knowledge bases recreate the blob problem with better branding. Where does a team coordination insight go versus a strategic decision versus a recurring review task? Without classification, the agent sifts through undifferentiated content to find what matters.

The common failure: treating agentic memory as a storage problem. It isn’t. Memory is a systems architecture problem: deciding what to store, where to store it, when to retrieve it, and what to forget. We expand on why these approaches fail in the comparison section later.

The 5-Layer Memory Architecture

Our system runs 7 agents across 734 indexed documents organized into 9 searchable collections. Each agent produces and consumes knowledge daily. The architecture has five layers, each with a distinct purpose, persistence level, and access pattern.

Layer	Name	Purpose	Persistence
1	Journals	Raw thinking, scratch pad	Daily files, never deleted
2	Process-Thinking Extraction	Classify and route insights	Completion-triggered, results routed
3	Trackers	Actionable state (tasks, goals, reflections)	Permanent, items marked done/dropped
4	Knowledge Files	Durable topic-specific insights	Permanent, updated as understanding evolves
5	Shared Library	Cross-agent organizational knowledge	Version-controlled, accessible to all agents

Layer 1: Journals (The Scratch Pad)

Each agent writes daily journal files. These are raw working notes: half-formed ideas, observations, problem-solving in progress, and honest assessments of what’s going well or poorly.

An actual excerpt from one agent’s journal:

“I’ve created 17+ work orders but the implementation pipeline is thin. WOs are piling up in drafts awaiting review. I’m generating work faster than it can be approved and executed. This creates an illusion of productivity, lots of artifacts, but the site hasn’t changed much.”

This is useful raw material. It contains a metric (17 work orders, 12% completion rate), a principle (output doesn’t equal impact), and a process observation (bottleneck at the review stage). But the journal itself doesn’t route any of this to where it needs to go. That’s the next layer’s job.

The key design rule: journals are the input to the memory system, not the memory itself. Write what you think. The extraction happens later.

Layer 2: Process-Thinking Extraction (The Bridge)

This is the layer that makes the architecture work. Every vendor and framework focuses on storage. The actual bottleneck is extraction: getting structured, useful knowledge out of raw agent thinking.

After any thinking session (journal writing, self-reflection, analysis), a process-thinking extraction runs automatically. It scans each section of the source document against a 7-category checklist:

Task — something to do
Goal — a multi-week objective
Pattern — a recurring need that should be scheduled
Improvement — a process change to propose
Knowledge — a durable fact, metric, or principle worth storing
Decision — a direction that was set
Question — something that needs another agent’s or a human’s input

Each extract is classified, deduplicated against what already exists, and routed to the correct destination layer.

The self-check gate is what prevents under-extraction, which is the default failure mode. After the initial extraction pass, the processor reviews its own output:

Found 0 knowledge items from a rich document? Re-scan.
Found 0 decisions from a reflection session? Re-scan.
Found only tasks from a multi-section document? Re-scan.
Volume sanity check: a 2-page reflection should yield 5 to 15 items across multiple categories.

In a direct comparison using the same source document and the same model (GLM-5-Turbo):

Run	Method	Items Extracted	Categories
1	Without self-check	1	1 (task only)
2	With self-check	8	4 (knowledge, decisions, tasks, themes)

Same document. Same model. 8x more useful extractions. The self-check mechanism is what prevents under-extraction, which is the default failure mode. AI agents are prolific thinkers and poor self-editors. Without structured extraction, they generate mountains of journal text and store almost nothing useful.

What does extraction cost in practice? For our system, which uses GLM-5-Turbo for extraction and reserves Opus for the deepest writing and reflection work, the extraction step adds roughly $0.01 to $0.03 per session. Across 10 to 20 sessions per day and 7 agents, that runs $0.70 to $4.20 daily. The latency is negligible: extraction runs as a completion step after the session ends, not inline, so it doesn’t slow down the agent’s active work. The self-check re-scan adds a second pass on documents that under-extracted, roughly 20% of runs. Total overhead per session is 10 to 30 seconds of background processing. The tradeoff is straightforward: for less than $5 per day across the entire system, every agent retains 8x more useful knowledge from its own thinking.

Layer 3: Trackers (Actionable State)

Trackers hold the agent’s current operational state in structured JSON files. Items are never deleted, only marked done or dropped, which gives each agent a full decision history. Every session starts by loading the agent’s trackers into context.

There are four tracker types:

Short-term tasks are immediate actions with priority, type (think or act), status, and what they’re waiting on. These look like:

{
"id": "st-048",
"task": "Send data request for top 10 pages by traffic and bounce rate",
"type": "act",
"priority": 2,
"status": "done",
"notes": "Extracted from self-reflection. Need analytics baseline."
}
Long-term goals are multi-week objectives with progress notes and target dates:

{
"id": "lt-006",
"goal": "Content quality scoring system",
"target_date": "2026-04-30",
"progress_notes": [
{"date": "2026-03-24", "note": "Framework built. First audit: Blog 79%, Home 38%."},
{"date": "2026-03-27", "note": "Analytics reveals bounce rates take priority over foundation work."}
]
}
Noodles are the metacognitive layer. These are recurring self-reflection loops that the agent schedules for itself on a weekly, biweekly, or monthly cadence. This is the mechanism that keeps an agent from getting stuck in pure execution mode, running tasks without ever stepping back to ask whether the tasks are the right ones. The agent literally schedules its own thinking.

{
"id": "n-002",
"title": "Self-Reflection Loop",
"interval": "biweekly",
"description": "Review journal entries from past 2 weeks. Ask: Are we effective? What's working? What's not? What should we be doing but aren't?"
}
This is not a human telling the agent to reflect. The agent identified the need for periodic self-assessment and created a recurring trigger. When the noodle fires, the agent reads its own journals, measures progress against extracted benchmarks from Layer 4, and produces new insights that flow back through extraction.

Stars are cross-agent improvement proposals. When one agent observes a problem in another agent’s workflow, it documents the observation and recommends a fix. The fix is never implemented directly by the proposing agent. A human reviews and implements it.

{
"id": "S-001",
"title": "Add quality checklist to content review",
"observation": "Blog scores 79%, Home scores 38%. Content signals not checked before publishing.",
"recommendation": "Add 7-signal checklist to review stage. Threshold: 10/14.",
"status": "implemented"
}
Stars create a governance loop. Agents improve each other’s processes through proposals, not direct intervention. The human in the loop ensures that one agent’s improvement suggestion doesn’t break another agent’s workflow.

Layer 4: Knowledge Files (Durable Insights)

Knowledge files are organized by topic, not by date. This is a design decision that most teams get wrong when implementing agent memory.

The instinct is to create dated entries: 2026-03-27-analytics-insights.md, 2026-04-02-analytics-update.md, 2026-04-08-analytics-revision.md. Three weeks later you have a dozen files on the same topic, each with partial and potentially contradictory information. The agent has to search and reconcile across all of them.

Our approach: one file per topic that gets updated as understanding evolves. When an agent learns something new about a teammate’s working patterns, it updates team/scott.md. It doesn’t create a new file. The knowledge file gets richer and more accurate over time instead of fragmenting across dated entries.

Categories include learning (operating principles derived from experience), strategy (long-range direction), team (cross-agent coordination patterns), and customers (client interaction knowledge). Each agent maintains its own set, and any agent can access another’s knowledge files through the search index.

Layer 5: Shared Library (Cross-Agent Knowledge)

The shared library is a version-controlled repository of 61 files (3.2 MB) that all 7 agents can read and write to. This is the organizational knowledge layer: brand positioning, communication strategy, service descriptions, pricing, customer journeys, art direction guidelines. Every agent, from our autonomous SEO research agent to the analytics team, draws from this same source of truth.

Agents don’t load the entire library every session. A decision matrix determines what’s relevant: writing content triggers positioning and voice rules, auditing a page triggers site map and communication strategy, responding to leads triggers pricing and case studies. This selective loading keeps context windows focused.

The cross-agent knowledge flow works like this:

One agent learns something during its work (e.g., “structured data requests with explicit action sections get a reliable 4-to-8-hour turnaround”).
The extraction process stores this in the agent’s own knowledge file (Layer 4): team/coordination-patterns.md.
If the insight is generalizable, it also gets committed to the shared library (Layer 5): shared-library/rules/agent-communication.md.
Now every agent can access it, either through direct loading or through the search index.

The distinction matters. Not everything an agent learns should be shared. An analytics agent’s internal heuristics for interpreting bounce rates are specific to that agent’s workflow. A finding that “structured requests produce faster turnaround from all agents” is generalizable and belongs in the shared library.

There’s also a hard boundary between internal and external knowledge. Sensitive operational data, client details, and internal strategy live in a separate context-firewalled system that never touches the shared library. The two knowledge pools propagate across the team independently, which prevents internal and external information from cross-pollinating unintentionally. Mechanically, this means the shared library and the context-firewalled store are separate directory trees with separate access controls. An agent loading shared library files for a content task never loads files from the firewalled store, and vice versa. The search index respects the same boundary: queries against the shared library don’t surface results from the firewalled partition. We cover the full security model, including access controls and data boundaries between agents, in our guide to AI agent security. This segmentation is a design constraint, not a limitation.

The Glue: Searchable Knowledge Index

The 5 layers produce knowledge. The search index makes it findable. We use BM25 keyword search across 9 collections containing 734 indexed documents. Every agent can search every other agent’s knowledge, the shared library, and the full content archive.

This bridges the gap between agent-specific knowledge in Layer 4 and organizational knowledge in Layer 5. An agent researching a topic can find another agent’s analytics findings, a third agent’s content research, and the shared positioning documents, all from a single search. The index refreshes nightly, so new knowledge becomes searchable within 24 hours.

We run BM25 keyword matching, not semantic vector search. This is a constraint (CPU-only servers, RAM limitations), but it works well enough for our use case. Agent knowledge files use consistent terminology because they’re written by systems with consistent vocabulary. Keyword matching handles this reliably.

How It Works Together: A Real Example

One complete cycle through the architecture, using Link (our knowledge management agent) as the example. (For the full agent team and how our pipeline works, see the companion article.)

Step 1 — Journal (Layer 1): During a work session, Link writes a self-reflection noting that 17 work orders were created in the past week, but only 2 were implemented. A 12% completion rate. The observation: “I’m generating work faster than it can be approved and executed.”

Step 2 — Extraction (Layer 2): The process-thinking extraction runs immediately after the journal entry is complete. It finds 8 items across 4 categories: 3 decisions (“data-backed everything,” “shift focus to implementation,” “effectiveness means impact, not volume”), 4 knowledge items (an operating principle, pacing rules, a baseline metric, a coordination protocol validation), and 1 short-term task.

Step 3 — Trackers (Layer 3): The short-term task is added to the agent’s tracker. Existing items are checked for duplicates, none are added twice.

Step 4 — Knowledge Files (Layer 4): Four files are updated: learning/analytics-priority-shift.md gets a new operating principle, learning/pipeline-bottleneck-pattern.md gets updated pacing rules, a new baseline document is created with the week’s metrics, and team/coordination-patterns.md is updated with the protocol validation.

Step 5 — Shared Library (Layer 5): In this case, nothing. The insights are specific to the agent’s workflow. If the “data-backed everything” principle applied organization-wide, it would be committed to the shared library.

The next morning: The agent’s session starts by loading its trackers. It sees the new task from yesterday. It doesn’t need to re-read yesterday’s journal. The actionable item is already extracted, classified, and waiting.

Two weeks later: The agent’s biweekly self-reflection noodle fires. It reads the past two weeks of journals. But it also has the knowledge files from Layer 4, the baseline metrics, the pacing rules, the operating principles. It can measure progress against extracted benchmarks instead of re-deriving them from raw journal text.

Why This Architecture Beats the Alternatives

Against a flat vector store, the layered approach retrieves classified, deduplicated, routed knowledge. A vector search for “completion rate” returns fragments from scattered entries. Our system returns a clean, maintained document with the current pacing rules and historical context.

Against conversation history, our system is structured across 7 categories, bounded because tracker items get completed or dropped, and actively maintained because knowledge files are updated rather than appended to. Conversation history is linear, unbounded, and grows without limit.

Against a single knowledge base, our system routes each type of knowledge to its natural home. Tasks go to trackers, durable insights go to topic files, decisions go to memory logs, process improvements go to Stars. Each consuming agent or process gets exactly what it needs without sifting through everything else.

The common thread: extraction is the bottleneck, not storage. Every team building persistent agent memory can pick a storage technology in an afternoon. The hard part is building a reliable process to get knowledge out of raw agent output and into the right place. The 7-category checklist with a self-check gate is our answer. It’s the reason the same model extracts 8 items from a document instead of 1.

What We Got Wrong (And Still Haven’t Solved)

This system has been running in production for months. It works well enough to be worth publishing. It has real limitations we haven’t fixed.

Knowledge file staleness. When a knowledge file was last updated three months ago, is it still accurate? We don’t have a good signal for this. Noodles (self-scheduled reflections) help because they periodically re-examine stored knowledge, but there’s no systematic staleness detection. A knowledge file about a teammate’s working patterns could be out of date if that teammate’s workflow changed and nobody flagged it.

Extraction false negatives. The self-check gate catches under-extraction, but it’s not perfect. Some insights are subtle enough that the 7-category checklist doesn’t surface them. A nuanced observation about why something works, as opposed to the fact that it works, sometimes gets missed. We catch the “what” more reliably than the “why.”

Mis-classification. A separate problem from under-extraction: the classifier sometimes assigns the wrong category. A decision gets classified as a task, or a context-specific observation gets promoted to the shared library when it should stay in the agent’s own Layer 4 files. Unlike false negatives, which the self-check catches, mis-classifications are silent. A decision filed as a task still looks like a valid extraction, so the quality gate doesn’t flag it. Over time, these errors accumulate and degrade Layers 3 through 5.

How do mis-classifications actually get caught? In our experience, through four paths: a human notices the error while reviewing output, the system encounters a contradiction that forces a resolution, the agent naturally revisits the knowledge during a later session and spots the mismatch, or an external signal (like a reader pointing out an inconsistency on a published article) surfaces it. This is like any other bug: it needs to either be noticed or cause enough pain to surface. We don’t have an automated correctness check for classification accuracy, and we’re not sure one is possible without a second model reviewing every extraction, which would double the cost of the extraction step for marginal improvement.

Cross-agent knowledge pollution. When agent A’s context-specific learning is stored in the shared library, agent B might apply it in a situation where it doesn’t fit. The selective loading via decision matrix reduces this, but it’s not eliminated. An insight that “short emails get faster replies” might be true for one agent’s stakeholders and wrong for another’s. We’ve written about the broader challenge of securing agent access to shared knowledge; it’s an ongoing design problem.

Search limitations. BM25 keyword matching is reliable for agents that use consistent vocabulary, which ours do. But it doesn’t handle conceptual similarity. Searching for “work piling up” won’t find a knowledge file about “bottleneck in the review stage,” even though they describe the same problem. Semantic search would help, but our server constraints don’t support it today.

Knowledge volume scaling. With 7 agents and 734 documents, the system is manageable. At 50 agents or 10,000 documents, the nightly index rebuild, the cross-agent search queries, and the deduplication checks would need significant rearchitecting. We built this for our current scale, not for arbitrary scale.

Frequently Asked Questions

How do you give AI agents persistent memory?

With a layered agentic memory system that separates raw thinking from structured knowledge. Our approach uses 5 layers: journals for raw working notes, a process-thinking extraction step that classifies insights into 7 categories, trackers for actionable state, topic-specific knowledge files for durable learning, and a shared library for organizational knowledge. The extraction step is what makes it work. Without it, agents produce raw output that’s never organized into retrievable knowledge.

What’s the difference between agent memory and RAG?

RAG is fundamentally a read-only retrieval mechanism. It grounds the model in external documents that the agent didn’t write. Agent memory is read-write and agent-specific. The agent generates knowledge through its own work, extracts it, stores it, and retrieves it later. In our architecture, RAG corresponds roughly to Layer 5, the shared library. Layers 1 through 4 are the agent’s own memory.

Can AI agents share knowledge with each other?

Yes, through two mechanisms. The shared library (Layer 5) holds organizational knowledge that any agent can read and update. The search index (9 collections, 734 documents) lets any agent search any other agent’s knowledge files. The key constraint: not everything should be shared. Context-specific insights stay in the originating agent’s Layer 4 files. Only generalizable knowledge gets promoted to the shared library.

What’s the biggest challenge in AI agent memory?

Extraction, not storage. AI agents are prolific thinkers and poor self-editors. Without a structured extraction process, agents generate pages of journal text and store almost nothing useful. Our self-check gate, which improved extraction from 1 item to 8 items from the same document and model, exists specifically to address this. The 7-category checklist (task, goal, pattern, improvement, knowledge, decision, question) provides the structure. The self-check provides the quality control. It’s the core of what makes agentic memory work at scale.

How does agent memory differ from giving an LLM a longer context window?

Context windows are temporary, unstructured, and expensive to fill. Memory is permanent, classified, and searchable. An agent running 10 sessions per day for a week generates 70 sessions of history. No context window holds that, and even if it could, filling it indiscriminately degrades reasoning quality. Memory is the curated subset: decisions, knowledge, active tasks, and durable principles, loaded selectively based on what today’s session needs.

What tools do you need for agent memory?

A file system and a search index. We use markdown files organized by topic and a BM25 keyword search engine indexing all of them. You don’t need a vector database, a graph database, or a specialized AI agent memory product. The architecture matters more than the tooling. The 5-layer structure with extraction and routing would work on top of any storage system that supports organized files and keyword search.

How do you prevent agents from storing irrelevant information?

Through the 7-category extraction checklist and the self-check gate. The checklist forces classification: if something doesn’t fit any of the 7 categories, it stays in the journal and doesn’t get promoted to trackers or knowledge files. The self-check adds volume awareness: a 2-page reflection should yield 5 to 15 items. Significantly fewer suggests under-extraction; significantly more suggests over-extraction. Both trigger a re-scan.

Getting Started

If you’re building agents that need to persist knowledge across sessions, start with the extraction problem, not the storage problem. The 7-category checklist (task, goal, pattern, improvement, knowledge, decision, question) is technology-agnostic. You can implement it today, regardless of your stack, and immediately improve how much useful knowledge your agents retain from their own work.

From there, add structure: separate trackers for actionable items, topic-specific files for durable knowledge, and a shared repository for anything that applies across agents. The layering can be incremental. You don’t need all 5 layers on day one. You do need extraction from day one.

If your team is building multi-agent systems and running into the memory wall, the architecture described here is a starting point. We help teams design and implement agentic memory systems as part of our AI whiteboarding engagements, where we work through architecture decisions like these before writing any code.

Agent Governance in Practice: A Practitioner’s Guide to Securing Production AI Agents

Sebastian Chedal — Mon, 20 Apr 2026 18:10:44 +0000

Agent Governance in Practice: Why April 2026 Changed the Conversation

If you’re running autonomous AI agents in production, governance just went from “we should probably think about that” to “we need this implemented before August.” Three things converged in the span of a single week that made the shift unavoidable.

In this article:

What the OWASP Agentic Top 10 risks actually mean for a company running fewer than 50 agents, with practical controls for each

A complete mapping of OWASP risks to Microsoft’s newly open-sourced Agent Governance Toolkit

What production agent governance looks like in a real multi-agent system — our 5-layer architecture (per-task timeouts → recovery anti-loop → cost circuit breaker → model pinning → budget tracking), with specific implementation details

A 90-day implementation plan designed to get you governed before the EU AI Act high-risk deadline in August 2026

Honest lessons from getting governance wrong before getting it right

On April 2, Microsoft open-sourced the Agent Governance Toolkit, a seven-package runtime security framework that maps to all 10 OWASP agentic AI risks with sub-millisecond enforcement. This wasn’t a whitepaper or a press release about future plans. It was working code, available in Python, TypeScript, Rust, Go, and .NET, designed to slot into existing agent frameworks like LangChain, CrewAI, and AutoGen.

The same week, the Cloud Security Alliance published a governance gap report with numbers that should make anyone running agents uncomfortable: 92% of organizations lack full visibility into their AI agent identities; 95% doubt they could detect or contain a compromised agent; and security researchers documented approximately 8,000 MCP servers exposed on the public internet without authentication.

And the regulatory clock is now audible. The EU AI Act’s high-risk obligations take effect in August 2026. Colorado’s AI Act hits in June. NIST launched its AI Agent Standards Initiative in February, though substantive deliverables aren’t expected until late 2026.

The gap between “agents are running” and “agents are governed” has been growing for over a year. Arkose Labs surveyed 300 enterprise leaders and found 97% expect a material AI-agent-driven security or fraud incident within the next 12 months. Meanwhile, only 6% of security budgets are allocated to AI-agent risk. That math doesn’t work.

What the OWASP Agentic Top 10 Actually Means for Your Agents

The OWASP Top 10 for Agentic Applications, published in December 2025 with input from over 100 industry experts, is the first formal risk taxonomy for autonomous AI systems. It’s useful as a reference, but most coverage just lists the risks without showing what “addressed” looks like compared to “unaddressed.” Here’s the practical version.

OWASP Risk

What It Means (Plain Language)

Practical Control (Mid-Market)

MS Toolkit Package

Excessive Agency

Agent has more permissions than it needs. A content agent that can also delete databases.

Least-privilege tool access. Each agent gets only the tools its job requires. Review permissions quarterly.

Agent OS, Agent Auth

Uncontrolled Autonomy

Agent can run indefinitely without human checkpoints. No kill switch, no time limits.

Per-task timeouts. Budget ceilings per execution. Human approval gates for high-impact actions.

Agent Runtime

Identity & Access Abuse

Agents using shared credentials or human accounts. No way to tell which agent did what.

Unique identity per agent. Separate API keys, separate log streams. Never share credentials between agents.

Agent Identity, Agent Mesh

Goal/Instruction Hijacking

External input manipulates the agent into doing something outside its intended purpose.

Input validation on all external data. Sandbox untrusted inputs. System prompts that resist override attempts.

Agent OS

Memory Poisoning

Corrupted data in the agent’s memory or context changes its future behavior in unintended ways.

Versioned memory with rollback capability. Integrity checks on persistent state. Regular memory audits.

Agent OS, Agent SRE

Tool/API Misuse

Agent calls tools with unintended parameters or in unintended sequences. Uses a delete endpoint when it should use update.

Schema-validated tool calls. Rate limiting per tool. Allowlists for destructive operations. Log every external API call.

Agent Runtime, Agent Auth

Cascading Failures

One agent fails, triggering failures across connected agents. A research agent crashes, the writing agent consumes bad data, the publishing agent publishes garbage.

Circuit breakers between agent stages. Each agent validates its inputs independently. Retry limits with backoff. Doom spiral protection.

Agent SRE

Rogue Agents

An agent operates outside its defined boundaries, either through drift or compromise.

Behavioral monitoring against baseline. Anomaly alerts. Hard boundaries on scope (file paths, network access, API endpoints).

Agent Compliance, Agent SRE

Data Leakage

Agent exposes sensitive information through its outputs, logs, or tool calls.

Output filtering for PII/secrets. Credential isolation (agents never see raw secrets). Log redaction rules.

Agent Compliance, Agent OS

Inadequate Audit Trail

No record of what the agent did, when, or why. When something goes wrong, there’s nothing to investigate.

Structured logging of every decision, tool call, and output. Immutable audit logs. Retention policies aligned with regulatory requirements.

Agent Compliance

The Microsoft toolkit column matters because it’s the first time these risks have been mapped to specific, deployable open-source packages. Before April 2, addressing OWASP’s list meant assembling your own stack from general-purpose tools — IAM, observability, policy engines — that weren’t designed specifically for agent governance. The toolkit is the first reference implementation that packages agent-specific governance into a single deployable framework. According to Microsoft’s published benchmarks, the toolkit delivers governance enforcement at sub-millisecond latency (runTimeoutSeconds: 600 in openclaw.json — every cron is hard-killed at 10 minutes. Research tasks, writing tasks, and pipeline stages all share this ceiling, enforced at the orchestration layer, not by the agent itself. An agent can’t extend its own deadline. If it hits the limit, the task fails cleanly and the orchestrator logs the timeout with full context.

This is the simplest governance layer and the one with the highest ROI. A single runaway task can consume hundreds of dollars in API calls if left unchecked. The timeout is the floor — every other governance layer builds on the assumption that unbounded execution is already off the table.

Layer 2: Recovery Anti-Loop (Doom Spiral Protection)

When an agent fails, the natural instinct of any retry system is to try again. The problem: some failures are self-reinforcing. An agent fails, gets retried, fails the same way, gets retried, and each retry consumes the same resources as the original attempt. We call this a doom spiral.

Our anti-loop system runs pipeline-recovery.py every 30 minutes during office hours (8 AM–6 PM PT weekdays). Any item stuck for more than 1 hour triggers a recovery attempt. After 2 failed recovery attempts, the circuit trips: a flag file is written, a Discord alert fires to the ops channel, and the recovery script self-disables until manually reset. The circuit breaker came directly from a real incident on April 4, 2026 — a doom spiral in the AM/PM pipeline split that consumed 472K tokens and $2.78 before it was caught. That one incident justified the entire anti-loop layer.

The system differentiates between transient failures (API timeout, rate limit) and structural failures (bad input data, missing dependencies). Transient failures get retries with exponential backoff. Structural failures get logged, flagged for human review, and the agent moves on to the next task.

Layer 3: Cost Circuit Breaker

Every agent execution has a cost ceiling. cost-monitor.py runs every 30 minutes with three thresholds: DAILY_WARN at $50 (triggers a Discord alert), DAILY_HALT at $100 (disables all crons), MONTHLY_WARN at $600 (approximately our $20/day run rate over 30 days). These numbers are already published in our OpenClaw security best practices guide, which covers the spending circuit breaker implementation in detail.

The design philosophy is suspend-and-escalate: execution doesn’t just trigger an alert — when the hard ceiling is hit, crons disable and a human decision is required before resumption. Killing an agent mid-task can leave systems in an inconsistent state. A content agent terminated while updating a WordPress draft might leave a half-written post visible on the site. Suspending until a human reviews is safer than an automatic kill.

Layer 4: Model Pinning

Each agent task is pinned to a specific AI model. In our pipeline, research tasks run on GLM-5, writing and review stages run on Opus, and art direction runs on Sonnet. The assignment is deterministic — it’s not left to the agent to choose. When the GLM-5.1 migration landed in April 2026, 27 crons had to be explicitly re-pinned. That’s the right behavior: a model change is a deliberate decision, not an automatic propagation.

Model pinning prevents two failure modes. The first is cost blowout — a task accidentally running on the most expensive model. The second is quality drift — a task running on a model that wasn’t tested for that job type. Both produce silent failures: the system appears to work, but the output degrades in ways that take time to surface.

Layer 5: Budget Tracking and Anomaly Detection

The final layer watches aggregate patterns across all agents over time. Individual task governance handles the micro level. Budget tracking handles the macro: two scripts run in parallel. cost-monitor.py monitors daily USD spend. zai-quota-monitor.py tracks a 5-hour burst window and weekly token cap, warning at 70% utilization and alerting at critical/exhausted states. Both surface in the ops dashboard with a quota-burn widget. Discord alerts land in the ops channel.

These five layers address several OWASP risks, though the mappings are our practitioner interpretation rather than canonical OWASP guidance. Per-task timeouts directly address Uncontrolled Autonomy (#2). The anti-loop system directly addresses Cascading Failures (#7). Cost circuit breakers limit the financial damage from Excessive Agency (#1) and Tool Misuse (#6), though they constrain spend rather than permissions themselves. Model pinning reduces the quality drift and cost blowout associated with Rogue Agents (#8). Budget tracking supports the audit infrastructure needed to address Inadequate Audit Trail (#10). No single layer covers everything, and they weren’t designed to. Each one was added to solve a specific problem that the existing layers didn’t catch.

Mapping Production Governance to Microsoft’s Formal Framework

When Microsoft released the Agent Governance Toolkit, the categories mapped directly to patterns we’d built independently.

MS Toolkit Package

What It Does

Our Equivalent

Gap/Notes

Agent OS

Policy engine — enforces governance rules at runtime

Cost circuit breaker + model pinning

Our policies are config-driven, not a formal policy language. Toolkit’s approach is more portable.

Agent Runtime

Execution rings — sandboxed execution with resource limits

Per-task timeouts + recovery anti-loops

Similar intent, different implementation. Toolkit uses formal execution rings; we use orchestrator-enforced limits.

Agent SRE

Reliability engineering — health monitoring, anomaly detection

Budget tracking + anomaly detection

Toolkit’s monitoring is more formalized. Our anomaly detection is effective but custom-built.

Agent Mesh

Agent identity and inter-agent communication governance

Agent-specific permissions + isolated workspaces

We have isolation but not a formal mesh identity system. This is a gap worth addressing.

Agent Compliance

Audit trails, regulatory reporting, data retention

Structured logging + execution logs

Toolkit adds formal compliance reporting. Our logs are detailed but not formatted for regulatory submission.

Agent Identity

Unique, verifiable identity per agent

Separate credentials per agent

Basic implementation. Toolkit offers cryptographic verification we don’t have yet.

Agent Auth

Fine-grained authorization for agent actions

Tool allowlists + action-level permissions

Functional overlap. Toolkit’s approach is more granular and standardized.

The point of this mapping isn’t to claim our system is equivalent to Microsoft’s toolkit. It isn’t. The toolkit is more formalized, more portable, and designed for broader adoption. The point is that the governance patterns Microsoft codified are the same patterns practitioners discover independently when they run agents long enough for things to go wrong. If you’re building governance from scratch today, the toolkit gives you a significant head start. If you’ve already built governance, the toolkit tells you where your gaps are.

The 90-Day Governance Implementation Plan (Before August 2026)

The EU AI Act’s high-risk obligations take effect in August 2026. Colorado’s AI Act arrives even sooner, in June. If you’re running agents that make decisions affecting people (hiring, lending, insurance, medical triage), you likely fall under high-risk classification. Even if you don’t, the regulatory direction is clear: agent governance is moving from voluntary to mandatory.

This plan assumes a mid-market company running 5-15 agents. Adjust scope based on your situation, but don’t adjust the timeline. The deadlines are fixed.

Weeks 1-2: Audit

Start by answering three questions for every agent in your system:

What does this agent have access to? (Tools, APIs, databases, file systems, credentials)

What can this agent do that would be hard to undo? (Deletions, external communications, financial transactions, public publishing)

What happens if this agent runs for 24 hours uninterrupted? (Cost projection, potential damage radius)

Map each answer to the OWASP Top 10 risks in the table above. Your top 3 risks will become obvious. For most companies running fewer than 50 agents, Uncontrolled Autonomy (#2), Cascading Failures (#7), and Inadequate Audit Trail (#10) are the ones that matter first.

Weeks 3-6: Implement Core Controls

Start with the governance layers that have the highest ROI and lowest friction:

Timeouts first.

Every agent task gets a maximum execution time. This is a config change, not an architecture change. It prevents runaway costs and addresses Uncontrolled Autonomy immediately.

Cost ceilings second.

Set a daily and per-task spending limit. Start generous and tighten over time based on observed patterns. Wire up alerts so a human gets notified before the ceiling is hit.

Structured logging third.

Every agent decision, tool call, and output goes to a structured log. This doesn’t require fancy infrastructure; a well-organized log file per agent per day is a starting point. You need this for regulatory compliance and for debugging when something goes wrong.

Separate identities.

Every agent gets its own API keys, its own credential set, its own log stream. No sharing. This is tedious to set up and invaluable when you need to investigate an incident.

Weeks 7-12: Harden and Verify

Add circuit breakers between agent stages.

If your agents hand work to each other (agent A produces input for agent B), add validation at each handoff. Agent B should verify its inputs before acting on them, regardless of trust in agent A.

Implement anomaly detection.

This doesn’t require machine learning. Start with simple threshold alerts: if daily costs exceed 2x the 7-day average, if any single task exceeds 3x the median execution time, if tool call patterns change significantly. These rules catch most problems.

Run a red-team exercise.

Pick your three most critical agents. Try to make them do something outside their intended scope. Feed them adversarial inputs. Test whether your governance layers actually catch the problems they’re designed to catch.

Document your governance posture.

The EU AI Act requires demonstrable governance for high-risk systems. Even if you’re not classified as high-risk today, documentation makes compliance straightforward when regulations expand.

Minimum Viable Governance

You don’t need all 10 OWASP risks addressed on day one. Minimum viable governance for a company running fewer than 10 agents is:

Per-task timeouts on every agent (addresses Uncontrolled Autonomy)

Cost ceilings with human alerts (addresses Excessive Agency)

Structured logging of all tool calls (addresses Inadequate Audit Trail)

Separate credentials per agent (addresses Identity & Access Abuse)

Four controls. You can implement all four in a week if your agent framework supports configuration-level changes. This won’t make you fully governed, but it eliminates the scenarios that cause the most damage: runaway execution, runaway costs, untraceable actions, and shared-credential incidents.

What We Got Wrong (And What It Taught Us)

Governance didn’t start as a planned initiative for us. It started as damage control. Here are the failures that shaped the architecture described above.

On April 4, 2026, a doom spiral in the pipeline consumed 472K tokens and $2.78 before anyone caught it. The cause: AM/PM cycle logic combined with an evening filter to reject every new topic after 5 PM, which triggered a retrigger loop. Each retry was legitimate by itself; together they were catastrophic. The circuit breaker on the recovery script — the two-attempt limit, office-hours guard, self-disable behavior — came directly from that incident. We didn’t build the anti-loop because it seemed like a good idea. We built it because we’d seen the alternative.

A week earlier, on March 25, the gateway heap exhausted memory — not a rogue agent, just accumulated session memory from 2.5 days of uptime, 135 Discord reconnects, and one large session. V8 hit the 2 GB default limit, GC thrashed the event loop, and the cron scheduler died silently. The process appeared alive to systemd for 21 hours while no jobs ran. The fix: a hard 1.5 GB heap cap that forces a clean crash and systemd auto-restart, plus a daily 4 AM PT scheduled restart to prevent slow accumulation. The lesson isn’t about agents — it’s that governance has to include the infrastructure the agents run on, not just the agents themselves.

The more instructive failures happened after governance was in place. When we tested GLM-5-Turbo for the dedup-check stage to reduce cost, the model missed 52% of items and produced 4 false positives. Opus caught all 21 items with zero false positives. The system ran clean; the output was broken. Model pinning isn’t just about picking the right model once — it’s recognizing that model accuracy is load-bearing at certain stages, and that “cheaper” and “equivalent” aren’t the same thing.

The most useful meta-governance lesson came from a stale pricing table. Our ops dashboard had Opus 4-6 priced at numbers from an earlier model version for months, inflating cost estimates roughly threefold before anyone noticed. The governance system was working correctly. The config it consulted was wrong. Correct process, wrong answer. If you’re building governance, build governance-of-the-governance: periodic audits of the config files, threshold values, and reference data your governance layers depend on. They drift too.

The Arkose Labs report found that 87% of enterprise leaders agree AI agents with legitimate credentials pose a greater insider threat than human employees. That framing matches our experience. The risk isn’t that an agent goes rogue in some dramatic, adversarial way. The risk is that an agent with perfectly valid permissions does the wrong thing in good faith, at machine speed, for longer than you’d want.

The other lesson: governance has a cost. Every layer adds latency, complexity, and operational overhead. Microsoft’s toolkit helps with the latency concern (sub-millisecond enforcement), but the complexity and operational overhead are real regardless of tooling. Budget for governance as a first-class system concern, not an afterthought. The AI agent market is projected to reach $10.91 billion with 46% CAGR in 2026 — the governance complexity is only going to increase.

FAQ

How much does AI agent governance cost to implement?

The core controls (timeouts, cost ceilings, structured logging, separate credentials) are configuration-level changes with near-zero marginal cost if your agent framework supports them. The operational cost is in monitoring and responding to alerts. For a mid-market company running 5-15 agents, expect 2-5 hours per week of governance-related operational work (reviewing alerts, investigating anomalies, updating policies). The alternative, running agents without governance, is more expensive in expectation. One undetected runaway incident can cost more than a year of governance overhead.

Do I need Microsoft’s Agent Governance Toolkit, or can I build governance myself?

You can build governance yourself. We did, and many of our patterns predate the toolkit. The toolkit’s value is that it’s standardized, open-source, and maintained by Microsoft. If you’re starting from scratch, the toolkit saves you months of custom development. If you’ve already built governance, the toolkit is useful as a benchmark to identify gaps in your implementation, particularly around formal identity management and compliance reporting.

What’s the minimum viable governance for a company running fewer than 10 agents?

Four controls: per-task timeouts, cost ceilings with human alerts, structured logging of all tool calls, and separate credentials per agent. These can be implemented in about a week and address the four highest-impact risks (Uncontrolled Autonomy, Excessive Agency, Inadequate Audit Trail, and Identity Abuse). Start here, then expand based on what your monitoring reveals.

How does the EU AI Act apply to autonomous AI agents specifically?

The EU AI Act classifies AI systems by risk level. Agents that make decisions in areas like employment, credit scoring, education, or critical infrastructure fall under “high-risk” and require documented governance, human oversight mechanisms, and ongoing monitoring. The high-risk obligations take effect in August 2026. Even agents that don’t fall under high-risk classification are subject to transparency requirements. If your agents interact with humans (chatbots, customer service agents), users must be informed they’re interacting with an AI system.

What’s the difference between AI governance and AI agent governance?

AI governance broadly covers model development practices, training data ethics, bias mitigation, and organizational AI policy. Agent governance is more specific: it covers runtime security, execution controls, inter-agent communication, identity management, and behavioral monitoring for autonomous systems that take actions in the real world. A model that generates text needs AI governance. An agent that reads email, makes decisions, and sends responses needs agent governance. The distinction between AI tools and AI agents is what drives the difference.

How do I govern agents that use MCP (Model Context Protocol) to access tools?

MCP creates a standardized interface between agents and tools, which is useful for governance because it gives you a single control point. The challenge: the CSA report documented approximately 8,000 MCP servers exposed on the public internet without authentication. If your agents connect to MCP servers, treat each connection as an external API integration. Require authentication, validate responses, log every interaction, and monitor for unusual patterns. The Microsoft toolkit’s Agent Auth package specifically addresses MCP-connected tool authorization. For organizations evaluating their overall agent security posture, an AI risk and security assessment can identify MCP-specific vulnerabilities in your deployment.

Governance infrastructure is now table stakes for production agents. If you’re evaluating where to start, the four-control minimum viable governance described above can be implemented in a week and eliminates the scenarios with the highest damage radius. If you’re evaluating which AI projects to prioritize, governance infrastructure should be near the top — it’s not a feature; it’s a prerequisite for every agent you deploy after the first one. For a deeper look at enterprise agent security tooling, our analysis of NemoClaw’s approach to enterprise agent security provides additional technical context on how the tooling landscape is evolving.

Agentic SEO: What It Actually Is and How We Run It in Production

Sebastian Chedal — Thu, 16 Apr 2026 18:08:06 +0000

The “Agentic SEO” Category Just Formalized. Most of It Is Mislabeled.

Agentic SEO became an official category in early 2026. Frase rebranded around it. Siteimprove published a definitional guide. Search Engine Land ran a practitioner walkthrough. The term now has its own SERP, its own vendor ecosystem, and its own set of inflated claims.

The working definition is reasonable enough: agentic SEO uses autonomous AI agents to plan, execute, and refine optimization tasks across the full search lifecycle. Instead of a person prompting ChatGPT for keyword ideas and manually updating title tags, an agent monitors performance data, identifies opportunities, generates briefs, writes content, and tracks results on its own schedule.

The problem is scope. Most content using the term “agentic SEO” describes what is really AI-assisted SEO: a human operator using smarter tools. Frase’s content monitoring feature is useful. Search Engine Land’s n8n workflow walkthrough is practical. But connecting a keyword tool to a content optimizer through a no-code pipeline is not the same thing as an autonomous system that runs your entire SEO operation.

The distinction matters because the results are different. Tool-level automation speeds up individual tasks. System-level automation changes what your team spends its time on. And the gap between those two outcomes widens with every month of compounding operation.

Every piece in the current SERP for “agentic SEO” is written by either a platform vendor defining the category around their product, or a publication ranking tools in a comparison list. What is completely absent is a practitioner perspective: someone who actually runs an autonomous SEO system in production, showing how it works, what breaks, and what the real economics look like.

The Agentic SEO Spectrum: Three Levels of Autonomy

Not all agentic SEO is the same. The label covers a wide range of implementations, from a single AI writing assistant to a multi-agent system managing research, production, optimization, and monitoring in parallel. A useful way to evaluate any “agentic SEO” solution is to place it on a three-level spectrum.

Level 1: AI-Assisted SEO

A human drives the process. AI helps with discrete tasks: generating keyword clusters, drafting content outlines, suggesting meta descriptions. The operator decides what to work on, when to work on it, and whether the output is good enough. Tools like ChatGPT, Surfer SEO, and Clearscope operate here. This is where the vast majority of teams sit in 2026, and it works well for small sites with straightforward content needs.

Level 2: AI-Augmented SEO

AI handles specific workflows end-to-end, but a human coordinates between them. A platform might autonomously monitor your rankings, detect a drop, generate a content brief, and draft an updated version. The human still decides whether to publish, still bridges the gap between the keyword research tool and the content tool, still manually triggers the next step. Frase, OTTO by Search Atlas, and Alli AI operate here. They are genuinely useful platforms that automate real work. For many teams, this is the right level of investment.

Level 3: Autonomous SEO Systems

Multiple specialized agents work as a coordinated system across the entire SEO lifecycle. Research, brief generation, content production, quality review, image creation, publishing, performance monitoring, and iteration all happen through structured handoffs between agents, with human approval gates at defined checkpoints rather than at every step. No single tool covers this scope. It requires purpose-built agents that pass work to each other through a shared pipeline.

The jump from Level 2 to Level 3 is not incremental. It is an architectural shift from “better tools for my SEO team” to “an SEO system that runs on a defined cadence and surfaces results for human review.” Most organizations do not need Level 3. Those that do typically have high content velocity requirements, multiple content types, and enough complexity that manual coordination between tools becomes its own bottleneck.

What Level 3 Actually Looks Like in Production

We run a Level 3 system. It has been in production since early 2026, and the operational data is published across several pages on this site. Rather than describing what autonomous SEO could theoretically look like, here is what it actually looks like when you run it.

The system uses four core agents and two support agents covering the full content lifecycle. A research agent handles keyword tracking, competitive analysis, SERP monitoring, and content brief generation. A writing agent takes enriched briefs and produces full drafts calibrated to a specific voice profile, with built-in review processes that catch voice violations, grammar issues, and brief compliance problems before any human sees the work. An analytics agent monitors traffic, conversion rates, and engagement patterns to identify optimization opportunities. A distribution agent handles social amplification of published content.

Each agent has a narrow job description and the specific tools it needs to do that job. The research agent, for example, runs scheduled workflows for keyword data collection, SERP analysis, GEO monitoring across nine AI search engines, and brief writing. It produces 40+ content briefs per month from this automated research cycle. We have written about how AI agent teams work in business operations in more detail elsewhere; the short version is that agent specialization beats general-purpose agents in every dimension that matters for production use.

The architecture changed meaningfully in our first months of operation. We initially ran everything on scheduled crons: specific times for research, writing, review, and publishing. That worked, but it created artificial delays. A brief that finished research at 10 AM would sit until the writing cron fired at 2 PM. We moved to a completion-triggered model where finishing one stage immediately triggers the next. A cron pulls work into the pipeline. Completion events push it through. An item can move from enriched brief to published WordPress draft in a single cascade, touching each quality gate along the way.

The handoff mechanism is intentionally low-tech: structured file drops between agent inboxes, with a shared pipeline tracker that records what stage every item is at. No message bus, no complex orchestration layer. Each agent reads its input, does its work, writes its output, and updates the tracker. The simplicity is the point. When something breaks, the debugging path is a text file and a log entry, not a distributed system trace.

The quality infrastructure matters more than the speed. Every draft goes through a self-review stage that checks against 25+ banned voice patterns, verifies source attribution, audits brief compliance, and flags anything that reads like generic AI output. That review catches issues in every draft before a human ever looks at it — voice drift, missing attribution, brief compliance gaps, anything that reads like generic AI output. Sebastian, our CEO, reviews the final output and approves for publication. His review typically takes five to ten minutes per piece because the automated review has already handled the mechanical quality work.

Once the infrastructure exists, the marginal cost to produce each additional article drops to a fraction of what a freelancer or agency charges. The full economics are detailed in our pipeline operations breakdown.

What Running Autonomous SEO for Two Months Has Taught Us

The system works. It also has real limitations that the vendor pitches in this space never mention.

Consistency compounds faster than quality

The research agent runs its keyword and competitive analysis on the same schedule every week. It does not skip a week because someone got pulled into a client project. It does not forget to check GEO citations because the team is busy with a product launch. It does not lose momentum during holidays, sick days, or hiring transitions. For SEO, where compounding effort over time drives most results, that consistency matters more than any individual piece of content being brilliant. Most SEO programs fail not because the strategy was wrong, but because execution was inconsistent.

We can produce and publish content faster than Google indexes it. That sounds like a good problem to have, but it creates a measurement lag that makes it hard to evaluate what is working in real time.

Human approval is the bottleneck — by design

The pipeline can produce a finished draft in hours. Getting it reviewed and approved depends on when the human reviewer has time. We could remove the human gate and publish autonomously, and the quality gates would catch most issues. We do not, because the issues they miss are the ones that damage credibility: an unverified claim, a tone-deaf opening, a placeholder that slipped through. The human review is not a limitation of the system. It is the system working as designed.

Agent coordination failures are real. Agents occasionally lose context, misinterpret a brief, or produce output that technically passes every quality gate but reads flat. These failures are different from tool failures. A tool either works or errors out. An agent can produce confidently wrong output that looks correct on the surface. We have had cases where the research stage found strong competitive data but the writing stage ignored it in favor of restating the brief’s thesis, or where a self-review flagged a voice issue and the fix introduced a different voice issue. Building detection mechanisms for these subtle failures is harder than building the agents themselves.

GEO monitoring changed our content strategy

Tracking citations across nine AI search engines revealed that AI platforms cite content differently than Google ranks it. Structured data, named frameworks, and specific operational numbers get picked up by AI engines at higher rates than narrative-driven content. This shifted how we structure articles — not what we write about, but how we format the arguments within them.

Voice calibration turns out to be a harder problem than content generation. Any capable language model can write a 3,000-word article. Getting it to write in a specific voice, consistently, across dozens of articles, without drifting into generic AI patterns is a separate engineering challenge. Our writing agent runs against a style guide with 25+ banned patterns and a set of preferred alternatives. The self-review stage checks every draft against those rules. Even with that infrastructure, we still catch voice drift on roughly one in five pieces. The calibration improves with each iteration, but it’s not a solved problem.

An autonomous system will also naturally reuse what worked before: the same proof points, the same frameworks, the same company references. Left unchecked, five articles in a row will cite the same two statistics and use the same credibility structure. We built a repertoire tracking system that flags repetition across the last several published pieces and pushes the writing agent to find fresh evidence. Maintaining variety across a high-volume pipeline is operational work that most autonomous content discussions ignore entirely.

Tool-Based vs. System-Based Agentic SEO: A Practical Comparison

The platforms in this space are genuinely useful. For most teams, a well-configured Level 2 platform is the right investment. The comparison below helps clarify where the approaches diverge and when the system-level approach makes sense.

Capability	Frase	OTTO (Search Atlas)	Alli AI	System-Level (FC)
Automation Scope	Content research, creation, monitoring, and recovery	On-page optimization, technical fixes, content generation	Sitewide on-page and technical optimization	Full lifecycle: keyword research through publishing, monitoring, and iteration
Autonomy Level	Level 2 — autonomous within content workflows	Level 2 — autonomous for on-page and technical changes	Level 2 — autonomous for rule-based optimization	Level 3 — multi-agent system across all SEO functions
Multi-Agent	Single platform with specialized features	Single platform with automated task execution	Single platform with site-level automation	Five specialized agents with structured handoffs
Quality Gates	Content scoring and optimization suggestions	Automated implementation with rollback capability	Rule-based guardrails	Multi-stage automated review + human approval checkpoints
GEO Monitoring	Content Watchdog monitors 8 AI platforms	Limited AI search coverage	Not a primary feature	Tracks citations across 9 AI search engines weekly
Customization	Template-based with brand voice settings	Configuration-based automation rules	Site-level optimization rules	Fully custom agents built for your specific workflow
Pricing	$99–$999/mo	$99–$499/mo	$299–$999/mo	$2K–$6K/mo managed, incl. AI costs
Best For	Content teams wanting autonomous content research and recovery	Teams needing automated technical and on-page fixes	Multi-site SEO management with rule-based automation	Organizations needing full-lifecycle SEO automation with custom workflows

Frase’s Content Watchdog feature is particularly strong for teams that already have a content operation and want autonomous monitoring and recovery. If your primary pain point is detecting ranking drops and generating recovery content, Frase at $99–$999/month solves that without the complexity of a custom system. Frase also recently integrated MCP (Model Context Protocol) for agent-to-tool communication, which indicates where the platform category is heading: tighter integration between specialized AI capabilities within a single product.

OTTO excels at automated technical fixes that would otherwise require developer time: schema markup deployment, canonical tag management, internal link optimization. For teams whose SEO bottleneck is implementation speed rather than content strategy, this solves a real problem. Alli AI’s strength is scaling on-page optimization across large multi-site portfolios, applying consistent rules across hundreds of pages without per-page configuration.

The system-level approach makes sense when no single platform covers your full workflow, when you need agents to pass context between stages rather than operating independently, or when your quality requirements demand multi-stage review processes that platform tools do not support. It also makes sense when your content needs to serve both traditional search and AI search engines simultaneously, requiring different structural optimizations that a single-purpose tool may not address. The cost reflects that difference. A custom build is an infrastructure investment, not a subscription. Organizations evaluating this path can start with agentic development consulting to scope whether the investment fits their operation.

Is Autonomous SEO Right for Your Business?

System-level agentic SEO is not for everyone. It is an investment in infrastructure, and like any infrastructure decision, the return depends on whether the scale of your operation justifies the build.

It makes sense when:

You need to produce and manage content at a volume that outpaces your team’s coordination capacity. If the bottleneck is not writing speed but the overhead of managing research, drafts, reviews, and publishing across dozens of pieces per month, a system closes that gap.
You need SEO and GEO optimization running in parallel. Traditional SERP ranking and AI search engine visibility require different structural approaches to the same content. A system that monitors both and adjusts accordingly saves the ongoing manual analysis.
You have complex approval workflows. Multiple stakeholders reviewing content, compliance requirements, brand voice standards that vary by content type. Automated quality gates reduce the review burden without removing human judgment from the process.
You are an agency offering content services to multiple clients. Each client has different voice profiles, keyword strategies, and approval processes. A multi-agent system can manage this complexity in a way that scaling a human team cannot match economically.

Tool-level (Level 2) is the better choice when:

You manage a single site with moderate content needs. A well-configured Frase or OTTO subscription will cover most of what you need at a fraction of the cost.
Your team is small enough that coordination is not a bottleneck. If two or three people can manage the full SEO workflow without dropping tasks, adding system-level automation creates complexity without proportional benefit.
Your primary SEO challenge is technical, not content-driven. OTTO and Alli AI handle technical SEO automation well. A multi-agent content system solves a different problem.
You are still evaluating your AI readiness. Building a Level 3 system before your organization is ready for autonomous operations creates expensive shelf-ware.

If you are exploring where SEO automation fits in your broader AI strategy, a useful starting point is understanding how to prioritize AI projects across your organization. SEO is one function. The same architectural decisions apply to any business process you want to automate.

The Market Context: Why This Matters Now

The urgency behind agentic SEO is not hype-driven. The search landscape has shifted structurally, and the data reflects it.

58.5% of Google searches now end without a click, according to SparkToro data cited by Siteimprove. Following the rollout of AI Overviews, 37 of the top 50 U.S. news sites lost referral traffic. These are not edge cases. They represent a structural change in how search delivers value. Optimizing only for traditional rankings means optimizing for a channel where the majority of queries no longer produce clicks.

Meanwhile, adoption is accelerating. Roughly 90% of marketing organizations already use some form of AI agent in their technology stack, according to BCG research cited by Frase. Organizations leading in agentic AI achieve five times the revenue gains of laggards. The gap between teams using AI for SEO and teams not using it is already wide. The gap between teams using tools and teams running autonomous systems is the next competitive divide.

That divide is about dual optimization: maintaining traditional search visibility while building presence in AI-generated answers. A system that monitors both channels and produces content structured for both audiences does work that a purely SERP-focused tool does not.

FAQ: Agentic SEO

What is agentic SEO?

Agentic SEO is the use of autonomous AI agents to handle SEO tasks across the full search lifecycle — from keyword research and content creation through optimization, publishing, and performance monitoring. Unlike using AI as a writing assistant, agentic SEO involves agents that plan, execute, and iterate on their own, with humans providing strategic direction and approval rather than step-by-step instructions. The system initiates work based on data triggers and schedules, not human prompts.

How is agentic SEO different from using AI writing tools?

AI writing tools handle one stage: content creation. Agentic SEO covers the full lifecycle. The difference is scope (single task vs. full workflow), coordination (one tool vs. multiple specialized agents), and autonomy (prompt-driven vs. goal-driven). A writing tool generates text when you ask it to. An agentic SEO system identifies what needs to be written, researches it, writes it, reviews it, and publishes it on a defined cadence.

What tools are used for agentic SEO?

At Level 2, platforms like Frase (content creation and monitoring, $99–$999/mo), OTTO by Search Atlas (technical and on-page automation, $99–$499/mo), Alli AI (sitewide optimization, $299–$999/mo), and Surfer AI Agent handle specific SEO workflows autonomously. At Level 3, purpose-built multi-agent systems use combinations of keyword APIs, content generation models, quality review processes, and publishing integrations tailored to the specific operation.

Can small businesses use agentic SEO?

Yes, at Level 1 and Level 2. A small business with a single site and modest content needs can get meaningful results from AI-assisted keyword research and content creation tools. Level 3 autonomous systems make financial sense for organizations producing content at scale or managing multiple client accounts. The investment in custom infrastructure does not pay off until the volume justifies the build cost.

How does agentic SEO handle GEO (Generative Engine Optimization)?

GEO requires monitoring how AI search engines (Perplexity, Google AI Overviews, ChatGPT, Claude, and others) cite and reference your content, then structuring content to earn those citations. Agentic SEO systems track citation rates across multiple AI platforms, identify which content formats get cited most frequently, and adjust content structure accordingly. This dual optimization (traditional SERP + AI engine visibility) is one of the strongest practical arguments for autonomous SEO systems, since manual GEO monitoring across nine or more platforms is not sustainable. In practice, GEO optimization often means structural changes, adding named frameworks, explicit definitions, comparison tables, and FAQ sections that AI engines can extract cleanly, rather than changes to the underlying argument or topic selection.

What are the risks of autonomous SEO?

Quality control is the primary risk. AI-generated content can pass automated checks while still reading as generic or slightly off-brand. Multi-stage review processes and human approval gates mitigate this but do not eliminate it. Other risks include over-optimization (agents optimizing for metrics rather than reader value), hallucination in sourced claims (agents citing statistics they generated rather than found), and dependency on AI model quality (a model downgrade can affect output across the entire system).

How much does agentic SEO cost?

Tool-level (Level 2) ranges from $99 to $999/month for platforms like Frase and OTTO, with some tools like Writesonic starting as low as $19/month for basic features. System-level (Level 3) is a custom build: typically $1,000 to $4,000/month in ongoing management and AI API costs. The per-article production cost for an autonomous system runs $2 to $5 in direct API costs, which is the economic argument for scale: the marginal cost per piece drops dramatically once the infrastructure exists.

For organizations evaluating whether an AI agent platform fits their operation, the qualification question is not “can we afford the system?” but “do we produce enough content for the system to pay for itself?”

GEO for B2B Companies: A Practitioner’s Guide to AI Search Visibility

Sebastian Chedal — Tue, 14 Apr 2026 18:07:05 +0000

What GEO Actually Is (And What Most Guides Get Wrong)

Generative Engine Optimization is the practice of structuring your content so AI search engines cite it when answering user queries. Where SEO optimizes for ranking positions, GEO optimizes for citations: getting ChatGPT, Perplexity, Google AI Overviews, and other AI platforms to reference your content in their responses.

You’ll find the same discipline called LLMO, AEO, GSO, and AIO depending on who’s writing about it. GEO appears to be winning as the standard term, with 880 monthly searches and roughly 4x year-over-year growth. The underlying practice is the same regardless of the label.

Every existing GEO guide in the search results is written by a tool vendor or an agency selling GEO services. They’re comprehensive, but the recommendations always lead back to the author’s product or service offering. None are written by a company that actually tracks GEO results across multiple AI engines for its own business.

We track citation performance across 9 AI engines for 25 keywords every week. We’ve measured the improvement. We know which engines cite us, which don’t, and why the same keyword produces completely different citation leaders on different platforms. This article shares what we’ve learned from doing GEO, not from selling GEO tools.

AI Search Is Not One Channel. It Is Nine (At Least)

The biggest mistake in every existing GEO guide is treating “AI search” as a single channel. It isn’t. Each AI engine has different retrieval mechanics, different citation patterns, and different source preferences. Optimizing for “AI search” generically is like optimizing for “social media” without distinguishing between LinkedIn and TikTok.

We track citations across these engines using LLM Refs as one of several monitoring tools. Our research agent continuously evaluates and adds new tracking tools through self-directed learning.

Here’s how each engine handles citations:

AI Engine	Retrieval Method	Citation Style	Source Preferences
ChatGPT Search	SerpAPI / web scraping	Footnote-style inline citations	Heavy Wikipedia preference; moderate citation rate for optimized content
Perplexity	Real-time web crawling	Inline numbered citations	Strong Reddit preference; freshness bias (90-day window); high source traceability
Google AI Overviews	Google’s own index	Source cards with expandable links	Strong E-E-A-T signals; prioritizes already-ranking content
Google AI Mode	Conversational, expanded retrieval	Inline with follow-up context	Shares Google’s E-E-A-T signals; broader scope than Overviews
Claude	Web search (when enabled)	Source cards	Less publicly documented; emerging patterns
Gemini	Google-grounded	Coarser, end-placed citations	Google ecosystem bias; structured content preference
Copilot	Bing index	Numbered inline citations	Bing-dependent; favors structured, well-indexed content
Grok	X (Twitter) data + web	Inline references	Social signal weighting; real-time content bias
Meta AI	Web search integration	Inline citations with links	Emerging; Facebook/Instagram ecosystem tie-ins

The practical implication: the same keyword produces different citation leaders on different engines. We see this in our own tracking data — a keyword where Fountain City ranks #3 with 19% share of voice in aggregate might not appear at all on some individual engines, while enterprise brands dominate others. Aggregate citation rates hide per-engine divergence, and that divergence is where the real optimization opportunities live.

What We Learned Tracking 25 Keywords Across 9 Engines

We’ve been running weekly citation tracking across 9 AI engines for 25 keywords related to our core topics: AI agents, AI readiness, autonomous systems, and related B2B queries.

Over a five-week measurement period, our citation rate improved from 20% (5 out of 25 keywords citing us) to 32% (8 out of 25). That’s a 60% improvement. For context, Princeton University and IIT Delhi research analyzing 10,000 queries found that optimized content can increase AI visibility by up to 40% in controlled studies. Our measured improvement exceeded that benchmark in a production environment.

The data showed a few things clearly:

Content structure matters more than domain authority for citation. Our data-heavy pages with clear section headings and direct-answer opening paragraphs consistently get cited. Opinion pieces and thought leadership articles with softer structures don’t, even when they rank well in traditional search.

Per-engine divergence is real and significant. Treating AI search as one channel means you’re optimizing for an average that doesn’t exist on any individual platform. One keyword might have Microsoft dominating with 46-56% share of voice, while a different keyword in a related topic has no clear dominant source at all.

Enterprise brands dominate most broad keywords. On keywords like “AI agent development” or “enterprise AI deployment,” Microsoft, Accenture, and Salesforce hold 44-60% share of voice across most engines. A boutique firm isn’t going to displace them on those terms. The opportunity for smaller companies is on specific, practitioner-level keywords where the large brands haven’t published authoritative content yet.

Freshness has an outsized effect on some engines. Perplexity in particular shows a strong freshness bias toward content published within the last 90 days. Newer content of similar quality consistently outperforms older content. This means GEO for Perplexity is partly a publishing cadence game.

The citation gap between accessible and blocked content is widening. According to Press Gazette research cited in Frase’s analysis, nearly 80% of top news publishers now block at least one AI training crawler via robots.txt. That creates a content scarcity dynamic where accessible, well-structured content has a disproportionate citation advantage. This advantage will erode as publishers adapt, but right now it’s significant.

A B2B GEO Implementation Framework (What Actually Works)

Most GEO guides repeat the same generic advice: add FAQ schema, use long-tail keywords, create comprehensive content. That advice isn’t wrong, but it’s incomplete. Here’s what actually moves citation rates based on our tracking data and production experience.

Lead with quotable definitions. Write the opening 40-60 words of every section as if an AI engine will extract only that paragraph. Because in many cases, it will. AI engines pull from the first paragraph after a heading more than any other position. Structure your content so each section starts with a standalone answer.

Original data is the single highest-leverage content type for GEO. The Princeton/Georgia Tech research (KDD 2024) found that adding original statistics improves AI visibility by 40%. Our experience confirms this directly: our pages with proprietary data and specific numbers get cited; pages built on synthesis of other people’s data rarely do.

Structure for per-fact extraction, not per-page ranking. AI engines cite individual paragraphs, not whole pages. A 4,000-word article with one strong claim buried in paragraph 23 is less effective than the same article with that claim positioned clearly under its own heading. Each H2 section should contain a standalone, extractable answer.

The most impactful structural change for GEO is answering the question first, then elaborating. Every section should begin with a direct answer in the first paragraph, then provide supporting context, evidence, and nuance in subsequent paragraphs. The “build up to the answer” approach that works for narrative writing actively hurts GEO performance.

Entity consistency is one of the fastest GEO wins available, and it costs nothing. Use the same company name, personal name, and descriptor format across your website, social profiles, directory listings, and content. AI engines build entity models. Consistent naming across platforms helps them connect your content to your brand.

Use schema markup, but don’t overestimate it. FAQ schema (FAQPage), HowTo schema, and Article schema are all worth implementing. They provide structured signals that AI engines can parse directly. That said, schema alone won’t overcome weak content. Think of it as the metadata layer on top of already-strong content, not a substitute for it.

GEO builds on top of SEO authority. In our tracking, content that already ranks well in traditional search is significantly more likely to get cited by AI engines, particularly by Google AI Overviews (which draws directly from Google’s search index). Strong SEO is a prerequisite for GEO, not an alternative to it.

Finally, track per-engine, not just aggregate. If you only track overall citation rate, you’re hiding the signal under noise. Per-engine tracking reveals which platforms are accessible, which aren’t, and where specific content changes will have the most impact.

What GEO Cannot Do (Honest Limitations)

Every GEO guide we found in the search results is pure advocacy. Here are the constraints they leave out.

Enterprise-dominated keywords are mostly out of reach. If Microsoft holds 46-56% share of voice on a keyword, a B2B company with a fraction of their domain authority and content volume isn’t going to displace them. The strategic move is selecting keywords where large brands haven’t published authoritative practitioner content. We won citations on specific, long-tail keywords where our operational depth gave us an edge. We gained nothing on broad, high-volume terms where enterprise content libraries dominate.

Citation algorithms change without notice. Unlike Google’s search algorithm, which has a two-decade history of documented updates and patterns, AI engine citation logic is newer, less documented, and changing faster. What works on Perplexity in April may not work in July. Any GEO strategy needs to be treated as adaptive, not fixed.

Citation doesn’t equal conversion. Being cited by ChatGPT or Perplexity doesn’t mean leads will follow. The attribution path from AI citation to website visit to form submission is murky at best. AI-referred sessions are growing rapidly — up 527% year-over-year according to Previsible’s 2025 AI Traffic Report — but connecting those sessions to revenue remains a measurement gap for most businesses.

GEO tool maturity is low. The current landscape ranges from roughly $32/month for basic monitoring to $2,000+/month for enterprise platforms, with wildly different coverage across engines. No tool tracks all 9+ engines comprehensively. No industry standard exists yet. Plan to combine multiple tools and manual spot-checks for at least the next 12-18 months.

The 80% publisher blocking dynamic cuts both ways. Right now, accessible content benefits disproportionately from AI citations because most premium publishers block AI crawlers. As publishers negotiate licensing deals and reopen access, that advantage will erode. GEO strategies built entirely on the scarcity advantage should plan for a more competitive citation landscape.

No guaranteed ROI timeline. SEO has established (if imprecise) timelines: 3-6 months for competitive keywords, 6-12 for newer domains. GEO timelines are less predictable. We saw improvement within 5 weeks, but our starting position, content volume, and topic selection all influenced that. Your mileage will genuinely vary.

How to Get Started: 30-Day B2B GEO Plan

Most GEO guides prescribe a 90-day plan. For B2B companies that already have a content library and some SEO foundation, 30 days is enough to establish a baseline and start making informed decisions.

Week 1: Audit your current AI visibility. Take your top 10 business queries — the ones prospects actually type when looking for what you sell — and run them through ChatGPT, Perplexity, and Google AI Overviews. For each query, note three things: whether you’re cited, which competitors are cited, and whether any queries return no citations at all. Queries with no current citations are your highest-opportunity targets.

Week 2: Apply quick structural wins. Go to your top 5 pages by traffic and add a direct-answer opening paragraph to each major section. If the page starts with background context and builds toward the answer, reverse that. Answer first, then elaborate. Add FAQ schema to any page that already has a Q&A section. Check your entity consistency across Google Business Profile, LinkedIn, directories, and your website.

Week 3: Publish one piece with original data. This is the highest-impact single action for GEO. Take an operational metric, industry survey result, or proprietary framework your company has and publish it as a structured article. Make the data the centerpiece, not supporting evidence for another argument. Structure it with clear headings, direct-answer paragraphs, and specific numbers near the top of each section.

Week 4: Set up tracking and establish your baseline. You don’t need expensive tools to start. Manual spot-checks — running your target keywords through AI engines and recording the results in a spreadsheet — work fine for a 25-keyword list. If you want to automate, tools like LLM Refs can track citations across multiple engines. Record your citation rate, which engines cite you, and which competitors appear alongside you. This becomes your baseline for measuring improvement.

Once you have four weeks of data, you’ll know where you stand, which engines are accessible to you, and where to invest your next round of content and optimization effort. That gives you more to work with than a theoretical 90-day plan based on someone else’s benchmarks.

For companies that already have a broader AI search optimization strategy in place, GEO becomes a focused extension of that work rather than a separate initiative.

Where GEO Fits in a B2B Content Strategy

GEO isn’t a replacement for SEO, content marketing, or any other channel. It’s an additional optimization layer applied to content you’re already producing.

The volume of AI search queries is significant and growing. ChatGPT processes 2.5 billion prompts per day as of mid-2025. Perplexity has reached 45 million active users and surpassed 780 million monthly queries. 43% of professionals report using ChatGPT for work-related tasks. These are not niche platforms. They are where an increasing share of your prospects start their research.

For B2B companies, the practical approach is integrating GEO principles into your existing content production process rather than treating it as a separate workstream. Every article, landing page, and resource you publish should be structured for both traditional search ranking and AI citation. That means direct-answer opening paragraphs, clear section headings, original data where you have it, and consistent entity references. The incremental effort is small when it’s built into how you write rather than bolted on after the fact.

Each piece we publish is structured for AI extraction before it’s written — that’s built into the research step, not bolted on after. The result is content that serves both channels from the start.

Companies evaluating their broader AI readiness, including how well positioned they are for shifts like GEO, may want to start with a structured AI readiness evaluation to identify where the biggest gaps are.

Frequently Asked Questions

Is GEO replacing SEO?

No. GEO extends SEO. Strong search authority is a prerequisite for GEO performance, particularly with Google AI Overviews, which draws directly from Google’s search index. Companies with weak SEO foundations will struggle with GEO regardless of how well they structure their content for AI extraction. Build SEO first, then optimize for citations.

How much does GEO cost?

The range is wide. DIY with manual tracking and content restructuring costs roughly $32-89/month for basic monitoring tools plus your team’s time. Agency GEO services run $1,500-$25,000/month depending on scope. In-house, the primary cost is one person’s time plus monitoring tools. We built GEO tracking into our existing content operations, making the incremental cost negligible beyond tool subscriptions.

How long before GEO produces results?

For topics where no strong authority exists, 2-6 months is reasonable. For enterprise-dominated keywords, significantly longer or potentially never. We saw measurable improvement within 5 weeks, but we had an existing content library and domain authority to build on. Newer domains should expect a longer ramp.

Which AI engines should B2B companies prioritize?

Google AI Overviews for the widest audience reach. Perplexity for the highest-value B2B research audience, as its user base skews toward professionals and decision-makers. ChatGPT for the largest query volume. Don’t ignore Claude and Copilot — both have growing B2B user bases and different citation preferences that represent distinct opportunities.

Can I do GEO myself or do I need an agency?

The audit, structural improvements, and quick wins from the 30-day plan above are well within reach for any team that can edit their own website content. Ongoing per-engine tracking and optimization — particularly publishing original data at a cadence that maintains freshness advantage — is where most B2B companies benefit from systematic tooling or outside help. The data analysis, interpreting what per-engine divergence means for your specific content strategy, is where expertise matters most.

What is the difference between GEO, LLMO, AEO, and AIO?

They describe the same discipline under different names. GEO (Generative Engine Optimization) appears to be winning as the standard term. LLMO (Large Language Model Optimization) is used in more technical contexts. AEO (Answer Engine Optimization) predates the current wave and originated in the featured snippet era. AIO (AI Optimization) is the broadest and least specific. Use whichever your audience recognizes — the strategies are identical.

We asked Perplexity directly to identify B2B companies that are leaders in GEO strategy. The response: “Search results do not identify specific top companies excelling in B2B GEO strategies.” That gap is one reason we wrote this guide. When we ran our strategic framework for prioritizing AI projects, GEO optimization scored high on both impact and feasibility for exactly this reason: the competitive field is still forming.

We’ve been through every major platform shift in 27 years. GEO is a significant one. The companies that start tracking and optimizing now will have compounding advantages over those that wait for the discipline to “mature.” It’s already mature enough to measure. That’s enough to start.

For companies that want help implementing a GEO strategy built on production tracking data rather than theory, our AI search optimization services include per-engine citation monitoring, content structure optimization, and ongoing tracking across all major AI engines. We also use an autonomous SEO research agent that continuously monitors AI search visibility and identifies citation opportunities as they emerge.