What one agent learns, every agent knows.

Problem

Half of what a team knows never makes it into the code

In part one and part two, we kept your context graph fresh and gave every branch its own copy. But even a perfectly current graph only records what the code is, never why the team built it that way. Why the API promises these exact response headers, why the team runs on the cache it already has instead of adding infrastructure, why a core interface must stay synchronous — each was a real decision, made once, and the code keeps the outcome while quietly discarding the reasoning. Human teams bridge that gap with tenure: you ask the person who was in the room. An AI agent has no tenure; every session starts from zero. As Andrej Karpathy put it, working with one is like "a coworker with anterograde amnesia: all they have is short-term memory."

With no memory of the decisions behind the code, the cost splits in two, along a single line — was the answer ever in the code?

C-07

Re-derives what the code encodes

Every session, the agent re-reads the structure and reconstructs logic the team already understands. It stays correct — the code constrains it — but pays for it in tool calls, tokens, and time.

C-08

Re-decides what the code doesn't

For choices never written down — client-facing headers, naming, enforcement scope — there is nothing to inherit, so the agent decides for itself and silently diverges from what the team settled.

You can't hand an agent tenure. But you can give the graph a memory, and let the reasoning travel with the code the same way the map already does.

Solution

AI learnings: a memory on the graph

LatentGraph already builds a living map of your codebase, the graph your agents navigate instead of reading everything from scratch. AI learnings give that map a memory. As an agent works, it writes down the decisions it makes and the constraints it discovers, in plain language, attached to the exact part of the code they're about. Nothing enters team memory on an agent's word alone: a learning is proposed, reviewed, and approved by a code owner, exactly like code. When the facts change, newer decisions supersede older ones instead of piling up. And once approved, a learning surfaces on its own — the next time any agent touches that part of the codebase, the decision is simply there, alongside the map it was already reading.

The key insight

Code records what exists. A learning records what was decided — reviewed like code, and surfaced automatically the next time any agent touches that part of the codebase.

Learning · recorded while building the rate limiter

"The counter store stays synchronous, because this is a WSGI app. Anything that builds on it must not introduce async."

Approved to team memory

What this looks like in practice

Claims are cheap, so we measured. We took healthchecks, a real open-source Django service of some 1,300 files, indexed it into LatentGraph, and split one production feature across two agents: rate limiting for its public API. The senior engineer's agent went first, designing and building the core engine — clean and fully tested — and recording six decisions into team memory as it worked: the algorithm it chose, the infrastructure it deliberately didn't add, the internal contracts anything built on top must respect, and the exact behavior API clients would see. Each was reviewed and approved onto the graph before the handoff.

Then a brand-new agent — fresh context, no history, the engineer who wasn't in the room — took over the finishing task: wire the limiter into the public API. We ran that identical handoff twice: once with the six learnings available, once with nothing but the code. Neither run was told a single one of the decisions.

With learnings 7.2 min to done

1Explore It starts the way any engineer starts: reading the code around the task — the API surface, the auth layer, the existing engine.
2Understand · decisions arrive with the code As it explores, the team's recorded decisions surface alongside the very code they're about: why this algorithm, what the contracts demand, how the API must behave. It understands the reasoning as it understands the code.
3Build · to the contracts It builds directly against the existing engine, exactly as the recorded contracts demand: staying synchronous, staying on the existing cache, following the agreed naming. Nothing is re-litigated.
4Ship · and cite The finished integration returns the exact headers the team committed to. Every new test passes; the full existing suite stays green. Its notes cite each inherited decision.

Consistent by construction. The review reads like the team wrote it.

Without 10.7 min to done

1Orient · map by hand With no memory to consult, the agent maps the territory itself: routes, views, auth, settings, test conventions — rebuilding a picture the team already had.
2Re-derive · what code can tell Reading the source, it correctly reconstructs everything the code can reveal: the algorithm, how counting works, where enforcement plausibly belongs. Careful work, at roughly twice the effort.
3Guess · what code can't tell But several decisions were never in the code: the exact client-facing headers, the naming, which endpoints the limit covers. Where the code goes silent, it has no one to ask, so it decides for itself.
4Diverge It commits to different response headers than the team had promised its API clients — a breaking difference for anyone integrating against the API — plus its own naming and a different enforcement scope.
5Ship · clean but wrong All tests pass and the code is clean, but the divergence is invisible to the suite, because the tests were written against its own guesses. It surfaces in review at best, in production at worst.

Good engineering, wrong conventions. Every decision the code didn't encode drifted.

Both runs shipped working, tested code — today's agents are strong. What differed was the path: how much work it took to get there, and whether the result matched what the team had already decided.

With learnings Without

Work to orient · tool calls+78% without

Compute burned · tokens+57% without

59.8k

93.6k

Time to done+49% without

7.2 min

10.7 min

The cost no bar chart captures

The run without memory shipped a client-breaking public API difference — different response headers than the team had promised its clients. Not because the agent was weak, but because the decision it needed was never in the code to begin with.

What this changes for a team

One handoff was the experiment; the payoff is a team. Across dozens of engineers working with agents on the same codebase, a decision recorded once holds everywhere instead of being re-derived and re-decided by each of them. Conventions hold across every agent: one approved contract keeps everyone's agent on the same design, so the drift we measured never starts. New branches inherit automatically: start a feature branch and the team's approved knowledge travels with it — onboarding without the onboarding doc. And it stays governed like code: nothing becomes memory without an owner's approval, and superseded decisions retire instead of resurfacing.

Try it

See it on your own codebase. AI learnings ship with LatentGraph today: index a repo, let your agents work the way they already do, and watch the second session know what the first one learned.

npm install -g @latentforce/latentgraph
lgraph init          # index once, learnings accrue as your agents work

Get started at lgraph.dev →

That completes the series. Part one kept a single graph fresh at ROOT, part two gave every branch its own, and part three gave the graph a memory. Back to the start: Code changes. Context graphs don't. · Your codebase has branches. Your context graph should too.