There are two dominant approaches to making enterprise AI agents better over time, and both are wrong for the problem.
The first is observability. Tools like Braintrust, Langfuse, and Arize do an excellent job of giving you traces, evals, and dashboards over your agent runs. You can see what the agent did. You can see when it was wrong. You cannot, in any structural way, make it stop being wrong.
The second is fine-tuning. Bake the corrections into the weights. It's a reasonable bet for some problem shapes — narrow, stable, well-curated. But for enterprise institutional knowledge — the kind that changes when a sales team renames a region, when finance updates a definition, when a new product launches — retraining cycles are the wrong frequency. By the time a fine-tune is shipped and validated, the underlying truth has shifted.
We think there's a third loop, and we think it's the only one that matches how enterprises actually correct work. We call it the correction flywheel.
The shape of the loop
The correction flywheel runs on three premises:
- Corrections come from experts in the moment of being wrong. When the agent answers a finance question incorrectly, the person who notices is the controller, not the data team. The correction has to be captured in their workflow, not routed to a backlog.
- Corrections update the knowledge layer, not the weights. A correction says: "This entity maps to that one," "This term means this thing in this context," "This document supersedes that one." These are facts about the business, not parameter updates.
- The next agent run uses the new knowledge automatically. No retraining. No deploy. The next time anyone asks a related question, the corrected understanding is in scope.
When this loop is running, every expert correction makes the system better for every other user. That's the flywheel. The asset compounds.
Why this is different from observability
Observability tools surface errors. They don't close them. The correction sits in a Linear ticket, a Slack thread, or someone's head. The next time the agent runs the same query, it makes the same mistake, because nothing in the agent's view of the world changed.
The correction flywheel is the closing loop that observability platforms structurally don't have. Both are useful — you want observability to find the corrections worth making — but observability without a flywheel is a graph of unfixed bugs.
Why this is different from fine-tuning
Fine-tuning bakes facts into model weights. This works when the facts are stable, the corpus is curated, and the cost of retraining is amortized over many users. None of those things are true for enterprise institutional knowledge.
What we see in practice:
- The fine-tuned model is correct on the corrections it was trained on, and quietly wrong on everything else.
- Six weeks later, the underlying data has changed in ways the fine-tune doesn't reflect.
- The next model release breaks the fine-tune entirely, and the team has to retrain from scratch.
- Nobody actually knows whether a given answer is coming from the fine-tune or the base model.
Worse, the corrections are no longer auditable. A fact in the weights cannot be inspected, versioned, or rolled back without a re-train.
The correction flywheel keeps corrections as data — versioned, attributable, reversible. The model is just the runtime.
Why corrections need a knowledge layer to land
The reason most teams default to fine-tuning or observability isn't preference. It's that they don't have a place to put corrections. There's no schema for "the controller said the EMEA aggregation excludes Israel," because there's no aggregation registry to write it into.
The correction flywheel only works if you have an institutional knowledge layer underneath the agent — entity resolution, terminology, process structure, document authoritativeness — that corrections can target. Without that layer, every correction is a sticky note on top of an unchanged system, and the loop stays open.
This is the part that gets glossed over. People hear "feedback loop" and assume it's a UX feature. It isn't. It's a data architecture.
What it looks like in practice
In a Phyvant deployment, when an expert flags an agent answer as wrong:
- The correction is captured against the specific entities, definitions, or documents the answer relied on.
- The knowledge layer is updated immediately — not in a nightly batch, not in a retrain, not in a future release.
- The agent's next run sees the corrected layer.
- The correction is versioned, attributable to the expert, and reviewable.
Over six months in a real deployment, the rate of repeat corrections drops sharply, and the rate of new corrections shifts toward genuinely new edge cases rather than the same bug surfacing in different forms. That's the flywheel signature.
The category bet
We think the right way to evaluate an enterprise AI vendor in 2026 is not "what model do you use" or "what's your accuracy on a benchmark." It's: when an expert tells your system it's wrong, what happens next?
If the answer is "we open a ticket," the loop isn't running.
If the answer is "we fine-tune in the next release cycle," the loop is too slow.
If the answer is "the correction lands in our knowledge layer and the system improves immediately," that's the flywheel — and that's the loop we think enterprise AI converges on.