Agent operating procedures (AOPs): how a company stops forgetting what it learns

Companies find out how much they didn't know about a process on the day the person who knew it leaves.

The SOPs and dashboards survive, and access gets reassigned. What the new hire can't see is that one vendor's invoices almost always look wrong and are almost always fine, which discrepancies deserve a second look, which approvals can wait, and which system the team trusts when two sources disagree. Nobody hid any of this. It never got written down, because people learned it by doing the work.

When a person does the work, that gap is an inconvenience. When an agent does the work, it's a failure mode. A general-purpose model can know accounting without knowing how your accounting team runs today. It can know procurement without knowing which supplier you trust, when to escalate, or which edge case from three quarters ago quietly became standard practice.

We think a company is autonomous to the degree that it stops forgetting what it learns by doing the work. The useful test is whether the judgment behind the work outlasts the people who made it. At Zamp, the thing that holds that judgment is the agent operating procedure.

What is an agent operating procedure (AOP)?

An agent operating procedure (AOP) is the versioned set of instructions, policies, sources of truth, permissions, approval limits, escalation paths, and scoped precedents that one AI employee executes, and it changes only through tested, reviewed updates. At Zamp every AI employee has exactly one: one agent, one AOP. The short definition lives in our AOP glossary entry. This piece is about why the idea matters and how it works in practice.

Some of what goes into an AOP looks like any SOP: objectives, instructions, policies, permissions. The rest usually has no home at all: which source wins when two disagree, guardrails, approval boundaries, how exceptions get handled, known failure modes, the reasoning steps, and the judgment that builds up once the agent is doing real work.

The process owner writes it: the person who already does or manages the job, working in plain operating language, the way you'd brief a new hire. That's deliberate. An engineer working from a secondhand description of the process would write down the documented version and miss the exceptions. The process owner is the one who knows what "acceptable" means for their team, and the first to notice when that changes.

It helps to separate three layers. The model supplies general intelligence. The Company Brain is the data layer, the company information an agent is allowed to use. The AOP is the operating layer, and it decides what the agent does with that information inside this particular business. Keeping the three apart matters later, when we get to what an agent is allowed to learn and from whom.

Real roles are rarely one tidy workflow. A finance role covers reconciliation, approvals, investigations, reporting, and exceptions. Sometimes one agent can own most of it, and sometimes the work splits across several agents. Each one still needs a clear operating boundary, so each gets its own AOP.

AOP vs SOP: what's the difference?

An SOP is a document written for people. An AOP is the procedure an agent executes on every case. That change in who reads it changes almost everything else.

At the start the relationship runs one way. The existing SOP is an input to the AOP, along with policies, historical cases, corrections, and escalation records. Then the agent starts working, and the AOP moves as reality shows what the SOP left out. Over time the AOP becomes the more accurate description of how the job gets done.

That points at a step we're building toward and haven't shipped: generating the current human SOP from the AOP, so a new employee starts with how the role works now instead of how it worked the last time someone had a free afternoon to update the document.

Why you can't write the whole process down up front

The first instinct in any automation project is to document the process completely, every edge case included. That sounds sensible until you try it.

Ask an experienced finance operator to list every situation in which they'd reject an invoice, and you'll get a decent list. Show them an unusual invoice six months later and they'll often say something is off right away. Ask why, and the answer usually comes from years of context rather than from the list they wrote.

Operational knowledge gets made while the work gets done. Someone sees an exception. Someone makes a judgment. Someone explains why. Two months later someone else sees the same pattern. Experience turns into precedent, and enough precedent can eventually turn into policy. Companies learn this way all the time. What they usually lack is a place to keep it.

Take an illustrative example. Say an AOP allows a 2% invoice variance and an invoice arrives at 4%. No rule covers it, so the agent escalates instead of improvising. A reviewer recognizes a known rounding issue with that vendor, approves the invoice, and writes down why. The explanation is worth more than the approval. It's knowledge that used to live in one person's head, and now the process can keep it.

Keep precedent, policy, and inference separate

The approval supports a narrower rule than "4% variance is acceptable."

It says this vendor, under these conditions, has been approved before. Promoting one approval into a general rule is overfitting on a sample of one. There's a quieter failure too. The model will form its own theory about why the reviewer said yes. If it stores that theory as though it were the reviewer's reasoning, inference has become authority without anyone signing off.

So an AOP keeps three things apart: explicit policy, reviewed precedent, and the model's own inference about what happened. They have different owners and carry different weight, and each should be allowed to spread to a different degree. A precedent stays scoped to the conditions under which someone made the call. If it keeps recurring, a process owner can decide to turn it into a broader rule. That's how an AOP gets stronger without turning one person's judgment into company policy.

What this looked like in a real deployment

The same loop ran in a live procurement deployment.

In June 2026 an AI employee went live inside the procurement division of a global biopharma enterprise, reviewing purchase requests (PRs) before they become purchase orders (POs). The checks are familiar procurement checks: purchase amount and currency, whether a cited quote has expired, whether the purchase falls under an existing multi-year contract, and which tax rules apply. The full account is in our biopharma procurement case study and in Raghav's write-up on X, "Our agent reduced its own cost by 90% while scaling 13x".

Week one was cautious by design. The agent handled 205 PRs, recommended a decision on 36% of them, and sent the other 64% to manual review. The rule behind that number matters: when the agent wasn't sure, it routed the case to a person instead of approving it. That rule is what made it safe to run on live requests from the first day.

Then the correction loop started. The agent went through every case where its decision disagreed with the human reviewer's and restructured how it worked through the procurement rules and their exceptions, breaking them into smaller, more predictable steps. After that restructuring its decision rate rose to 85%, and manual review fell from 64% to 15%. Reviewers could see why it decided what it did, because it wrote its full reasoning into SAP Ariba, the system the team already used for purchasing. Weekly volume grew to 1,327 PRs, then 2,389 by week five and 2,712 by week seven.

Cost per PR fell from $11.57 in week one to $1.21 by week seven, a 90% drop. Two changes got it there. The rules and exceptions were split into smaller steps handled in a more predictable order, and anything predictable, like checks already run or information already known, became a deterministic tool the agent stopped re-deriving on every request. Only after that did the agent recommend switching from a frontier model to a smaller one. The model choice alone didn't produce the result. Switching first, before restructuring the work, would have cost accuracy.

The next step is to fine-tune a small open-source model that runs inside the customer's own environment. That's a goal, and it hasn't happened yet.

Where the model stops and code starts

That cost curve came from a boundary every AOP has to draw: which steps belong to a model and which should be plain code.

The engineering agent draws that line, and the process owner reviews it. When Zamp builds an agent, its engineering agent decides where the boundary sits and codifies both sides into the AOP. In the procurement deployment the boundary moved as the agent learned. Checks that turned out to be predictable, such as ones already run or information already known, became deterministic tools. Judgment on the exceptions stayed with the model. The AOP records that split, so it's reviewable like any other rule.

We've found that when a step keeps getting the same answer from a model, it's usually a candidate for code. Each time the boundary moves toward code, the agent gets cheaper and more predictable, and the model's attention goes to the cases that need judgment.

Learning only from failures caps you at the operation you already have

Most agent-learning setups are built around failures. The eval set is a collection of cases the agent got wrong, and learning means adding the fix. That's necessary. It also puts a ceiling on what the agent can become, for three reasons.

First, a failure-only eval set defines "correct" as "what the human reviewer would have done." Every case gets graded against today's operation. An agent that reaches the right answer by a shorter path gets no credit, and an agent that reaches a better answer than the reviewer looks like it disagreed and gets corrected back. At best, such a system matches the current process.

Second, waste rarely shows up as an error. A redundant approval step produces the right outcome, so nobody files it as a failure. Two teams maintaining slightly different procedures for the same problem both produce acceptable results. Look at the procurement case again: by the time cost became the focus, the answers weren't the problem. The agent was doing too much redundant work and making too many model calls per request. A failure log wouldn't have surfaced that, because nothing was failing.

Third, fixes tend to add rules. Each failure turns into a new rule or exception, and the loop rarely proposes deleting one. Run that loop for a year and the procedure tends toward a pile of patches.

So an AOP also has to learn from what went right. A seven-step process keeps finishing in five. An approval turns out to be redundant. That might mean removing a rule as well as adding one, splitting processes that were bundled together, or joining processes that were treated separately. We treat successes as learning signal today, alongside failures.

The process owner still decides which change serves the company. The agent shouldn't drift toward whoever corrected it last. Automating a process and improving it differ here: learning from failures makes the agent better at the operation you have, and learning from successes shows you where the operation should change.

Operating knowledge needs version control

If the AOP determines how an AI employee behaves, editing the AOP is editing the employee. That goes wrong fast when several people touch the same process.

The person making most of those edits is the process owner. They can adjust a threshold, add an exception, or tighten a tolerance without filing an engineering ticket. Engineering is involved once, at initial system integration, and after that rule changes don't wait for a sprint. Our guide to running agentic AI without engineers covers where that boundary sits.

The same controls apply to every change. At Zamp every change, whoever makes it, happens on a new branch of the agent. The branch runs against evals, including a golden set of behavior the agent already has to get right. It merges into the main agent only after review. Evals keep running afterward against live operating conditions, which is how we check that a change that passed testing still holds up in production.

The reviewer's scoped precedent from the 4% invoice goes through the same path. It's captured on a branch, tested against the golden set to make sure it doesn't break cases the agent already handles, reviewed, and merged.

Business operators get something software teams have had for years: a change history they can use. Who changed the procedure, what prompted it, what was tested, what improved, what regressed, and which version is live. A team whose operating reality really is different can fork an agent, and a team that found a lesson worth sharing can contribute it back to the standard agent. The process owner authors the change, and the branch, the evals, and the review do the checking an engineering team would otherwise have done by hand.

The goal is to end the habit of treating operating knowledge as a document someone quietly updates when they remember. If a procedure shapes work other people depend on, its history should be visible.

Continuity means remembering how the business works

Business continuity usually means systems staying online. Companies tend to be worse at a different kind of continuity: remembering how the business works.

People leave, teams reorganize, processes get outsourced, and companies get acquired. The person who made an important call three years ago isn't around to explain it. The systems survive those changes, and the operational memory often doesn't.

An AOP gives that memory somewhere to live. The reviewer who approved the 4% invoice can leave, and the scoped precedent stays, along with the note explaining it and the record of who merged it.

The more you automate, the more this matters, which runs against intuition. When fewer people perform a process every day, fewer people build experience with it. A highly automated company can become fragile if the automation runs cleanly and nobody keeps the reasoning behind it.

Learning has to respect boundaries

Organizational learning has limits on who learns what. Unrelated agents are isolated from each other today, and that isolation is the control that keeps audited, mission-critical processes apart from non-sensitive ones. Where two agents take part in the same larger process, what one learns can improve the process for the other. The broader controls around identity, access, and audit are covered in our trust and security overview.

Conflicts are harder. When a change to one AOP starts affecting the goals or outcomes of another, the system should surface the risk and leave the call to a person. That's a direction we're building toward and haven't shipped. The principle behind it holds already: there's still a process owner, and people still have their names attached to the numbers. AI should cut how often someone has to repeat a judgment while leaving intact who has the authority to make it.

What AOP in AI means depends on the vendor

Zamp is one of several vendors using the term "agent operating procedure." Decagon uses it for the procedures behind its customer-facing conversational agents. Other agent platforms organize the same problem around workflow builders or orchestration layers, with no single procedure per agent.

In this piece, an AOP means one thing: the versioned operating procedure for one AI employee, updated from reviewed precedent and from what went right, tested before merge, and kept separate from the data layer. When you compare vendors, ask what changes the procedure, whether there's a usable history, and whether the person who owns the process can read it.

Why agent count is a poor measure of autonomy

It's tempting to measure autonomy by counting agents, as if a company with 50 agents were more autonomous than one with five.

You could deploy hundreds of agents and still run a deeply human-dependent company if every unfamiliar situation ends up in the inbox of the three people who remember how the business works. Operational memory is what reduces that dependency.

For a company to run autonomously, it has to know what each agent is responsible for, what authority it has, which information it can trust, when judgment is needed and where that judgment comes from, how a decision changes future behavior, and who stays accountable for all of it. The AOP is where those answers live. Humans keep owning goals, policy, and accountability. The change is that the company's ability to execute stops depending on a handful of people remembering the right detail at the right moment. That's also the premise of a company with a brain: the knowledge belongs to the company.

Open questions we haven't settled

We're confident in the mechanism. Several questions around it are still open for us, and they're the ones we find most interesting.

When should precedent graduate to policy, and who decides? Recurrence is a useful signal and a weak criterion on its own. Five approvals for the same vendor could mean the tolerance is wrong, or could mean five reviewers deferred to the first one. Our current answer is that a process owner makes the call. We don't yet have a good rule for when to prompt them, or for how much evidence should be required before a scoped exception becomes general.

How do you stop scoped precedents from piling up into an unreadable exception list? Scoping is what keeps one judgment from becoming company policy, and left alone it could produce hundreds of narrow exceptions nobody can reason about. Learning from successes helps, because it can propose deleting rules as well as adding them. Whether that's enough to keep an AOP legible after three years of real operation is something we'll only know by watching it happen.

How much of the SOP can ever be regenerated from the AOP? Parts of what an agent does will be clear enough to write back out as a human procedure. Some of the judgment that stays with the model may never compress into prose a new hire can follow. We don't know where that line falls, and it probably differs by process.

From people learning to companies learning

Companies have always learned through their people. Someone handles hundreds of cases and gets better at the job. Some of that reaches their team. Less becomes company knowledge, and even less survives a few generations of employees. Individuals compound faster than institutions.

AOPs change the unit that learns. A person corrects an agent, and the correction becomes a scoped precedent. If the precedent keeps recurring, a process owner can turn it into policy. The change is tested and merged, and every execution after that carries it. The procurement agent that started by sending 64% of its PRs to a person, and got that down to 15%, got there the same way, one disagreement at a time. The person who taught it something can leave, and the company keeps what they taught it.