Agency Was the Easy Axis: The Architecture of an Agent That Improves

PERSPECTIVES · PLATFORM NOTES · VANTAGE · JULY 2026

Most of the argument about AI agents is still about whether they can act. Inside our fleet that question is settled. The harder one is whether an agent gets better, and the answer turns out to be an argument about where a lesson should live.

Agency and learning are different axes, not stages

The previous essay in this series settled on a working definition of the word "agent," a model that runs a loop, deciding which tool to call, observing the result, deciding what to do next, and taking real actions toward a goal. It then set one further property aside on purpose. A track record, we argued, does not belong in that definition, because a system can satisfy every clause of it and still not have one. It belongs to a different and more useful question. This essay is that question, and the first thing worth saying is that it does not sit further along the same road.

Seven capabilities matter. They divide into two groups, and the division is the point.

CAPABILITY	WHAT IT REQUIRES	AXIS
Perception	Reading live state rather than a snapshot handed to it	Agency
Action	Changing state rather than describing it	Agency
Autonomy	Choosing the next step from what it just observed	Agency
Delegation	Invoking another agent and reading back its judgment	Agency
Persistence	Carrying knowledge across sessions rather than starting cold	Learning
Self-knowledge	Holding an accurate account of its own track record	Learning
Adaptation	Changing behavior from accumulated experience rather than from an edited prompt	Learning

The two axes are orthogonal, and treating them as a single ladder is the most common conceptual error in this whole conversation. A system can hold all four agency capabilities and none of the learning ones and still be an agent in every sense that matters. Dodona selects among sixteen tools on its own, writes to a client's database, triggers other agents' analyses, and files tickets against the platform that nobody asked it to file. That is agency under any working definition, and none of it requires the system to remember yesterday.

So "make them real agents" was never the goal we were reaching for. They are real. The goal is making them improve, and that is a different engineering problem with a different shape and a different hard part.

We made a promise about this and it needs machinery underneath it

When we wrote about where the human stands, we described four positions along the boundary between people and machines, and argued the fourth was the one we encountered least often and regarded as most important: humans training the machines to eventually stand at the gate. The claim was that every correction a reviewer makes is a record of the distance between what an agent produced and what the firm was willing to publish, that accumulated corrections compose an increasingly exact portrait of excellence in a given category of work, and that the portrait is the material from which a more capable agent is built.

That was a design commitment stated as prose. What follows is the engineering, including the parts that are harder than the prose implied.

Learning needs five primitives, installed at one place

Every structured agent in the fleet already flows through a single entry point. That function owns the safety and cost controls so no caller has to: in-flight deduplication, cooldowns, freshness windows, eligibility gating, transient retry, and tenant stamping on every run. Learning belongs at the same chokepoint for the same reason. A capability installed once where everything passes is a capability every agent has. A capability installed per agent is a capability that three agents have, in three slightly different ways, none of which anyone can reason about.

PRIMITIVE	WHAT IT DOES	WHAT BREAKS WITHOUT IT
Judgment capture	Normalizes three moments that look unrelated into one typed event: a user correcting an agent mid-conversation, reality resolving a claim it made months ago, a person accepting or rejecting an extraction. Each record is attributed to an agent and a version	Feedback exists and cannot be attributed, so a lesson learned about last quarter's prompt gets silently applied to this quarter's
Storage with scope and supersession	A record knows whose it is and what it replaces	An append-only store accumulates contradictions and resolves them by accident of retrieval order, confidently applying a rule the firm retired six months ago
Retrieval	Selects the few records that belong in this specific invocation, for this company, at this moment	Every other primitive works and nothing useful arrives. This is the hardest of the five by a wide margin
Injection	One function assembles firm memory, the agent's own track record, cross-firm platform calibration, and learned rules into a single block the agent reads	Each agent builds its own fragment in its own way, and nobody can say what any given agent actually saw when it made a call
Verification	Evaluations, so a learned rule cannot silently regress	The system gets worse in ways nobody notices, which is a worse outcome than not learning at all

The fifth is the one teams skip and the one that makes the rest safe. It is the same principle as the gate in our delivery architecture: no output is trusted because the thing that produced it was confident. It is trusted because a check went green. The third is where the actual difficulty lives.

Retrieval is the whole problem, and storage is not

Storing ten thousand lessons is trivial. Any relational database will hold them, indexed and scoped, without complaint. The difficulty arrives one step later, when an agent is invoked and something has to decide which four of those ten thousand belong in this context window, for this company, at this moment.

This is the argument from The Attention Ledger arriving one layer down, and it took us a while to see it. We wrote there that the fovea and the four-item working memory are the constraints artificial intelligence did not relax, and that the attention of the person reading the screen is the one input that did not get cheaper. A model's context window is enormously larger than human working memory and it is still a fixed denominator. Injecting more of a badly ranked corpus makes an agent worse rather than better, for the same reason that adding one more panel to a dashboard makes a partner slower. Precision in retrieval is the same discipline as restraint in an interface, practiced on a different reader.

Our current ranking is a salience heuristic: recency multiplied by frequency multiplied by a source weight. It is a reasonable first version and we do not expect it to hold past a few hundred rows in a single scope, because a heuristic that never reads the question cannot know that a lesson about revenue recognition is irrelevant to a conversation about key-person risk. The eventual answer is semantic rather than heuristic, which means vectorizing memory and learning records so that retrieval matches on meaning and later clustering can group lessons by what they actually say.

A lesson should end up as hard as it can get

Knowledge in a system like this can live in five places, and they are not equivalent. Ranked from the softest to the hardest, where hardness means how reliably a lesson stored there actually governs behavior:

LAYER	HOLDS	NATURE
Database rows	Memory, calibration, track record	Retrieved per invocation. The softest substrate, and conditional on the retrieval step succeeding
Tool descriptions	When and how to act	A contextual hint, read only while the agent is choosing among tools
System prompt	Behavioral rules, identity	A strong hint. Present on every invocation, and still a hint
Code	Deterministic domain logic	A guarantee
Model weights	General capability	Outside the ladder. Not ours to write, and not where any of this is going

The direction of travel is the whole point. A lesson begins as an observation, becomes a stored record, and may eventually be promoted into a prompt rule. Most learning systems being built today stop exactly there, and treat an accumulated pile of prompt rules as the finished product of learning. We think the better destination, for most lessons, is one layer harder.

Take a real one. When several valuation letters share the same date of value, they should be summed rather than treated as competing marks. That is not a matter of judgment. It is arithmetic with a condition attached, and it is correct every time the condition holds. Written into the valuation read path it is simply true. Written as a line in a prompt it is a request that a model comply, and a model complies most of the time, which is a different and much worse property for a figure that ends up in an LP letter.

A lesson in a prompt is a hope that the model complies. The same lesson in code is true every time.

A learning system that only writes prompt rules leaves most of its value behind

So promotion carries a discipline, and it is a single question asked before anything else. Can this lesson be encoded deterministically? If the answer is yes, it belongs in code and it arrives with an evaluation attached. Only genuinely judgment-shaped lessons, the ones that require reading intent or weighing incommensurable things, stay as prompt rules, and there are fewer of those than most teams expect once they start sorting honestly.

This is the same split that already governs the fleet, applied to learning instead of to analysis. The Follow-On Advisor is barred from arithmetic because four valuation methods are computed in code and the model's contribution is how to weight them. Round Radar may move a deterministic base probability by at most a fifth of the way in either direction, and only with a named reason. The rule in both cases is that the model handles judgment and code handles anything that must be exact. A learning system that only ever produces prompt lines routes every lesson to the judgment side regardless of its shape, which is the same error in a new place.

It also answers a fair objection to the argument we made last time. If agents improve by accumulating rules in their prompts, then a mature agent is a system governed by a long, unaudited pile of accreted instructions that nobody has read end to end. That is a real failure mode, and the promotion ladder is what prevents it. A prompt that stays short because most of its lessons graduated into code is a prompt a person can still reason about.

Three tempting answers, and why we declined each

Each of these is a reasonable response to something real, which is why capable teams reach for them.

THE APPROACH	WHAT IT GETS RIGHT	WHERE IT BREAKS
Fine-tune a model on the firm's data	Weights genuinely are the most durable substrate, and fine-tuning really does encode a domain more deeply than any prompt	It requires pooling examples, which is precisely what our isolation architecture forbids. And a fine-tune cannot be read, versioned per firm, attributed, or deleted on request, which are not optional properties for institutional capital
Add a graph database, because the knowledge is a graph	The knowledge genuinely is a graph. Company to tranche to realization, rule superseding rule, a lesson corroborated across firms. The shape is correct	Graph databases earn their cost at millions of edges and deep multi-hop traversals. At our volume it buys elegance and costs a second system to keep tenant-isolated, which is a poor trade in an architecture whose entire premise is isolation
Store more and inject more of it	Memory is the right substrate, and an agent with more of the relevant history really does reason better than one with less	The constraint is the context window, not the disk. Injecting more of a poorly ranked corpus degrades the agent, because irrelevant precedent is not neutral, it competes. More retrieval is only better when retrieval is good

Isolation is the reason we do not fine-tune

The third row above is an engineering judgment we could revisit at scale. The first is architectural, and it does not move.

Multi-tenancy makes training-data collection the hard problem. Gathering the examples a fine-tune would need means pooling material across firms, and pooling raw material across firms is exactly what we designed the system to make impossible. That is the constraint we described from the security side when we wrote that there is no cross-firm leakage because there is no cross-firm, seen now from the learning side, where it costs us something real.

There is one intentional exception and it belongs in the open rather than in a footnote. Platform calibration aggregates resolved predictions across firms so that every client benefits from the fleet's accuracy record. What crosses the boundary is a shape rather than an example: when the fleet forecasts a raise probability in a given band at a given stage, how often does the raise actually happen. The fencing is deliberately severe. A cell is exposed only past hard re-identification floors, meaning a minimum of twenty resolved claims, at least three distinct contributing firms, and stability across two consecutive recomputations. Only aggregate statistics cross. No per-firm value is ever written, logged, or serialized, and no model sits anywhere in the aggregation path. Our white paper states the equivalent rule for code: what may travel upstream is the generalized capability with its extension points, never a client's specific instantiation. This is that rule applied to knowledge.

Which points at why we prefer in-context learning here, and the reason is governance before performance. For this class of problem a well-retrieved memory block and a sharp learned rule already outperform a fine-tune on a thousand examples. But the deciding property is that the memory block can be read, versioned, attributed to the judgment that produced it, and deleted. A fine-tune cannot be any of those things. For a client who may reasonably ask what the system has learned about them, and ask for it removed, that difference is the entire argument.

The infrastructure was never the bottleneck

The database question turns out to be the least interesting part of this, which is worth saying plainly because it is where these conversations usually begin.

STORE TYPE	VERDICT
Relational	Already running, and it handles nearly all of this. Learning records, memory, predictions, and calibration cells are all naturally tabular
Document	Already covered, via JSON columns on relational tables. A second database buys nothing
Vector	In place for documents, org-scoped with ranked retrieval. Not yet for memory or learning records, which is the one real gap in this design
Key-value	Covered by the relational store at our volume
Graph	Intellectually the right shape and practically unnecessary. Model the edges as rows and traverse them in application code
Column-oriented	Answers analytical questions at a volume we do not have
Hierarchical and object	Not candidates

The graph row is the one worth defending, because it is the tempting one and the shape really is correct. A graph database earns its cost at millions of edges with deep multi-hop traversals, and we have neither. What we would buy is elegance. What we would pay is a second system with its own isolation surface to maintain, in an architecture whose entire premise is that each client's data sits somewhere nothing else can reach. That is a bad trade at any scale where the rows are still traversable in application code.

Five primitives at one entry point, one storage system we already run, and zero new models. The hard engineering is retrieval and the promotion ladder.

The machinery is built and the corpus is young

The honest status is worth stating precisely, because the failure mode of writing about a learning system is describing the architecture as though it were the accumulated result.

The primitives are installed at the entry point every structured agent flows through. The prediction ledger is writing scored claims with their resolution specifications attached. The consolidation of injection into a single learning block is landing now, replacing the fragments individual agents currently build for themselves. What is young is the corpus. Track-record injection carries a deliberate floor, a minimum number of resolved claims before an agent sees its own record, and platform calibration carries a higher one, precisely so that a small sample cannot mislead. Those floors are correct and they mean the loop runs at full strength only once resolution accumulates. A learning system's value is a function of accumulated judgment, and accumulation is the one thing no architecture can shortcut. We would rather describe the machinery accurately while the record behind it is thin than describe it grandly and be corrected by a client who looked.

That is also the shape of the commitment we made about the boundary between people and machines. We argued there that a boundary which never moves is the respectable failure, and that what lets it move honestly is a measured gap between what a machine produced and what a firm was willing to publish, narrowing and staying narrow across a meaningful run of cases rather than a fortunate handful. Everything above is the apparatus that turns that gap into a number. The number is what eventually earns an agent a post it does not hold today, and until then the reviews keep making it better at a job it has not yet been given.

Anyone can build an agent that acts. Building one that gets better, in a way a client can audit and a person is accountable for, is the work.

---

Vantage runs a fleet of more than thirty specialist agents with bounded authority, scored track records, and a learning path that ends in code rather than in an ever-longer prompt. The machines take the coverage. Your team keeps the conviction.

Conviction Made Citable.