Zamp

Inside Zamp's Self-Learning System: How AI Employees Improve From Every Correction

Inside Zamp's self-learning AI employee architecture: real production numbers, no model retraining, and how it differs from Ema, Kore.ai, and Decagon.

9 MIN. READPUBLISHED SEP 10 · UPDATED OCT 9
AM
Ashwat MahendranMarketing Team @ Zamp. Documenting the influence and impact of AI across industries.

Most AI agent platforms that ship today take one of two approaches to improvement. Either the agent never changes after deployment, running the same logic in month six as it did on day one, or it "improves" only when the vendor swaps in a newer underlying model. Neither actually teaches the agent your job. A newer model might reason slightly better in general, but it does nothing about the specific vendor's invoice format an agent misread last Tuesday, or the exception a reviewer has now corrected for the third time this week.

Zamp's AI employees are built on a different premise: the system should get measurably better at a specific job, from specific corrections, without anyone retraining a model or filing an engineering ticket. This is the technical detail behind that premise: two loops running at different timescales, a hard line between what learns and what doesn't, and a production deployment where this compounded into a 90% cost-per-request reduction inside seven weeks. It's the deep dive on the self-learning piece of the full platform architecture.

Two loops, running at different speeds

Call the first loop PEV, for Plan, Execute, Validate. It runs inside a single case, every time, regardless of how many cases came before it. The agent plans its approach to the task in front of it, executes that plan, then validates the result against what it expected before marking the case done. That validation step is what catches confident-but-wrong output, the kind of answer that reads as correct and would ship straight through a single-pass system, before it reaches a human reviewer or a downstream system. See PEV Loop for the mechanics in full.

Call the second loop the self-learning loop. It runs across cases, over days and weeks, not inside any single one. Every time a human reviewer corrects an agent's decision on an edge case, that correction gets folded back into the agent's Agent Operating Procedure (AOP), the plain-language document that captures a role's rules, tolerances, and known exceptions. The next time a similar case comes up, the agent already has the corrected handling available to it. Early cases lean on more supervision by design; as reviewed corrections accumulate, straight-through handling climbs. See Self-Learning Loop for the mechanics.

A concrete example makes the difference clearer. Say an accounts payable agent flags every invoice from a specific vendor because the vendor's PO number sits in an unusual field on the page. A reviewer corrects the first few cases, pointing to where the number actually lives. That correction becomes part of the AOP. The tenth invoice from that vendor doesn't get flagged, not because a model got smarter at reading documents in general, but because the agent now has this vendor's specific quirk written into how it does the job.

What actually changes: the operating procedure, not the model

This distinction matters more than it sounds like it should. When people hear "the agent learned from that correction," the default assumption is that a model got retrained or fine-tuned somewhere in the background. That's not what happens here. What changes is the AOP, the operating context the agent reads before acting on a case. The underlying model's weights don't move.

That distinction has four practical consequences. First, it's auditable: every behavior change traces back to a specific reviewed correction in the AOP's revision history, not to an opaque retraining run nobody can inspect after the fact. Second, it's reversible: if a correction turns out to be wrong, or a policy changes back, you edit the AOP, you don't have to undo a fine-tune or wait for a new training cycle. Third, it carries no retraining cost or latency: there's no GPU job sitting between a correction and the agent applying it; the very next case simply reads the updated procedure. Fourth, and most important in a regulated environment, it avoids the silent model drift risk that comes with continuous fine-tuning, where a model's behavior can shift in ways nobody explicitly reviewed or signed off on. A procedure change is a diff a human can read line by line. A weight update is not.

The evidence: a biopharma procurement deployment

The clearest evidence for any of this is a live deployment, not a diagram. An AI employee took over PR-to-PO review for a global biopharma enterprise's procurement division in June 2026. Within five weeks, purely from reviewed corrections restructuring how the agent worked through exceptions, with no change to the underlying model, its approve-recommendation rate rose from 8.3% to 30.4% and manual review fell from 64% to 36%.

Both metrics moved together over those weeks, not as a single before/after snapshot but as a trend: as the AOP absorbed each newly corrected pattern, less of each batch needed a human touch, and the cases that still needed review were increasingly genuinely novel ones, not repeats of exceptions already corrected. That's what the loop compounding in practice actually looks like.

Over the full seven weeks of the deployment, weekly volume scaled from 205 to 2,712 requests and cost per request dropped from $11.57 to $1.21, a 90% reduction. That reduction came primarily from restructuring the workflow into smaller, more deterministic steps before switching to a cheaper underlying model, not from switching models first, which is itself evidence that the gains came from procedure, not horsepower. Full write-up: How an AI Employee Cut Procurement Cost per Request by 90% at a Global Biopharma Enterprise.

Reflection agents and feedback loops: the pattern underneath

Both loops are specific implementations of two more general patterns from agent design. A reflection agent pauses after acting to evaluate its own output before treating a task as finished, rather than executing in a straight line and stopping, which is what the PEV loop's validate step does inside a single case. See Reflection Agent.

A feedback loop, more broadly, is any system that uses its own results to change future behavior instead of running the same way every time. That's what the self-learning loop does across cases, using reviewed outcomes as the signal rather than raw model output. See Feedback Loop. The reason this holds up in production, instead of drifting into its own mistakes the way unsupervised feedback loops can, is that the trigger is always a human-reviewed correction, not an automated or self-graded signal.

Where the self-learning loop has limits

It's worth being precise about what this system doesn't do, since overclaiming here is exactly what turns "self-learning" into a marketing word instead of an engineering one. The loop is bounded by the AOP's scope: it gets better at the job it's already been briefed on, it isn't a general reasoning upgrade that makes the agent smarter at unrelated tasks. A genuinely novel exception, one the AOP has no precedent for, still escalates to a human the first time it appears; the agent doesn't guess its way through unfamiliar territory to "learn faster." And because the signal is a reviewed correction, the loop requires an actual review process in place, it doesn't retroactively re-grade or re-run decisions that were never checked by anyone.

How this differs from how Ema, Kore.ai, and Decagon learn

All four companies build in the same broad category, and the vocabulary overlaps more than the mechanisms do. Ema's differentiator is a proprietary system, a routing layer that combines outputs from 100+ underlying LLMs to avoid single-model lock-in, orchestrated through what it calls a Generative Workflow Engine. That's model-selection breadth: picking a stronger model for a given call. It isn't a mechanism for learning a specific operational procedure from corrections.

Kore.ai's differentiator is a build-your-own multi-agent orchestration and governance layer, with parallel processing and independent fault recovery across a fleet of agents you assemble yourself. That's operational resilience, keeping a system of agents running when one component fails, not a learning mechanism.

Decagon uses the same term Zamp does, Agent Operating Procedure, paired with Watchtower for live QA monitoring and Duet Autopilot for self-improvement. The mechanism is closer in spirit to what's described here than Ema's or Kore.ai's. But the domain is different: Decagon's AOPs drive customer-facing concierge conversations across chat, voice, email, and SMS. Zamp's AOPs encode operational policy for regulated, high-stakes back-office roles, accounts payable, procurement, KYC, chargebacks, where the AOP has to hold up to an external examiner reconstructing a decision months later, not just a customer satisfaction score measured in the moment.

Why a self-learning system has to stay auditable

None of this is useful in banking or pharma if a reviewer can't reconstruct why the agent's behavior changed. Every reviewed correction that updates an AOP is logged: what the original decision was, what the correction changed it to, who reviewed it, and when. That's what lets a self-learning system operate in a regulated environment instead of staying a demo-only capability. The full architecture of that audit trail is covered in Zamp Trust & Security: How Enterprise AI Employees Are Governed, Audited, and Secured.

How to evaluate a vendor's self-learning claim

"Self-learning" shows up in a lot of AI agent pitches. Four questions separate a real mechanism from a slogan:

  1. Does the system change from reviewed corrections, or does every exception require a new engineering ticket or a retraining job? If teaching an exception means waiting on an engineering backlog, the "learning" is really just a slower version of manual reconfiguration.
  2. Can you see exactly which correction caused which behavior change, or does 'it learned' mean an opaque, unexplained shift? A vendor who can show you the specific reviewed correction behind a specific behavior change has an auditable system; one who can't has a black box.
  3. Does "learning" ever touch the underlying model's weights, or does it stay contained to the operating procedure? Weight changes introduce retraining cost, latency, and drift risk that a procedure change doesn't.
  4. Is the learning signal a human-reviewed correction, or an automated or self-graded one? An unsupervised feedback loop can reinforce a mistake just as easily as it fixes one.

For the platform's full architecture beyond the self-learning piece, Agent Operating Procedures, Company Brain, audit trails, and deployment models, start with the full platform architecture piece, or the broader What Is an AI Employee? Definition, Examples and Complete Guide.

Get new essays in your inboxThe Z-Axis, delivered whenever we publish something worth reading.
Like what you read?Add Zamp AI as a preferred source on Google to see more of our work in your search results.
Prefer on Google
Velocity is Survival

Hand the rest to an AI employee that runs it end-to-end

book demoDither Right Arrow