Learning without drift

“The only real mistake is the one from which we learn nothing” - Henry Ford

Learning from mistakes over time is one of the many things that we humans are so great at that we take for granted. While it may seem trivial, rather complex computations and decision trees take shape in our heads any time we attempt a task that we have failed at before. We subconsciously keep track of what we tried that didn’t work, what did eventually work, and rather importantly, why it worked.

Unlike people, most production agents start each run virtually from scratch. Over the course of a run, they can recover from a bad tool call, discover that a document needs to be parsed a certain way, or even find a clever trick… and then discard that experience when the run ends. This allows subsequent runs to make the same mistakes.

At production scale, the same avoidable failure can recur across hundreds of invoices, claims, or reviews. Agents can scale repetition much faster than they scale learning; and without an improvement loop, they scale their mistakes too.

Memory seems to be the obvious answer: let the agent remember everything and teach itself as it goes. Unchecked memory that changes future behavior, however, is no longer just memory. It becomes policy. A supplier might be exempt from one approval because of a temporary exception. If the agent remembers only “this supplier does not require approval,” a one-time recovery can silently become a permanent bypass. To avoid such issues, policy, in production, must have evidence, and be scoped, reviewable, and reversible.

We built our self-improvement system, called “Hydra” internally, around this constraint. It turns execution evidence into proposed improvements while maintaining these standards. Like its Lernaean namesake, the system comes back stronger every time.

How we measured it

To measure Hydra, we ran it against a fixed set of work that mirrors what Pointer runs in production. The unit of that work is a procedure: a recurring operational task with a right answer, akin to a standard operating procedure. Think a close reconciliation, invoice auditing, or clearing chargebacks.

For each one we assembled scenarios, each a fixed set of inputs with a known correct result, carrying the same mixture of emails, attachments, spreadsheets, business rules, judgment calls, and incomplete instructions that is standard in real operations.

We built these scenarios to be difficult on purpose. They skew toward the adversarial cases we expect in production rather than the clean ones. Corrupt documents, ambiguous decisions, threshold calculations, competing policy rules, human review requirements, inputs scattered across files and applications. Some require the runtime to recognize that it cannot safely proceed.

The procedures were realistic in another important way - their SOPs were useful, but not exhaustive or foolproof. That is how production work is usually specified. An SOP defines the work but it rarely anticipates every malformed attachment, conflicting field, missing integration, edge condition, or judgment call. They are like Jasper O’Farrell’s map of San Francisco, in that they lay out what needs to be done in broad strokes but don’t guarantee that the terrain will cooperate.

The result is that the opening numbers reflect cold performance against the worst of production, not typical performance. Out of the box means the runtime executes each procedure from its SOP as written, with no findings active. We assembled 68 scenarios across 10 procedures and ran three rounds, feeding each round's evidence to Hydra before the next. Scenarios within a procedure were distinct work items that shared failure types, not answers, so a finding extracted in one round could only improve the next by generalizing to work it had never seen.

More work, done correctly

At Pointer, the result that we care the most about is correctness. We work in spaces where being almost right is the same as being wrong.

We measured several dimensions separately because a single “success rate” hides too much:

• Operational completion rate: measures how often a run reached a completed state. The first requirement for winning a race is to get to the finish line.

• Task-critical accuracy: combines the scored fields within each scenario and balances the result across procedures. It includes:

  • Terminal-decision accuracy: whether the runtime made the correct final decision for each work item.

  • Numerical accuracy: task-critical amounts, ratios, thresholds, and normalized values.

• Cost per completion

• Median run duration

Every quality metric climbed across the three rounds:

The runtime finished more often, made better final decisions, and produced substantially more accurate numbers. Accuracy is what decides whether the work can run without a person behind it. Every decision the runtime gets right is one nobody has to review, and every one it gets wrong is rework, so these numbers are the difference between a system that removes work and a system that creates more.

A system that gets faster at being wrong is not improving, so the movement that matters happened on both sides of the ledger. While quality climbed, the cost of each completed run fell, and the runs got faster:

Cost is what decides whether any of this runs at production volume. Accuracy that arrives by spending more on compute and retries stops making sense at thousands of runs a month. Here the system got more accurate and cheaper at the same time, because much of what it learned was how to stop wasting effort.

The gains came from generalization rather than recall. A finding that only fit the scenario it came from had nowhere else to apply. The evidence that this transfers is production itself: since Hydra was introduced, operational completion across the procedures Pointer runs live has held above 99%.

Inside the improvement loop

Hydra reads completed runs. It sees the full trajectory, the tool calls, the intermediate outputs, and how the run ended, and it looks for patterns that hold beyond a single run, analyzing runs individually and in batches. Everything it extracts is recorded as a finding, and no finding influences future work until it is validated. Every finding stays scoped to its procedure, carries the evidence it came from, and can be walked back. Findings take one of three forms.

1. Learnings change how the system goes about the work without rewriting the procedure. In one procedure, the claims portal URL carried an internal identifier that differed from the official claim number displayed on the page, and the runtime kept trusting the URL. Hydra extracted a learning to use the displayed number. That learning is active today, with 55 successful applications out of 56. These are the closest thing to traditional memory. The difference lies in how much authority they carry. The effect of each active learning stays interpretable rather than dissolving into a bundle of simultaneous memories.

2. Rule suggestions are material changes to the procedure itself. If a step is underspecified, Hydra can propose the change but it cannot silently make it policy. In another procedure, six consecutive runs attempted extraction without a readable source document. Hydra proposed an input gate: confirm a parseable document exists before invoking the model, and fail with a clear input error otherwise. An operator accepted the rule, and all six work items completed on the next pass. This is a design-time decision about the standard the work runs against, made once, off the execution path. It is not a person sitting in the loop on production runs.

3. Issues capture problems the runtime cannot safely self-correct such as missing capabilities, broken integrations, infrastructure failures, or tooling defects. These are surfaced to the Pointer team for repair instead of being disguised as a prompt lesson.

Most of these surface early when we work with a customer. During the testing and simulation that precede any production deployment, a procedure runs against the adversarial scenarios first, and that is where the underspecified steps get caught and written in. The bulk of the rule suggestions land before the work is ever trusted with live operations, which is what compresses the time between standing a procedure up and running it unattended. The system keeps finding refinements in production, but it does not start from zero there.

Reaching the right answer and proving it is right are two different problems. Hydra focuses on the first. The second is a separate system we will get into another time.

What we learned

Implementing Hydra strengthened several hypotheses we held and weakened one the field still takes for granted.

1. Repeated execution evidence can reveal reusable improvements. The operational recoveries and correctness gains along with cost and duration improvements show that both failed and successful runs contain information worth preserving.

2. Imperfect instructions are a normal operating condition, not a defect to design around. A system that only improves under exhaustive instructions is solving the friendliest version of the problem. The procedures that gained the most were the ones whose SOPs left the most unsaid.

3. Correctness needs several independent measures. Completion alone is not enough. Decisions, numerical values, required fields, and structure each fail on their own, and a single score hides all of it.

The one we came in believing and left doubting is that more memory makes a better agent. It does not. The reason is mechanical - retrieval runs on similarity, so a memory that is merely topically related to the task at hand gets surfaced even when it is stale or beside the point, and once it is in the context window the model tends to lean on it and fold it into the answer with confidence.

You see this in general-purpose assistants constantly. You are asking about one thing, and the model reaches into its saved memory and drops in a note from some unrelated past conversation. It surfaces because the retrieval step decided it was close enough, and the model has no reliable way to tell that it does not belong here. In a chat that is a harmless non sequitur you scroll past.

In a financial close, where a stray note can tilt a decision on an invoice it was never meant to touch, the same behavior is drift. Memory without scope and validation compounds into bias.

The compounding advantage that stays with you

The reason someone who has run reconciliation for ten years is so good at it is because they have simply seen it all. They know which vendor invoices never match on the first pass, which accounts always need a manual adjustment, which exceptions are real and which are noise. That knowledge is what lets them run the close without anyone checking behind them, and almost none of it is written down.

That is the problem underneath everything mentioned here. The expertise that makes operational work run lives in a few heads, and it leaves with them. It is also the honest worry about handing the work to AI.

A general model arrives knowing nothing about your particular process, and there is no manual to give it.

Hydra is how the system earns that competence without spending ten years on the job. Every run leaves evidence, and Hydra converts it into the judgment the work actually requires, validated and written down for the first time.

Most of that earning happens before production, in the simulation phase described above, so the system goes live already knowing the edge cases a new hire would take months to encounter.

That loop is what makes an enterprise deployment possible at all:

• No process is fully specified on day one, and a system that cannot close its own gaps turns every unwritten step into an exception routed to a person forever, so the team it was meant to free never leaves the loop.

• No enterprise can hand work to a system that rewrites its own behavior freely, and Hydra was built under that constraint.

What the company gets is competence that compounds while staying visible. Each run makes the system better at your work specifically, and that accumulated judgment lives in your deployment rather than in any single person or any model underneath. A better base model raises the floor for everyone, but the record of how your work is done right is yours alone.

This is what lets Pointer run multi-day reconciliations, three-way matches, and threshold calculations inside some of the most regulated companies in the world without a person checking behind every step.

If you’re excited by self-improving AI systems for work that has to be right, we’re hiring across all functions.