Part 4 - Ingest Once. Retrieve Forever.
On the first day of GitHub Copilot's new token billing, a developer burned through most of a month's credits on one thorny problem.
One day. One problem. A month's allowance, nearly gone. Another wrote that half their tokens went on a single small feature. GitHub had metered every input, every output, and the flat subscription that used to hide the cost was gone. The invoice finally showed what a session actually spends.
A small feature is not half a month of thinking. It is a little thinking wrapped in a great deal of context reconstruction. The agent opens cold, remembers nothing from yesterday, and re-reads the files, the history, the state, before it can type a line. Every session rebuilds the world from zero, and now every token of the rebuild is on the bill.
The memory tax was always being paid. It just never had a number on it before.
This part is about the alternative architecture: process information once, keep the intelligence forever, and stop paying rent on your own context.
The index analogy
Imagine a library with no index.
Every question means walking the shelves. Ask again tomorrow, walk the shelves again. Hire a faster reader and the walk gets faster, but the reader walks the same shelves every single time, and the library grows.
That is how current AI workflows treat your information. "Loading context" is walking the shelves: the same emails re-read, the same history re-fed, the same reasoning re-run, each session, at reasoning prices.
A library with an index answers in seconds, because someone did the reading once and wrote down what matters and where it lives.
MrAgentˣ builds the index. Once. Then queries it forever. The index is called the Context Map, and the rest of this part is how it gets built and what it does.
Another way to say it: the pipeline surveys the territory once and draws the map. After that, nobody re-walks the streets to answer a question about the city.
Two doors, both already open
Operational reality enters through two doors, and the system reads both.
The first door is the AI session, because that is where your working life is moving. The options you weighed, the approach you chose, the risks you accepted: increasingly, those decisions happen in a conversation with Claude or ChatGPT, and they are the most context-rich material you produce. Save the session and it enters the pipeline like anything else, compiled into the same typed atoms, stamped as an AI session so your thinking never masquerades as fact. The last part of this series is devoted entirely to that loop.
The second door is email, and it is where the outside world's half lives. Think about what actually has an email behind it: every commitment made to you in writing, every confirmation, every deadline, every scope change, every dispute, every "as discussed on the call." Slack fragments reality into ephemera. Documents capture conclusions without the journey. Email, almost embarrassingly, holds the most complete record of what other people have promised you.
What the two doors share is the only property that matters: neither costs a behaviour change. You already talk to your AI. You already send email. Saying save and forwarding a thread are the entire integration.
That point matters more than any feature. Part two established that any capture step requiring a decision will eventually be skipped. Both doors are as close to zero-decision as capture gets. The way in has to be a door you already walk through, and you walk through these two all day.
What extraction looks like
Here is what happens when a thread arrives, described plainly.
The pipeline reads the whole thread and extracts atomic units of operational knowledge. Not summaries. Atoms. A commitment: someone agreed to do something, by when, for whom. A decision: a choice was made, by whom, on what basis. A risk: something could go wrong and was mentioned, however casually. A task. A sentiment: how someone actually feels about the situation, which is often the most operationally important fact in the thread.
Each atom is stored with its source and its date, and connected to the people, topics, and timelines it touches.
Walk through a real shape. A six-email client thread: proposal, questions, a call summary, a revision, an approval, a follow-up. Extraction yields three commitments (two yours, one theirs), one decision (the revised scope, approved on the 14th), and one risk (their finance team "might need extra time," mentioned in passing, forgotten by everyone).
Those five atoms are now permanent, structured, and connected. The original emails are never processed again. They do not need to be. What mattered has been distilled and filed where it can be found.
That is "ingest once." The reading happens one time, at ingestion, with full attention. Everything afterwards is lookup.
The compounding effect
Now run the clock forward, because this is where the architecture separates from everything in part two.
Week one: perhaps fifty atoms. Useful, sparse. The system knows a little.
Month one: hundreds. Topics have emerged on their own: this cluster is the Acme renewal, this one is the hiring pipeline. Patterns start forming. Load a topic and the brief includes a connection you had not noticed, because the map can see across threads and you can only see inside them.
Month six: thousands. The Context Map now knows your operational history better than you do. Not metaphorically. Literally: it holds every commitment with its state, every decision with its date, and it does not sleep, forget, or get distracted. A commitment from four months ago is in the brief the moment you load its topic again.
Notice what did not happen. The system did not slow down, and it did not decay. Manual systems rot with growth because every note added is future maintenance. Here, growth is just more structured knowledge in a store built for exactly that. Late email is treated exactly like early email. The architecture was designed so scale is not a constraint.
Every system in part two got worse with size. This one gets better. That inversion is the whole product.
Retrieval replaces reasoning
The economics follow directly, and they run opposite to the industry's.
When a question arrives, the map is checked first. "What did we agree with Acme on delivery?" is not a reasoning problem. It is a lookup. The commitment exists as a structured atom with a date and a source. Retrieving it costs approximately nothing.
Only genuinely novel questions reach the model. "Draft a difficult renewal email given the whole history" is real synthesis, and the model earns its cost doing it, with retrieved context handed to it instead of reconstructed from scratch.
Over time the ratio shifts. The richer the map, the more questions become retrieval and the fewer require reasoning. The system gets cheaper to operate as it gets smarter.
Hold that against the day-one credit burn. The stateless agent pays the memory tax on every session, forever, and the bill grows with usage. The stateful system pays for understanding once and amortises it over every future question. One architecture rents context. The other owns it.
The honest caveat
This would be a good place to overclaim, so let me not.
Retrieval scales. Reasoning does not. MrAgentˣ does not eliminate intelligence cost, and anyone who says their system does is selling something. Novel synthesis, strategic judgement, ambiguous interpretation: these still require a model, and models still cost money.
What the architecture eliminates is redundant cognition. The re-reading, the re-briefing, the re-deriving of things that were already known and merely unfiled. That redundancy is most of what you currently pay for, in tokens and in attention.
The correct claim, no larger: retrieval becomes cheap. Continuity compounds. Reasoning becomes dramatically more leveraged, because it is spent only on what deserves it.
The next part shows what it found in my own inbox.
Context Windows Close. AI Forgets Everything. Your Work Should Never Start From Zero.
MrAgentˣ is in private beta. Limited to the first 1,000 until launch.
Join the waitlist