Beyond the Transcript: Context by Design

You ask an AI agent to continue a piece of work. Behind that simple request sits a growing pile of messages, tool definitions, search results, files and decisions. Which of those should the model see next? At NanthAI, we have been building around that question for months.

Also published on [9][10].

Pi and its parent company, Earendil, are now bringing fresh engineering effort to this problem through MCP discovery and Codemode. Their recent articles are a welcome contribution to a direction we have been building into NanthAI.[1][2]

Those two earlier articles were detailed technical case studies. Here, we retrace their central ideas and use Pi's recent work to explore the next layer. The starting point is simple: an agent should be able to access far more information and capability than it needs to carry in every prompt.

Our May articles established the foundations. This follow-up examines Pi's approach alongside them.

This follow-up connects those ideas: what enters before tools run, what reaches the model during execution, and what remains useful afterward.

The conversation grows. So does the baggage.

A simple chat app often sends the conversation so far with every new message. Add tools, and results join that history. Add integrations, and a complete tool catalog may accompany every request. Capability and history both become prompt growth.

Also published on [10].

The baseline replays accumulated history. NanthAI prepares context from the conversation, memories and recoverable evidence.

A transcript has a clear purpose: let a person follow the conversation. A model request has another purpose: give the model the information it needs to act now. Those views overlap, but they do not have to be identical. The user can retain a readable history while the runtime prepares a more focused working context.

NanthAI separates the readable conversation from the evidence and runtime state behind it. Raw artifacts preserve tool results. Compact memories carry useful information with source references. Context assembly selects the appropriate material for the next request.

Also published on [10].

Larger context windows and prompt caching are useful alongside this architecture. A larger window provides capacity. Caching can reduce the cost of repeated prefixes. Context assembly decides what deserves that capacity in the first place. It is an information-design choice that still matters as models become more capable.

Give the agent a way in.

Also published on [9].

A skill is a discoverable package of workflow knowledge. Its short description helps the model recognise when to use it. Its full instructions explain how to perform the work. A tool is an executable operation: search, read, calculate, create or update. One skill can need several tools, and several skills can share the same tool profile.

In NanthAI, loading a skill brings in workflow instructions and activates its required tool profiles. The skill connects the task to both the guidance and the capabilities needed to carry it out.

Imagine a request for a research report. The catalog gives the agent enough information to discover the appropriate skill. Loading that skill brings in the research workflow and its required capabilities. If the work later needs a different capability, another skill can expand the active toolset. The model starts with a way to find what it needs.

NanthAI uses skills to activate guidance and tool profiles. Pi adds individual MCP tool discovery alongside its skills.

Pi approaches MCP discovery through compact server descriptions, tool search and inspection. The agent discovers individual declarations and can use them through Codemode or activate tools for direct calls. Pi also supports skills with instructions loaded on demand.[3][5]

That makes the comparison more interesting than simply asking who loads tools lazily. NanthAI explicitly links workflow knowledge to groups of tools. Pi's MCP discovery gives the agent finer selection among individual tools. Both separate knowing that a capability exists from loading its full detail.

Also published on [9].

A "tool memory" should lead back to its evidence.

Also published on [10].

A tool artifact is the execution record: what was requested and what came back, including a file or an error. A tool memory is a smaller representation of useful evidence from that record. It carries a link to its source. Context assembly chooses which messages, memories, references and exact details should enter the next generation.

The transcript, artifacts, memories and assembled context have different jobs. Source references connect them.

Suppose a tool produces a CSV and the agent explains the result. On the next turn, the model may only need the finding and a reference to that file. Later, the user asks for the exact rows behind a number. A compact memory gives the system a route back to the original artifact. The summary is useful because the evidence remains recoverable.

The distinction also helps with time. Calendar availability can become stale quickly; the identity of a generated file may remain useful much longer. Tool memories therefore carry information about freshness and provenance. The assembler can distinguish current evidence from an older observation instead of treating both as equally authoritative because they appear in the chat.

Also published on [10].

Keep the evidence. Choose what travels.

Once tools run, the context problem changes shape. A search or API call can return hundreds of records when the answer needs only a handful of facts. This is where Pi's Codemode offers a particularly useful comparison.

MCP gives tools a common way to connect to agents. How an agent exposes those tools to the model is a separate design choice. Earendil's MCP article and The New Stack's coverage make that distinction concrete: an integration can be available without every schema occupying the prompt from the start.[1][2]

The agent writes JavaScript that calls tools, joins or filters responses, and emits selected output. Intermediate values can stay inside the script, so the model need not receive each full response to move the calculation forward.[4]

Pi can reduce intermediate responses inside an operation. NanthAI selects and reuses evidence across requests.

Also published on [10].

The distinction is the point of intervention. Codemode can reduce intermediate data before it first reaches the model. Our memories and assembly shape what carries forward into subsequent requests. Specialized NanthAI tools already process data internally; the general tool loop returns the payload each tool produces.

These are related techniques at different stages of the same information flow. Pi's contribution gives us another useful place to examine that flow.

This is also why parallel calls alone do not capture Codemode's value. Parallel execution can fetch several results at once. Programmatic processing can then combine those results and emit only the evidence needed for the answer. It changes what the model receives as well as how the calls are organised.

One report. Three context decisions.

Imagine asking an agent to compare two sales exports and explain which accounts changed most. The finished report needs account names, meaningful differences and supporting evidence. The workflow may touch many more rows than the report contains.

Before execution, NanthAI can load the relevant analysis skill and activate its tools. This is the capability-selection problem from our first article. Unrelated calendar or messaging instructions do not need to accompany the analysis.

Three context decisions illustrated with a report. Each column shows a mechanism from the named approach.

During execution, a Codemode script could read both datasets through tools, join records by account, calculate changes and return the largest differences. That illustrates Pi's additional mechanism: express several data-processing steps in code and choose the output the model receives.[4]

Afterward, NanthAI's context architecture can preserve the artifacts and carry useful tool memories into later requests. When the user asks to revise the report, selected context and source references help continue the work. Exact evidence can be recovered when the task requires it.

With our recent local-runtime update, this division of responsibilities is already part of the product. NanthAI can dispatch work to a connected runtime on your Mac, including Pi. NanthAI assembles the relevant conversation, branch, memories and artifact context; Pi combines that prepared context with its own runtime instructions and tools, runs the agent loop and makes the calls to its configured LLM provider.

NanthAI prepares the context; Pi runs on the connected Mac and calls its configured LLM provider. The answer returns to the same conversation.

Bring that back to the sales report: ask for the comparison in NanthAI, and the connected Pi runtime can carry out the analysis with the context NanthAI prepares. The answer returns to the same conversation. When you ask a follow-up, NanthAI prepares the relevant context for the next turn, while the runtime handles execution. Our investment in context assembly and the capabilities of local runtimes come together in one workflow.

The work continues. The context goes with it.

Also published on [10].

That matters when people compare models, resume a task or change execution environments. NanthAI's shared preparation brings together the relevant conversation branch, summaries, recent messages, memories and artifact evidence. The same canonical preparation supports cloud and local turns.

NanthAI prepares shared context for different execution routes. Each route retains its own tool capabilities.

Consider two branches of a planning conversation. One explores a conservative budget; the other develops a more ambitious proposal. Each may generate a different spreadsheet. The next request should use the file and assumptions associated with the branch the user is continuing. The newest file anywhere in the conversation is not automatically the right file.

Pi also maintains continuity through sessions, branches and compaction. Earendil's Pi Durable article extends its work into checkpointed execution and recovery.[6] Its context and execution design deserves to be understood on its own terms.

NanthAI brings shared context into a product spanning clients, models and execution routes, including Pi itself. An execution engine can manage its working session while NanthAI maintains the shared record. This is the practical value of the separation we described in May: the work can continue beyond any single model session.

Also published on [10].

Build the context for the next useful step.

Our May articles established two connected principles: expose capabilities progressively, and assemble useful history deliberately. Pi's recent work brings another strong implementation perspective, particularly around discovering tools and computing over their outputs.

The common problem is how much information an agent must carry to do useful work. The approaches differ in what they select, when they select it and which part of the system owns the decision.

A comparison of emphasis: progressive capabilities, selective results and continuity across the work.

Cloudflare and Anthropic have also published work on code execution over tools.[7][8] We welcome the attention and engineering investment this problem is receiving. There is real value in comparing working designs and learning from the different choices teams make.

For NanthAI, this continues a sustained investment in skills, tool memories and assembled context. Our focus remains the experience those foundations enable: choose the models you want, bring the right capabilities into reach, and keep useful work available for the next step.

Put better context to work with NanthAI

NanthAI is where these architectural choices become a workspace: choose your models, shape their workflows with skills, work with files and continue with useful context in reach.

Draft with one model, get another perspective, and decide where the conversation goes next. Explore a branch without losing the original direction. Bring supported Pi or Codex work from your Mac into the same conversations you use on your phone and browser.

We have been investing in the foundations for that experience for months. It is encouraging to see Pi, Earendil and other teams put their weight and ideas behind the same problem. Better context is becoming a richer engineering conversation, and we are glad to contribute a working product and the thinking behind it.

The AI you need at the price you want

Explore NanthAI

Articles and sources

1. The New Stack: One MCP server used 18,000 tokens before doing anything
2. Earendil: You Said No MCP! (29 September 2026)
3. Pi documentation: MCP servers and tool exposure
4. Pi documentation: Codemode
5. Pi source: Skills and progressive disclosure
6. Earendil: Pi Durable (1 October 2026)
7. Cloudflare: Code Mode: the better way to use MCP
8. Anthropic: Code execution with MCP
9. NanthAI: Skills as Tool Gates (11 May 2026)
10. NanthAI: The Transcript Trap (15 May 2026)

Pi logo from the official Pi press kit. Technical comparison based on source and documentation reviewed in October 2026.

Also published on LinkedIn.