Agent Learning Requires Compressing Information into an Executable Reasoning Structure

TL;DR

• One framing: the problem we've all been solving for years is compressing information. That's what a model does, and it's what a harness does — finding ways to take a great deal of information and compress it into an executable format (a transformer is executable; it predicts the next token).
• The next question: more architectures will do this in more complicated ways, so the first thing to figure out is what the types of processes are, and what the optimal architecture or harness is for each.
• Reasoning graphs: a graph of agents. A bottom layer connects to the systems where raw data lives and does nothing but understand that data; a middle layer reasons; a top layer takes the right action at the right time. Any path from bottom to top is one possible reasoning path. It fits processes that must run repeatedly with very high consistency.
• An agent builds the graph: not a human. An architect agent produces it, forming a "handshake between an agent and a harness" — and it gets better at building them every time, with the compounding intelligence living in the model's weights.
• Invoice matching results: a baseline agent harness, even using Fable, gets ~40% right. Their reasoning graph reached 99.9% accuracy, correctly explained the decision in 96% of cases, and took one Fortune 500 client from $5 per invoice to $1.50, and this week to 10 cents.

Key Points

It's all compression (~00:44)

Salehi opened with a single claim: the problem we've all been solving for years is compressing information. At the end of the day that's what a model does and what a harness does — we keep finding different ways to take lots and lots of information and compress it into a format that is executable. A transformer model is executable, and the way it executes is by predicting the next token.

Over the next few years there will be more and more architectures doing this in more complicated ways. So the first problem to solve is: what are the various types of processes, and what is the optimal architecture or harness for each?

Reasoning graphs: a graph of agents (~00:44–00:46)

The one her team has had a lot of success with is the reasoning graph — every circle in the graph is an agent. They've found this is a very good architecture for processes that need to be run repeatedly and with very high consistency.

The layering:

• Bottom: agents that connect to all the different systems where the raw data lives, whose only job is to understand that raw data.
• Middle: agents that do the reasoning.
• Top: agents that take the right action at the right time.

Any path from bottom to top is one possible reasoning path. She noted that variations on the same idea had shown up in other talks that day — the paths can be run in parallel and optimized in various ways.

So how do you create one? It has to be done by an agent. What we'll see more and more, she argued, are handshakes between an agent and a harness, where the agent is trained to know that harness very well — and different architectures will suit different kinds of processes.

The one her team has invested most in is an architect agent aimed at processes that must run consistently and accurately: financial processes, supply chain, anything a company needs to keep running over and over. Non-deterministic, still requiring intelligence, but demanding high consistency and explainability.

The payoff is consistency: they routinely clear 95% accuracy on examples and benchmarks where even Fable only reaches about 40–70%, and it's fast. No custom code is written anywhere in generating the harness — it's all the architect agent working with the harness — so new use cases launch in a matter of weeks.

The most important property, she said, is compounding intelligence held in the model's weights: each time the architect takes a new use case, builds a reasoning graph for it, and learns how, it gets better at doing that.

Case study: invoice matching (~00:47–00:49)

Very large companies receive enormous volumes of invoices and face a deceptively simple decision: pay it or don't. They can't pay everything, because a certain amount of it is fraud; they also can't sit on invoices too long, because late payment ripples through the supply chain. At scale that's millions of invoices a month.

The process: receive the invoice, match it to a PO, normalize it, and handle a long tail of exceptions — different units, different currencies, tax in certain jurisdictions. Her favorite: if the goods are liquid, the invoice may come in up to 5% under the purchase order — but only during summer, because some of it evaporates and there's nothing anyone can do about it.

Which is exactly why the agent has to keep learning. It isn't one-shot, and it doesn't happen inside a single session: it's a long-horizon process spanning weeks and months, and every exception is something to learn from.

The numbers:

• A baseline agent harness, even using Fable, gets about 40% of it right.
• Their architect agent built the reasoning graph for this process — the agents, their wiring, their instructions, which model each agent should use, and a long-term memory per agent. All of those engineering decisions were made by the agent.
• The graph hit 99.9% accuracy on real data, the first version was up and running within a week, and in 96% of cases it not only made the right decision but correctly explained why.
• Cost at one Fortune 500 client fell from $5 per invoice to $1.50, and this week to 10 cents.

Her closing line: those are the kinds of advances available once you can take that learning and compress it into a reusable structure.

Quotes

"The whole problem that we're all solving and have been solving for years now is compressing information." (~00:44)

The first sentence of the talk, and its entire argument.

"If it's liquid, it's okay if the amount on the invoice is up to 5% less than what was on the purchase order — but only during summers, because some of it evaporates and there's nothing you can do." (~00:47)

A funny but very real illustration of why enterprise processes can't be learned in one pass.