The Transcript Trap: A Better Way to Scale AI Agent Context

A technical case study of NanthAI:Edge.

Most tool-using AI agents scale history the wrong way: every tool call, tool result, generated file, retry, summary, error, and continuation gets pushed back through the visible chat transcript until it is trimmed, compacted, or lost.

In NanthAI:Edge, this is not just a theory. In internal comparison tests, assembled graph context reduced prompt exposure from 1905 to 221 tokens for a multi-tool file-generation workflow, from 1986 to 197 tokens for a contradiction/supersession workflow, and from 1020 to 142 tokens for a deferred document-picker workflow. That does not prove better task success, but it does prove that the model-facing context surface can be made materially smaller while preserving recovery and provenance state.

The easiest way to build an AI agent is still to keep appending things to the chat.

The user asks a question. The model calls a tool. The tool returns a result. The result gets dropped into the conversation. The model calls another tool. Another result gets appended. The agent writes a file, hits an error, retries, summarizes, branches, resumes later, maybe spawns a subagent, and the transcript keeps growing.

At first, this feels natural. The transcript is right there. It is ordered. It is readable. It looks like memory. But for tool-using agents, the transcript is a trap.

The transcript is what the user should be able to read. It is not the same thing as what the model should see next. Once an agent runs tools, handles files, calls APIs, works across branches, compares models, or carries private runtime state, the visible chat log becomes a poor source of truth. It mixes product UX, evidence, memory, retry state, privacy boundaries, stale observations, and audit records into one chronological stream.

The better pattern is to treat the transcript as one projection of a richer runtime graph. Raw tool outputs are stored as durable artifacts. Compact memories are derived from those artifacts. Provenance links memory back to evidence. Branches, participants, model runs, tool calls, checkpoints, and policy decisions are separate entities. Each model request receives a policy-governed context assembly from that graph, not a blind replay of old chat messages.

That is the architecture this article argues for: not "more memory," not "just use a bigger context window," and not "GraphRAG for everything." The point is more precise: an agent's history should be durable without being replayed forever, and model context should be assembled deliberately rather than inherited from message order.

Abstract

Tool-using large language model (LLM) agents face a structural tension between conversational history, runtime state, tool evidence, memory, privacy, and context economy. A common implementation pattern treats the visible transcript as both user-facing history and model-facing context: prior messages, tool calls, tool results, summaries, errors, and generated artifacts are replayed into later requests until they are trimmed, compacted, or lost. This approach is simple, but it couples user experience to runtime cognition and makes context selection an accidental byproduct of message order.

This article develops the design pattern of policy-governed context assembly, in which the transcript is treated as one projection of a richer runtime graph rather than as the model's source of truth. The runtime stores raw tool artifacts separately from compact tool memories, preserves provenance from derived memory back to evidence, tracks participant and branch ownership, and records context assembly decisions under explicit policy versions.

The article positions this pattern against prior work on context engineering, agent memory, graph state, event sourcing, provenance-aware memory, stale-memory failures, prompt injection, and agent audit trails. It then uses NanthAI:Edge as one implementation example of the pattern.

The article argues that the strongest contribution is the integrated runtime contract: durable tool artifacts, compact tool memories, first-class context assemblies, policy decisions, participant-scoped runtime ownership, branch-aware graph selection, freshness and supersession policy, raw artifact rehydration, and a deliberate boundary between runtime cognition and the user-visible transcript.

The contribution is a conceptual framework for transcript/context separation in tool-using agents, an implementation-oriented analysis of NanthAI:Edge's durable artifact and context assembly architecture, a prior-art comparison across context engineering and graph runtimes, a risk catalogue for the policy layer, and implementation measurements from internal comparison scenarios.

1. Introduction

In the previous NanthAI article, I wrote about using skills as gates to tool access. The problem was capability bloat. As an agent gains more workflows, integrations, and domain instructions, the naive approach is to keep adding more prompt text and more tool schemas to every request. NanthAI:Edge avoids that by exposing a compact skill catalog first, then loading full instructions and expanding the executable tool registry only when a task justifies it. That solves one half of the context problem. The other half appears after the tools run.

Tool calls produce search results, files, citations, API payloads, OAuth-derived data, errors, partial outputs, retry state, generated artifacts, private scratch state, stale external observations, subagent state, and continuation checkpoints. If the runtime keeps replaying all of that through the visible chat transcript, the model context becomes expensive, noisy, and sometimes wrong.

This creates two related problems.

1. Transcript bloat occurs when old tool calls, tool results, generated artifacts, summaries, retries, and operational state accumulate in the conversation history and are repeatedly passed back to the model.
2. Runtime-state ambiguity occurs when the transcript is asked to act simultaneously as user history, model memory, audit trail, retry state, privacy boundary, and tool evidence store.

Both are expensive. They consume input tokens, raise latency and cost, complicate provider routing, and make it harder to tell what the model actually knew when it generated an answer.

More importantly, they can degrade correctness. A model may see stale tool output as current truth. A retry-critical error may be summarized away. A branch may inherit a sibling branch's generated file. A private participant scratchpad may leak into another model's context. A compact summary may lose the exact value later needed for audit or rehydration.

This article examines a structured alternative: policy-governed context assembly over a runtime graph.

The pattern is simple: treat the transcript as the human-facing history, store raw tool artifacts separately from messages, derive compact tool memories from artifacts, preserve provenance from memory back to raw evidence, assemble each model request from graph state under explicit policy, and record enough of the assembly decision to explain what the model saw and why.

In NanthAI:Edge, the public chat UI did not need to change for the architecture to work. Users still see messages, tool cards, generated files, citations, branches, retries, continuations, and model responses. Behind the scenes, the runtime separates transcript, artifacts, memories, policy decisions, and context assemblies.

The same boundary applies across runtime modes. A normal chat turn, a multi-model comparison, an autonomous discussion, a child subagent run, a parent resume after subagents, a scheduled job, and a branch send do not all have the same context contract. A debate-style autonomous discussion should preserve speaker labels and moderator directives. A subagent child should not leak raw workspace state to its parent by default. A parent resume should respect its deterministic checkpoint instead of blindly querying the transcript. Context assembly has to be runtime-mode aware.

The article contributes a vocabulary for separating transcript, context, artifact, memory, and policy; a concrete architecture for durable tool artifacts and compact tool memories; an analysis of participant-scoped runtime state in multi-model and subagent workflows; a comparison with prior art; and an interpretation of implementation measurements and their limits.

2. Background: Context Engineering, Memory, and Tool State

2.1 Context Engineering

Context engineering is the practice of deciding what information enters the model context. It is broader than prompt writing. It includes system instructions, conversation history, retrieved evidence, tool outputs, memory, policy, task state, and formatting.

Modern context-engineering guidance supports the idea that model context should be explicitly assembled rather than treated as a raw transcript. Anthropic describes context engineering as the work of managing the information supplied to agents. Haystack and Atlan similarly describe context as structured zones such as instructions, history, retrieval, tool outputs, and memory.

This distinction matters because different context classes have different lifetimes and trust properties. A user message, a generated file ID, an OAuth payload, a stale search result, a retryable tool error, and a document citation should not be pruned, summarized, retained, or exposed under the same rule.

The transcript is especially misleading because it looks complete. It contains chronological evidence that something happened. It does not necessarily contain the raw thing that happened, the policy that allowed it, the branch that owned it, the participant that saw it, or the reason later turns should still trust it. For a simple chat product, chronology may be a good enough proxy for context. For tool-using agents, chronology is only one axis.

This is why the architecture treats context as an assembled projection. The projection can include recent conversation turns, selected tool memories, unresolved tool state, loaded skill state, provider/privacy constraints, and selected raw artifacts. It can also omit records that are stale, private, superseded, branch-ineligible, over budget, or unsafe for the selected provider. Inclusion is a decision, not an accident of message age.

2.2 Agent Memory

Agent memory research commonly distinguishes working memory, episodic memory, semantic memory, procedural memory, and long-term memory. Frameworks such as LangGraph distinguish short-term and long-term memory. Surveys of LLM agent memory emphasize that the field is still fragmented: there is no settled cross-framework schema for memory representation, provenance, freshness, contradiction, or retention.

That fragmentation is important. "Memory" is often used as a broad term for many different things: user preferences, facts extracted from prior conversations, summaries of old dialogue, tool observations, generated file handles, retrieved documents, task plans, execution traces, and provenance references.

The architecture separates user memory from tool memory. User memory handles personalization. Tool memory handles runtime evidence derived from tool artifacts.

That split is more than product taxonomy. It prevents a runtime observation from becoming a durable user fact simply because it appeared in a chat. If a tool reads a Slack thread, that may create a useful bounded memory about the thread state. It should not become a permanent user preference. If a document-generation tool creates a file, the file handle may be durable operational state. It is not the same kind of memory as "the user prefers concise answers."

Tool memory therefore needs fields that ordinary personalization memory often does not need: artifact IDs, source tool names, privacy class, freshness class, provenance locators, confidence source, repair attempts, contradiction links, supersession links, and promotion policy. In this architecture, memory is not "what the model might want to remember." It is a compact, policy-governed representation of evidence the runtime can account for.

2.3 Tool Traces as State

Tool-using agents create state every time a tool is called. The call arguments, result, error, timing, provider, runtime, active skill state, and ownership context may all matter later.

This is increasingly recognized in industry and research. Databricks discusses tool-call trajectories and execution results as agent state. LangGraph persists graph state and checkpoints. MCP makes tools and context sources explicit and structurally loggable. Event-sourcing work argues that autonomous agents need append-only records that support reconstruction and audit.

The key inference is that tool results should not live only as transcript messages. Messages are useful for display. They are a weak storage layer for raw evidence.

A transcript message is usually optimized for human readability and client compatibility. It may be truncated, redacted, summarized, reordered for presentation, or compacted away. That is exactly what a product UI needs. It is not what a recovery system needs when the user later says "use the exact CSV from before" or when an audit asks why a particular file ID was cited.

The architecture captures the artifact before that display-oriented transformation. The message can still show a clean tool card or compact result. The artifact store retains the raw arguments, raw result or error, hashes, byte counts, storage handles, runtime owner, privacy classification, and tool version metadata needed for recovery and audit.

2.4 Stale Memory and Contradiction

Persistent memory introduces a failure mode: the agent may continue relying on information that has become stale, contradicted, or superseded. Benchmarks such as STALE and studies such as LOCCO illustrate that long-term memory is not automatically reliable. Remembering more can make the system worse if old facts are treated as current truth.

This supports explicit freshness and supersession policy. A Slack thread summary, CRM snapshot, calendar availability result, generated file handle, and immutable document version should not age the same way.

The stale-memory problem is not only that old facts become false. It is that the model often receives them without a visible expiration marker. A six-week-old calendar availability result and an immutable document version ID can both appear as "prior context" if the runtime only replays messages. The architecture makes that difference explicit through freshness classes and stale-after metadata.

Contradiction is the related failure mode. Two memories can both be derived from real artifacts and still conflict because they came from different document versions, different branches, different providers, or different extraction methods. The system should not collapse those records into a single last-write-wins summary unless a policy has enough provenance and confidence information to justify that resolution.

2.5 Provenance and Audit

Provenance-aware memory is an emerging theme. MemORAI links graph memories to source turns. Portable Agent Memory proposes provenance-verified memory objects. ARGUS uses influence-provenance graphs to reason about unsafe tool calls. Audit-trail and event-sourcing literature similarly argue that AI systems need reconstructable histories of data, model, tool, and decision events.

For an agent runtime, the important audit question is:

Why did the model say this?

The answer cannot come from the transcript alone. It requires knowing what context was assembled, which memories were included, which raw artifacts were rehydrated, which policies omitted data, and which participant or branch owned the state. There is a second audit question that is just as important:

Why did the model not see something?

This is where policy-governed assembly differs from ordinary logging. A production incident may not be caused by a bad tool result. It may be caused by a useful result being excluded because it was stale, over budget, branch-ineligible, private to another participant, classified as Google-derived data, or blocked from raw rehydration. The architecture records compact omission summaries so debugging can ask about absence, not only presence.

3. Policy-Governed Context Assembly

Policy-governed context assembly treats model context as a projection over runtime state. The transcript is not discarded. It remains the human-facing history. But it is no longer asked to carry every runtime responsibility.

The runtime distinguishes between transcript messages, model runs, tool calls, raw tool artifacts, compact tool memories, loaded skill state, continuation checkpoints, branch lineage, participant ownership, policy decisions, and context assembly logs. A context assembler can then choose what the model sees based on the current task, branch, participant, provider, privacy policy, freshness policy, and recovery state.

This pattern separates four surfaces that are often conflated. The transcript is for the user: readable, stable, and product-friendly. The artifact store is for the runtime and audit layer: raw evidence, recoverability, and retention policy. Tool memory is for model context: compact, provenance-linked, and freshness-aware. Context assembly is for the model request itself: the policy-governed selection for one generation.

The most important relationship is:

tool execution creates artifacts first; memory is a policy decision layered on top.

This is the conceptual core of the architecture. The second relationship is:

context assembly is a policy-constrained graph query, not a transcript transformation.

The assembler starts from the active generation boundary: the current chat, source user message, branch lineage, participant, runtime kind, continuation state, selected provider, loaded skills, and tool availability. It then selects eligible graph records and decides how each one should appear. A recent message may remain conversational context. A tool observation may enter as compact memory. A stale record may appear only as a stale marker and revalidation hint. A raw artifact may be rehydrated when exact evidence is required. An unresolved tool call may be protected as recovery state. A private, stale, superseded, branch-ineligible, or provider-restricted record may be omitted, with the omission reason logged without exposing the content.

This design does not require every retrieval operation to be graph database retrieval. The graph is the runtime model: linked conversations, branches, participants, model runs, tool calls, artifacts, memories, checkpoints, assemblies, and policy decisions. Vector search, indexed table queries, storage reads, and graph traversal can all be implementation techniques inside that model.

A useful mental model is:

User-visible transcript = a readable projection of selected Message nodes

Model-facing context = a policy-selected projection over Message + ToolMemory + ToolArtifact + SkillState + ContinuationCheckpoint + PolicyDecision + Branch lineage

The difference is not academic. A transcript answers, "What did the user and assistant appear to say?" A runtime graph answers the questions the transcript cannot: which model run produced the answer, which tools it requested, which artifacts those tools produced, which memories were derived from those artifacts, which branch and participant owned the state, which policy allowed or omitted each record, and which older memories were stale, contradicted, or superseded.

Those questions are what make the graph approach valuable. It turns context selection into a query over typed relationships rather than a truncation strategy over a list of messages.

In practice, the graph approach has three jobs. It preserves evidence by keeping raw tool artifacts outside the transcript, subject to retention and privacy policy. It creates compact usable context by turning useful artifact content into tool memories for ordinary model calls. And it explains selection by recording why a model saw one projection of the graph instead of another.

The graph does not need to be visible to users. The user sees the conversation. The runtime uses the graph to decide what the next model call should know.

4. Implementation Pattern

This section describes the concrete shape of the pattern as implemented in NanthAI:Edge. The details are useful because they show what has to exist once the transcript is no longer the source of truth for model context.

4.1 Runtime Graph Model

The runtime graph starts by making the important nouns explicit. A Conversation is the user-owned chat container. A Branch is an ordered path through that conversation graph, inheriting prior shared history. A Participant is the model or persona configuration active for a run. A Message is the user-visible transcript node. A ModelRun is one provider-facing generation attempt for one participant, message, or job.

Tool work then gets its own vocabulary. A ToolCall is the model-requested function call, with arguments and call ID. A ToolArtifact is the durable raw execution record for that call or result. A ToolMemory is the compact model-facing memory derived from one or more artifacts. SkillState captures loaded skills, active profiles, direct tools, and integration state visible to a run. A ContinuationCheckpoint stores resumable runtime state across action boundaries.

The assembly layer is also explicit. A ContextAssembly is the versioned decision record for one model-facing prompt assembly. A PolicyDecision records privacy, freshness, pruning, rehydration, provider-routing, or recovery decisions.

The canonical relationships are straightforward.

1. Assistant transcript content is generated by a specific ModelRun.
2. A ModelRun requests one or more ToolCall records.
3. Each executed, failed, pending, or deferred ToolCall produces a durable ToolArtifact.
4. A ToolMemory is derived from that artifact, preserving provenance back to raw evidence.
5. Branches inherit from prior branches without copying all state.
6. A ContextAssembly records which memories were included and which raw artifacts were rehydrated.
7. A ContinuationCheckpoint restores runtime state rather than just transcript messages.
8. A PolicyDecision constrains the assembly so privacy, provider, freshness, pruning, and recovery choices are explicit.

4.2 Durable Tool Artifacts

A ToolArtifact is the durable raw record of a tool execution.

It captures the tool call ID, tool name, arguments, raw result or error, status, message and job ownership, participant and model-run ownership, branch scope, privacy classification, active skills and tool profiles, provider and runtime metadata, and storage handles for oversized arguments or results.

Message-level tool results can still exist for client compatibility and rendering. They may be truncated, summarized, or shaped for UI. That is fine for display. It is not enough for long-running workflows, audit, retry, or exact rehydration.

The important move is to capture full artifacts before message-level truncation. The UI can stay compact while the backend keeps recoverable evidence.

This matters when a later turn needs the exact CSV from an earlier tool call, a failed tool call must be retried, a deferred picker must continue, a cited document must be explained, a generated file ID must survive, a subagent's output must be audited, or a private tool payload must stay out of sibling model contexts.

4.3 Tool Memories

A ToolMemory is a compact, model-facing record derived from one or more artifacts.

Tool memories are separate from user memories. User memories represent personalization and durable user facts. Tool memories represent runtime evidence and tool-derived state.

Tool memories carry source artifact IDs, source tool names, summary text, structured payloads, confidence, confidence source, confidence rationale, ambiguity and limitation notes, privacy classification, freshness class, stale-after timestamp, revalidation tools, provenance locators, last resolution status, repair attempts, contradiction links, supersession links, and promotion policy.

The goal is not to make the model remember everything. The goal is to make memory accountable. A compact memory should retain enough provenance that the system can later answer where the memory came from, whether it is still valid, and whether exact raw evidence can or should be rehydrated.

4.4 ContextAssembly

ContextAssembly is the first-class record of what entered a specific model request.

It stores legacy message count, assembled message count, estimated token delta, raw artifact count, selected memory count, rehydrated artifact count, policy version, assembler version, selected graph references, omission summaries, safety and privacy decisions, graph query timing, policy evaluation timing, and serialization timing.

The audit target is:

Why did the model see this context?

The answer should not be "because it was in the last N messages." It should be closer to:

This response included ToolMemory_123, derived from ToolArtifact_88, inherited from the active branch, visible to this participant, assembled under policy version 4, with raw artifact rehydration skipped because the compact memory was sufficient.

Or:

This response omitted a Google-derived raw payload because the provider-routing/privacy policy classified it as restricted, but included a safe summary and a revalidation tool hint.

4.5 PolicyDecision

Context assembly is policy evaluation, not only trimming.

• Ownership policy asks which participant or model run owns a record.
• Visibility policy decides whether it is participant-private, branch-visible, conversation-visible, or audit-only.
• Privacy policy determines whether the data can be sent to the selected model or provider.
• Freshness policy decides whether a record is current, stale, durable, or needs revalidation.
• Promotion policy decides whether an artifact should become model-facing memory.
• Rehydration policy decides whether compact memory is enough or exact raw evidence is required.
• Contradiction and supersession policy resolve conflicts and replacements.
• Recovery policy protects unresolved, failed, deferred, or retry-critical state.
• Retention policy decides whether the record should be kept, pruned, archived, or deleted.

The implementation records compact policy summaries and omission counts rather than verbose per-record traces for every production assembly. Detailed traces remain available in tests and targeted audits.

4.6 Context Classes

Context is classified by how it should be pruned, retained, summarized, rehydrated, and exposed.

• Conversational context includes user and assistant prose or branch-local discussion, and is eligible for windowing and summarization.
• Operational context includes tool arguments, tool results, workspace paths, and generated file IDs; it should be preserved as artifacts before being summarized.
• Epistemic context includes claims, findings, and extracted facts, and belongs in tool memory with confidence and freshness metadata.
• Provenance context includes artifact IDs, document IDs, and citations, and should be preserved for audit or rehydrated when claims depend on it.
• Policy context includes provider constraints, OAuth scope, and entitlements, and must be enforced before assembly.
• Recovery context includes errors, deferred state, and retry contracts, and should not be pruned while unresolved.
• Planning context includes loaded skills, active profiles, and task decomposition for the current run or continuation.

This prevents message age from becoming the only pruning rule.

4.7 Freshness and Staleness

Tool memories must not silently become eternal truth. Every tool memory receives a freshness class:

• Volatile memories cover things like unread counts, availability, and search ranking.
• Session memories cover temporary runtime files, working directories, and scratch state.
• Bounded memories cover snapshots such as CRM records, Slack thread summaries, or Notion page state.
• Durable memories cover generated file metadata, document citations, and explicit provider entity IDs.
• Permanent memories cover immutable document version IDs or generated storage artifact identities.

The assembler does not inject stale volatile or bounded memories as current facts by default. It can include them as stale context, expose a revalidation path, omit them, or select raw rehydration when exact evidence is required and allowed.

4.8 Contradiction and Supersession

This approach avoids last-write-wins memory where possible.

Tool memories can conflict. One branch may analyze a document draft and produce one conclusion. Another branch may analyze a later version. One provider lookup may report a company headcount that another later lookup contradicts. One model may summarize a source incorrectly while another extracts the exact value from the raw file.

The runtime tracks conflict links, supersession links, confidence, confidence source, source artifacts, limitations, and ambiguity notes. The important fields are directional: conflictsWith marks a disagreement, supersedes means the current memory replaces older memories, and supersededBy points back from an obsolete memory to its replacement.

The policy is conservative. Conflicting memories remain separate records. Superseded memories are normally omitted from current model context, while the current replacement remains selectable. Both sides of a contradiction can be included when uncertainty matters. Resolution requires provenance and confidence, not only recency.

One practical detail matters: supersedes should mean "this current memory replaces older memories." The opposite direction should use a separate field such as supersededBy.

That sounds small, but ambiguity here can cause real bugs. A context assembler that drops the replacement memory instead of the obsolete one can make the model reason from stale state while believing it is being careful.

4.9 Participant and Runtime Ownership

NanthAI:Edge supports multi-model runs, autonomous discussions, subagents, branches, scheduled jobs, and tool-heavy continuations. That makes ownership important.

A visible assistant message can become shared conversation context.

But raw runtime state should not automatically become shared just because it happened during the same chat.

In this architecture, tool artifacts, tool memories, context assemblies, and continuation checkpoints carry ownership metadata such as visibilityScope, ownerParticipantId, ownerModelRunId, sharedWithParticipants, runtimeIsolationPolicy, and runtimeKind.

The default policy is that model-run state is participant-scoped and isolated. User-visible assistant output can become branch or conversation context after finalization. Private scratch state does not leak to sibling participants. Unresolved tool calls remain visible to the owning participant and required continuations. Subagent child artifacts remain private or audit-only until explicitly promoted.

This is one of the more under-documented parts of agent architecture.

Many multi-agent examples discuss collaboration. Fewer define the boundary between what one model said visibly, what one model saw privately, what one model's tools returned, what a child subagent discovered, what the parent can use later, and what remains audit-only.

This architecture makes that boundary explicit.

4.10 Branch-Aware Graph Assembly

NanthAI conversations can branch. That means context assembly cannot be only "fetch recent memories by chat ID." If two branches produce different document IDs, generated files, or analysis results, the active branch should not be polluted by newer sibling branch artifacts.

The fix is to make assembly branch-aware. Assembly candidates are selected from active branch lineage first. Explicitly shared or conversation-scoped records can still fill remaining slots, but sibling-private branch state does not crowd out active-branch context.

The context assembly logs record branch exclusions separately from normal context-budget omissions. This matters because branch bugs are subtle. The model may answer confidently with a file, citation, or document ID that belongs to a different branch. The UI will look fine. The transcript will look plausible. But the runtime will have mixed two incompatible paths.

Branch-aware assembly treats the conversation as a graph, not a flat message list.

4.11 Raw Rehydration

Compact memory is usually enough. Sometimes it is not. If the user asks, "use the exact previous CSV," a summary is not sufficient. The runtime needs to recover the raw artifact.

The architecture supports bounded raw rehydration. The important word is bounded. Storage-backed raw artifacts are rehydrated only after policy selection, not eagerly.

The assembler checks whether exact detail is required, whether the artifact was selected, whether the privacy classification is allowed, whether the byte budget is acceptable, whether the provider route is allowed, and whether the record is unresolved or recovery-critical.

• If yes, the raw artifact can be included.
• If no, the assembler can include a compact memory, a reference, a stale marker, a revalidation hint, or nothing.

This avoids two bad extremes: replaying raw tool payloads forever, and summarizing away evidence that later turns need exactly.

4.12 Runtime Cognition Is Not UX

This architecture adds a lot of internal runtime state. That state does not automatically belong in the chat UI. Tool memories, context assemblies, policy decisions, provenance repair records, omission counts, and graph query traces are runtime cognition.

They should not become conversational prose unless the user asks for an audit/debug explanation or opens a deliberate inspector.

This boundary is important. Many AI products blur it. The assistant starts narrating its memory, policy, internal state, and tool bookkeeping back into the conversation.

That makes the transcript noisier and often less trustworthy. In NanthAI:Edge, the user-facing transcript remains the product surface. The runtime graph remains the execution surface.

Provenance can appear through citations, generated-file cards, debug views, or a future "why did the model say this?" inspector.

But the runtime should not rewrite the conversation history to explain itself.

4.13 Runtime Mode Boundaries

Different runtime modes need different assembly rules. Normal chat and multi-model chat use branch-aware assembled context for the active participant. Autonomous discussion preserves the debate prompt shape, moderator directives, speaker labels, and supported non-text content while adding participant-visible assembled context. A subagent child run captures child-local tool artifacts and memories with child ownership, private or audit-only by default. A subagent parent resume keeps its deterministic checkpoint, attaches selected assembly references, and logs the restore decision instead of blindly querying the transcript. Scheduled jobs use the normal backend generation path where the job creates chat turns and routes into generation. Ideascape branch sends use the same branch-aware generation path after the client sends explicit parent IDs.

This was an important closure step because the hardest context bugs often live at orchestration boundaries. A normal chat turn can use the active branch and participant directly. A parent resume after subagents is different: the parent should receive promoted child summaries, generated-file handles, failed-child status, and retry-relevant state, but not raw child workspace payloads unless those payloads were explicitly promoted.

This requires metadata such as runtime kind, subagent batch/run IDs, parent message/job IDs, parent tool-call IDs, and promotion decisions where needed. The point is not to create more schema for its own sake. The point is to make ownership and promotion decisions representable before the assembler serializes anything into a provider request.

4.14 Subagent Promotion Boundaries

Subagents make transcript/context separation concrete.

A child subagent may call tools, read documents, generate intermediate files, hit errors, and maintain private scratch state. The parent may only need the final child report, a generated-file handle, a compact error summary, or a batch status. If the runtime stores child state only as transcript-shaped messages, it is tempting to replay too much into the parent. If the runtime discards child state after summarizing, audit and recovery suffer.

The runtime uses promotion semantics. Raw child tool arguments and results are child-private or audit-only by default. Generated-file handles become parent-visible after terminal child promotion. The child's final report is visible to parent resume. Failed or timed-out child status can be promoted as compact recovery context. Child scratch or workspace details are not parent-visible unless explicitly promoted.

That gives the parent enough context to continue without turning every child run into raw transcript baggage.

4.15 Retention and Garbage Collection

Durable artifacts create a storage responsibility. The architecture does not imply "store everything forever." It implies that retention becomes explicit.

The retention model has to balance auditability and privacy. Raw artifacts may be retained, archived, redacted, hashed, stored out-of-line, or deleted under policy. Sampled contextAssemblyLogs should be pruned aggressively. Account deletion must clean up artifacts, memories, and assembly logs. Audit-only artifacts should remain outside normal model context. Storage-backed payloads should be rehydrated only after privacy and byte-budget checks. Generated-file and document references need reference-preserving cleanup so active citations and file handles do not break.

This is one reason the architecture is most justified for serious tool work.

Keeping raw evidence improves recovery and audit, but it also increases the burden of classification, encryption, access control, deletion, and provider-routing discipline.

5. Architecture Analysis

5.1 Token-Cost Model

Under transcript replay, the model-facing cost of a tool-heavy conversation approximates:

conversation_window + historical_tool_calls + historical_tool_results + summaries + retry_state

Under graph-based context assembly, the cost approximates:

conversation_window + selected_tool_memories + protected_recovery_state + selected_skill_state + optional_raw_rehydration

The critical distinction is what scales with historical tool volume. In transcript replay, old tool payloads can remain in the replay path until trimmed or summarized. In this architecture, raw artifacts are retained separately and only compact memories, protected unresolved state, or explicitly rehydrated evidence enter model context.

This is the economic core of the architecture.

5.2 Raw Artifacts Versus Compact Memories

The raw artifact/memory split creates two layers. The evidence layer contains full arguments, raw outputs, errors, hashes, storage handles, provenance, and runtime metadata. The context layer contains compact summaries, structured facts, generated file handles, stale markers, confidence metadata, and revalidation hints.

This allows the system to reduce context size without losing auditability. A summary can be cheap and useful, but it should not be the only surviving record.

5.3 ContextAssembly as Cache and Audit Boundary

Context assembly creates a stable boundary between stored state and provider request serialization. The runtime can change how it serializes messages, but the assembly record still captures which graph references were selected and which policy version selected them.

The architecture targets policy-versioned reproducibility, not byte-identical replay forever. That means the same policy version over the same graph snapshot should select the same artifact set, memory set, protected raw state, and policy decisions. It does not guarantee identical tokenization or identical live model output from nondeterministic providers.

5.4 Participant-Scoped Context

In multi-model chat, transcript sharing and runtime sharing are different.

If two models answer the same user prompt, the user may see both final outputs side by side. That does not mean model A's private scratchpad, tool errors, or raw OAuth-derived payloads should be visible to model B.

The architecture makes this distinction explicit through visibility scope and runtime isolation policy.

This is a substantial evaluation advantage. Failures can be decomposed by layer: whether the record was branch-visible, participant-private, audit-only, promoted, stale, omitted by provider/privacy policy, or rehydrated because exact evidence was required.

5.5 Context Assembly as Graph Query

The architecture frames context assembly as a graph query over runtime entities constrained by active branch lineage, participant visibility, runtime isolation, privacy classification, promotion policy, freshness policy, confidence provenance, contradiction and supersession, continuation state, retry/recovery protection, context budget, and raw rehydration bounds.

This is why "GraphRAG" is not the right primary framing. GraphRAG is usually retrieval over domain knowledge or document relations. The runtime's graph includes execution state, policy, participants, branches, artifacts, memories, and context assemblies.

The runtime graph is broader than a knowledge graph.

5.6 Determinism and Reproducibility

The architecture aims for policy-versioned reproducibility, not byte-identical prompt replay forever.

That distinction is important. A provider SDK may change serialization. OpenRouter routing may change the model behind an auto route. Tokenization may differ across providers. A live model call may be nondeterministic even if the input is identical.

The reproducibility target is narrower and more useful. The same policy version over the same graph snapshot should select the same artifact set, memory set, protected raw state, and policy decisions. Privacy, provider-routing, branch scope, retry, and continuation decisions should be explainable from stored state. A prior context assembly should be materially reconstructable for audit/debug workflows. Harmless formatting changes should not destroy semantic auditability.

This is why policyVersion, assemblerVersion, selected references, omission summaries, and timing fields matter. They define the boundary between runtime state and provider-message serialization.

5.7 Why This Is Not Just Bigger Context

Large context windows help, but they do not solve the architecture problem.

A larger window can hold more stale evidence, more private scratch state, more sibling-branch noise, more old tool errors, and more raw OAuth-derived payloads. It can delay the point at which trimming becomes visible, but it does not decide what deserves to be included.

The architecture is not an argument against large context models. It is an argument that context windows should be filled deliberately. The assembler can still use a large window when the task needs it. The difference is that raw artifacts, compact memories, recovery state, and policy constraints compete through explicit rules instead of surviving by chronology.

6. Prior Art Comparison

The architecture sits in a strong lineage of context engineering, graph runtime, memory, provenance, and audit work.

• Context engineering is now a mainstream agent design concept. Anthropic, Haystack, Atlan, and others have all argued that the model context should be explicitly assembled from instructions, history, retrieved data, tools, memory, and task state rather than treated as a prompt string.
• LangGraph has strong precedent for graph state, threads, checkpoints, snapshots, replay, and durable execution patterns.
• Agent memory systems distinguish short-term, long-term, episodic, semantic, procedural, and working memory.
• MCP and tool-use frameworks make tools explicit and loggable.
• Event sourcing and audit-trail literature support append-only execution records and reconstructable histories.
• Provenance-aware memory research, including systems like MemORAI and Portable Agent Memory, points toward source-linked memory.
• Security work around prompt injection, memory poisoning, cross-session leakage, and provenance-aware tool safety supports stricter policy boundaries.

NanthAI's contribution is to integrate those converging patterns into one runtime contract: durable tool artifacts, compact tool memories, provenance, participant ownership, branch-aware graph assembly, policy decisions, and transcript/context separation.

That integration is the point. It turns a collection of useful techniques into a disciplined runtime model for tool-heavy agents.

6.1 What Seems Standard

Several ideas are already standard or close to standard: short-term and long-term memory, compacting old context, using tool outputs in later turns, checkpointing agent state, treating retrieved/tool/user content as potentially untrusted, explicitly managing model context instead of only writing prompts, and storing logs for debugging and observability.

6.2 What Seems Emerging

Other ideas are visible in the literature and in serious frameworks, but not settled: provenance-aware agent memory, stale-memory detection, contradiction and supersession handling, portable memory objects, raw artifact rehydration from compact memories, first-party state stores for provider-side zero-retention constraints, policy-governed context assembly, and memory as an attack surface.

The architecture is aligned with this direction, but it gives these ideas a concrete product-runtime contract.

6.3 What Seems Under-Documented

The most interesting ideas are narrower: ContextAssembly as a first-class persisted record, PolicyDecision linked to each generation, durable raw ToolArtifact separated from compact ToolMemory, participant-private runtime state in multi-model chat, child subagent artifacts that remain private until promotion, branch-aware context assembly over conversation lineage, promotion semantics between observation and memory, and runtime cognition kept separate from the user transcript.

This is where I think the architecture is most useful. Not because each field is individually surprising. Because the combination gives the runtime a vocabulary for decisions that otherwise stay implicit.

6.4 Closest Precedents

The closest framework precedent is LangGraph: graph state, threads, checkpoints, replay, time travel, and durable execution patterns are strongly aligned with the runtime's direction. The difference is scope. The architecture is not only graph execution. It makes tool artifacts, compact memories, participant visibility, branch lineage, context assemblies, and policy decisions first-class records.

Portable Agent Memory and MemORAI are close on memory provenance. They support the idea that memories should carry source links and integrity metadata. The architecture applies that logic to tool artifacts and generation context, not only portable memory objects.

Event-sourcing work is close on audit and replay. It supports append-only event histories and reconstructable execution. The architecture needs that temporal history, but also needs graph relationships among branches, participants, artifacts, memories, and policies.

ARGUS and related provenance-aware safety work are close on the security side. They treat tool decisions as influenced by prior context and use provenance to reason about unsafe actions. The architecture generalizes that instinct: provenance should shape not only safety checks, but also ordinary context inclusion, rehydration, contradiction handling, and audit.

MCP is relevant because tool calls and context sources become explicit. But MCP is an integration protocol, not a retention, provenance, branch, participant, or context assembly policy.

6.5 ZDR and First-Party State

Zero-data-retention and provider-side non-retention constraints make the transcript/context split more important.

If provider-side persistence is unavailable or undesirable, the application owner still needs internal audit records, recovery state, generated-file references, tool-call provenance, participant visibility decisions, deletion and retention policy, and a way to reconstruct what the model saw.

That pushes state ownership back into the product runtime. The provider becomes an execution endpoint. The application becomes responsible for deciding what to retain, what to redact, what to omit, and what to send on each request.

The architecture fits that model. It does not rely on provider-managed threads as the durable source of truth. The backend keeps its own graph state and assembles provider requests from that state.

7. Policy Complexity and How to Manage It

The main engineering challenge is that policy-governed assembly introduces a decision layer that must be designed, tested, and observed.

Transcript replay is simple to reason about. If the message is in the window, the model sees it. If it has been trimmed, the model does not.

Policy-governed context assembly is more powerful, and that power needs guardrails. The policy layer must prevent omitted useful evidence, stale memory inclusion, private-state leakage, hidden retry-critical errors, excessive raw rehydration, insufficient exact-evidence recovery, branch-lineage mistakes, over-trust in model-derived summaries, excessive graph-query latency, and shallow auditability.

This is the central tradeoff. The architecture exchanges accidental transcript inheritance for explicit policy. That is better only if the policy is testable, observable, and bounded.

The architecture is strongest when tool workflows are long-running or artifact-heavy, raw tool evidence matters, privacy or provider constraints matter, branches, subagents, or multi-model runs are common, stale facts can cause real errors, auditability is valuable, and context cost matters.

It is less relevant when chats are short, tools are rare, outputs do not need audit, all state is safe to share, exact evidence is never required later, or engineering resources cannot support policy tests and telemetry.

For a simple chatbot, transcript replay may be enough. For a tool-heavy agent workspace, the complexity already exists. The architecture makes it explicit and testable.

8. Risks and Failure Modes

R1: Policy Bugs

The assembler may omit needed evidence or include forbidden context.

Mitigations: deterministic scenario tests, omission summaries, policy versioning, before/after judgement, and sampled assembly logs.

R2: Storage Growth

Raw artifacts can grow quickly, especially with files, API payloads, stdout/stderr, and generated outputs.

Mitigations: retention classes, GC eligibility, account-deletion cleanup, storage handles, hashing, and audit-only retention policy.

R3: Privacy and Provider Leakage

Stored artifacts may contain OAuth-derived data, Google data, document data, runtime files, or secret-adjacent payloads.

Mitigations: privacy classification, provider-routing policy, raw rehydration gates, metadata-only summaries, and fail-closed omission.

R4: False Confidence from Compact Memories

Summaries can be wrong, stale, or incomplete.

Mitigations: confidence source, provenance locators, freshness class, contradiction links, limitations, and raw rehydration paths.

R5: Stale Memory

The model may rely on old external observations as current truth.

Mitigations: observedAt, staleAfter, freshness class, revalidation tools, stale markers, and omission policy.

R6: Branch Pollution

Sibling branch artifacts may crowd out active branch state.

Mitigations: active branch-lineage query, explicit conversation/shared visibility, and branch-exclusion telemetry.

R7: Participant Leakage

One model participant may see another participant's private tool state.

Mitigations: owner participant IDs, owner model-run IDs, visibility scope, runtime isolation policy, shared-with lists, and promotion decisions.

R8: Latency Drift

Graph queries, provenance repair, and storage rehydration can become expensive.

Mitigations: bounded candidate pools, two-pass rehydration after policy selection, timing telemetry, repair-attempt limits, and latency gates.

R9: Durability Overclaiming

Artifacts and checkpoints help with recovery and audit, but they are not the same as full distributed durable execution.

Mitigations: precise language, idempotency where needed, continuation checkpoints, retry contracts, and external orchestration for stronger workflow guarantees.

R10: Omission Debuggability

The model may fail because relevant state was omitted, not because bad state was included.

Mitigations: exclusion reason counts, deterministic detailed traces, branch-exclusion telemetry, sampled assembly logs, and audit/debug queries that can inspect candidates as well as selected records.

R11: Promotion Drift

Extractor logic may promote too much into durable memory or too little into model-visible memory.

Mitigations: explicit promotionPolicy, extractor tests, confidence provenance, privacy downgrade rules, and raw artifact recovery when a memory was not promoted.

R12: Rehydration Abuse

Raw rehydration can become a hidden path for large or sensitive payloads to enter provider context.

Mitigations: two-pass selection, privacy checks before storage reads, byte budgets, provider-routing gates, and fail-closed omission for OAuth/Google/secret-adjacent data.

9. Implementation Measurements

While full behavioral validation requires broader benchmarks, some claims can be evaluated directly from the current NanthAI:Edge implementation. In particular, the codebase allows comparison between a legacy transcript-replay context and an assembled graph context for fixed tool-heavy scenarios.

These measurements quantify the context-economy side of the argument: how much model-facing prompt material is avoided when old tool payloads are replaced by compact memories, selected graph context, privacy/ownership filtering, and protected unresolved raw state.

The comparison shape was simple. The legacy pass used transcript and tool-message replay with raw tool payload noise. The assembled pass used compact tool memory, selected graph context, privacy and ownership filtering, and protected unresolved raw tool state.

These are implementation measurements, not a public benchmark and not a claim of universal task-success improvement.

9.1 Prompt Context Reduction

The prompt-token deltas were strongly negative in the tested live comparison scenarios.

• Deferred document picker context fell from 1020 to 142 tokens, an 86.1% reduction.
• Multi-tool file generation fell from 1905 to 221 tokens, an 88.4% reduction.
• Stale connected-app memory fell from 1051 to 145 tokens, an 86.2% reduction.
• Multi-skill runtime state fell from 1008 to 179 tokens, an 82.2% reduction.
• Participant visibility fell from 961 to 161 tokens, an 83.2% reduction.
• Contradiction and supersession fell from 1986 to 197 tokens, a 90.1% reduction.

This supports the first context-economy claim of the architecture: successful old tool rounds do not need to remain in the replay path as raw transcript baggage. They can become compact, provenance-linked memories while raw evidence remains recoverable outside the prompt.

9.2 Recovery and Provenance Preservation

Token reduction is only useful if important state is not lost. The tested scenarios therefore included recovery, provenance, privacy, branch, and participant-boundary cases: deferred document picker state, generated files, stale connected-app memory, multi-skill runtime state, participant visibility, contradiction and supersession, broken provenance repair, exact raw CSV rehydration, branch isolation, retry-critical errors, Google-data privacy omission, subagent continuation state, autonomous discussion attribution, subagent child artifact capture, subagent parent resume metadata, scheduled job compatibility, and branch-send compatibility.

The assembled path improved behavior in places where transcript replay was structurally weak. It withheld participant-private scratchpad state, repaired provenance instead of fabricating replacement IDs, selected active branch state, preserved retry-critical errors, omitted Google raw bodies when policy required it, and recovered exact raw artifacts when policy allowed it.

9.3 Runtime-Mode Coverage

The same architecture has to work across generation modes, not only in the simple chat loop. A normal chat turn, a multi-model turn, an autonomous discussion, a subagent child run, a parent resume, a scheduled job, and a branch send all have different context boundaries.

The important lesson from the implementation is that graph assembly has to be tested at those boundaries. Subagent child state should remain private until promoted. Parent resume should use a deterministic checkpoint. Autonomous discussion should preserve speaker labels and moderator instructions. Branch sends should inherit active lineage without pulling in sibling-branch artifacts.

This is where the graph model matters most. The graph does not only reduce tokens; it gives the runtime a vocabulary for deciding which state belongs to which generation mode.

9.4 What the Internal Validation Showed

The internal validation had two layers.

1. The deterministic layer checked that assembly policy preserved the non-negotiable runtime state. Raw tool artifacts were persisted before message-level truncation. Unresolved, deferred, failed, and retry-critical tool state stayed model-visible. Participant-private state was withheld from sibling participants. Stale memories were marked or omitted rather than silently treated as current truth. Superseded memories were omitted while current replacement memories stayed selectable. Broken provenance was repaired or marked stale without fabricating replacement IDs. Branch-local artifacts and memories were selected from active lineage rather than recent sibling branches. Privacy-restricted raw payloads were omitted while safe summaries and revalidation hints remained available.
2. The live comparison layer then represented the same scenarios in two forms: legacy transcript replay and assembled graph context. The assembled path preserved the required recovery/provenance facts while sharply reducing prompt exposure.

In the measured live scenarios above, reductions ranged from 82.2% to 90.1%.

9.5 Interpretation

These measurements validate the context-reduction premise in the tested implementation scenarios. They show that NanthAI:Edge's assembled path can materially reduce default replay of historical tool payloads, exposure of private participant scratch state, stale connected-app state treated as current truth, branch pollution from sibling paths, loss of retry-critical tool state, and fabricated provenance when locators break.

The measurements answer one question:

Does policy-governed context assembly reduce model-facing context exposure while preserving important recovery and provenance state in the tested scenarios?

The answer is yes.

10. Discussion

The pattern I would take from the architecture is this: keep the transcript as the human-facing history, store raw tool artifacts before truncation, derive compact memories from artifacts rather than loose summaries, preserve provenance back to raw evidence, track freshness and supersession, scope runtime state by participant and branch, assemble model context through policy rather than message age, log enough of the assembly decision to explain what happened, rehydrate raw artifacts only when exact evidence is needed and allowed, and keep runtime cognition out of the UX unless the user asks for an audit view.

That is the actual architecture.

For implementation teams, the practical rules are equally direct. Resolve one immutable assembly policy before selecting graph candidates. Fetch active branch lineage before filling from shared or conversation-scoped candidates. Rehydrate storage-backed raw payloads only after privacy and budget policy selects them. Treat subagent child state as private or audit-only until explicit promotion. Log why records were omitted, not only what was included.

Not "long-term memory." Not "GraphRAG." Not "bigger context windows."

A policy-governed runtime that decides what deserves to enter the next model call.

This has several implications:

1. Context assembly becomes a runtime primitive. It should be tested and versioned like any other critical backend contract.
2. Memory becomes accountable. A memory without provenance, freshness, and confidence metadata is not enough for serious tool workflows.
3. Tool outputs stop being transcript baggage. Raw artifacts can be retained for recovery and audit without being replayed forever.
4. Participant boundaries become explicit. Multi-model and subagent systems need to distinguish visible outputs from private runtime state.
5. Branching becomes structural. A branch is not just UI navigation; it constrains which artifacts and memories should influence the next model call.
6. Audit shifts from logs to explanations. The goal is not only to store events, but to reconstruct why a model saw a particular context.

This is the direction we are taking in NanthAI:Edge: agent history should be durable without being blindly replayed, and model context should be assembled from policy-governed graph state rather than inherited from message order.

11. Conclusion

The industry is moving from chatbots to tool-using agents. That changes the state problem. A chatbot can often survive with transcript replay.

An agent that writes files, reads documents, calls APIs, searches the web, spawns subagents, runs scheduled jobs, branches conversations, and compares models cannot treat the transcript as the whole runtime.

The transcript is a projection. It is necessary, but incomplete. The model needs context. The user needs history.

The system needs evidence. The auditor needs provenance. The retry loop needs recovery state. The privacy layer needs policy.

The product needs all of those to coexist without turning every model request into a landfill of old tool payloads.

That is what the architecture does: it gives agent history a durable runtime shape without turning every future model request into a replay of old tool payloads.

Agent capability should not scale linearly with prompt size.

Agent history should not scale linearly with transcript replay.

The next layer is policy-governed context assembly.

References

• Anthropic. Effective context engineering for AI agents. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
• Haystack. Context engineering. https://haystack.deepset.ai/blog/context-engineering
• Atlan. How to structure context for LLM applications. https://atlan.com/know/how-to-structure-context-for-llm-applications/
• LangGraph. Persistence. https://docs.langchain.com/oss/python/langgraph/persistence
• LangGraph. Durable execution. https://docs.langchain.com/oss/python/langgraph/durable-execution
• LangGraph. Add memory. https://docs.langchain.com/oss/python/langgraph/add-memory
• Databricks. Memory scaling for AI agents. https://www.databricks.com/blog/memory-scaling-ai-agents
• Google Cloud. What is Model Context Protocol? https://cloud.google.com/discover/what-is-model-context-protocol
• Portable Agent Memory. https://arxiv.org/html/2605.11032v1
• MemORAI. https://arxiv.org/html/2605.01386v1
• ESAA: Event Sourcing for Autonomous Agents in LLM-Based Systems. https://arxiv.org/abs/2602.23193
• Audit Trails for Accountability in Large Language Models. https://arxiv.org/html/2601.20727v1
• STALE. https://arxiv.org/html/2605.06527v1
• Evaluating the Long-Term Memory of Large Language Models. https://aclanthology.org/2025.findings-acl.1014/
• OWASP Agent Memory Guard. https://owasp.org/www-project-agent-memory-guard/
• OWASP. LLM Prompt Injection Prevention Cheat Sheet. https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html
• ARGUS. https://arxiv.org/html/2605.11053v1
• Beyond RAG for Agent Memory. https://arxiv.org/html/2602.02007v2
• LongMemEval-V2. https://arxiv.org/html/2605.12493v1
• Agentic Memory. https://arxiv.org/html/2601.01885v2
• Governing Evolving Memory in LLM Agents. https://arxiv.org/html/2603.11768v1
• Giskard. Cross-session leak: when your AI assistant becomes a data breach. https://www.giskard.ai/knowledge/cross-session-leak-when-your-ai-assistant-becomes-a-data-breach
• Unit42. Indirect prompt injection poisons AI long-term memory. https://unit42.paloaltonetworks.com/indirect-prompt-injection-poisons-ai-longterm-memory/
• Diagrid. Checkpoints are not durable execution. https://www.diagrid.io/blog/checkpoints-are-not-durable-execution-why-langgraph-crewai-google-adk-and-others-fall-short-for-production-agent-workflows
• Zero Data Retention in LLM-based Enterprise AI Assistants. https://arxiv.org/abs/2510.11558

Also published on LinkedIn.