$cat agent-architecture-half-life.md

Your Agent Architecture Has a Half-Life of 6 Months

July 24, 202613 min readby MDflowview as .md

Three stacked emerald wireframe layers on a dark terminal grid — the top one dissolving into particles, the middle eroded, the bottom solid and brightly lit

If you have been building agents for more than six months, you have already rewritten something. A new model landed, a framework hit a major version, a tool-calling standard shifted, and the architecture that fit in January stopped fitting in June.

The useful question is not whether that will happen again. It is which parts of what you shipped last quarter survived — and whether they survived by design or by accident. That framing comes from a talk at AI Engineer by Dan Farrelly, CTO of Inngest, and it is the most practical way we have seen to decide where to spend architectural effort in a field that reprices itself every few months.

TL;DR — Your agent architecture has a half-life: prompts decay in weeks, models in months, execution logic can last years. Most teams couple all three, so the fastest-decaying layer drags the rest into a rewrite. Split the harness into execution (the brain), context (the knowledge) and compute (the hands), and invest in execution — resumability, invocation patterns, full-session observability. Then do the thing the three-layer model under-rates: split the context layer itself into volatile plumbing and durable knowledge, and keep the knowledge in plain markdown you own. That is what MDflow is for. Start free.

What is the agent architecture half-life?

Half-life is the time it takes for something to decay by half, and every layer of an agent stack has a different one. Farrelly's estimates, from building agent infrastructure full time:

Layer	What lives there	Rough half-life
Context	Models, prompts, tools, memory	Prompts: weeks. Models: months.
Compute	Sandboxes, runtimes, browsers	Months
Execution	Flow, state, durability, retries, scheduling	Years — if you design it that way

The layers are a mental model, not a package you install. Most architecture diagrams for agents show boxes and arrows — planner, router, tool registry — which tells you what exists but not what to protect. The half-life view tells you what to protect.

And the failure mode is specific: when the layers are coupled, the shortest half-life wins. Orchestration buried inside a framework chain. Run state kept on a sandbox's disk. Retry logic tangled with prompt logic. None of that fails a test. All of it means you cannot swap one thing without rewriting nearly everything — which is technical debt under a different name, and it is the reason "we should try the new model" turns into a two-week project.

The trap is not that things change. It is that nothing was designed to let them change independently.

Why the execution layer is the durable one

The execution layer is the system that runs your code reliably — deciding how, when and whether each piece of work completes, independent of the infrastructure underneath. It has stayed stable while everything above it churned, because its requirements come from the shape of long-running work rather than from this quarter's model. Three of them matter.

Resumability. Agents now run for minutes or hours across hundreds of tool calls, and at that length at least one failure is a certainty rather than a risk. If step 38 fails, you want to retry, wait or continue — not restart and re-pay for the 37 steps that worked. That has a hard architectural consequence: a three-hour run cannot hold its state in memory or on local disk. State must be durable and external to the work. Teams that skip this end up hand-rolling checkpointing or log replay, and those improvisations leak into every other layer.

Flexible invocation. Real systems need crons, event triggers, plain API calls, human-in-the-loop pauses, sub-agents and dynamically constructed workflows — invoked synchronously, asynchronously and on a delay. If your execution layer does not offer those primitives, your harness code starts absorbing queues, workers, polling, backoff and scheduling, one bad abstraction at a time.

Whole-session observability. Not just LLM and tool calls: database errors, permission failures, trigger latency, the lot. A background agent has no user sitting in front of it waiting, so the trace is the user interface. If you cannot see a full trace from trigger through the entire stack, you cannot debug the run, and you certainly cannot improve it.

One corollary is worth stating plainly, because it is a common and expensive mistake: a sandbox is not a state store. Sandboxes are ephemeral and stateless by design. Using one for durability or snapshots means losing the state precisely when a crash makes you need it. The sandbox is the hands; the execution layer is the brain that gives the hands sequence, context and durability.

The layer the model under-rates: knowledge

Here is where we would extend Farrelly's framing rather than merely repeat it.

The three-layer model puts models, prompts, tools and memory together in the context layer and marks the whole thing short-lived. That is true of most of it — and it quietly under-rates the one asset in the stack that should outlast the execution layer.

Split the context layer in two. There is context plumbing: prompts, tool schemas, retrieval code, model wiring, the adapter of the month. Its half-life really is weeks, and it should be cheap enough to throw away without ceremony. Then there is context content: the decisions your team reached and why, the spec, the conventions, the runbook, the correction someone made after an agent got it wrong at 2am. That content has a half-life measured in years — the same order as your execution layer, and longer than any framework you are currently using.

It does not decay on its own. It decays because of where teams put it. Bury a year of hard-won knowledge inside prompt files, framework-specific memory objects or a vendor's proprietary assistant memory, and it inherits the half-life of its container. The rewrite that was supposed to cost you a sprint of plumbing costs you the institutional memory too. That is not a migration problem; it is amnesia.

The fix mirrors the resumability rule exactly. Durable state must live outside the work — and durable knowledge must live outside the harness. Three properties make it portable:

Plain text you own — a format every model already reads, that you can export, diff and grep without our help or anyone else's.
Reachable over an open protocol — not one vendor's SDK, so the same store serves whichever agent framework you are on this quarter.
Written, not inferred — authored deliberately so it is auditable and immediately usable, rather than statistically derived and slow to warm up.

And be honest about the third property's limits: even protocols churn. The 2026-07-28 MCP revision is the largest since launch — a stateless core, protocol-level sessions removed, a new extensions framework. That is exactly why the format matters more than the interface on top of it. A markdown file with YAML frontmatter does not care which spec revision fetched it. Protocols are the fastest-moving thing you should be willing to depend on; file formats are the slowest, which is what makes them the right foundation.

Why decoupling matters for developers and AI agents

For developers, the layers change what counts as a design review question. Instead of "is this the right framework?", ask: if we replaced the model tomorrow, what breaks? If the framework shipped a breaking major, what would we keep? If a run dies at step 40, does it resume or restart? Where does state live when the sandbox is gone? Those four questions predict your next rewrite better than any architecture diagram.

For AI agents, the payoff is continuity. An agent's usefulness is a function of the context it can reach, and the machinery around it is replaced far more often than the knowledge is. An agent standing on a durable execution layer and an external knowledge store inherits everything its predecessor learned, because the learning was never inside the harness to begin with. Loop architectures — the increasingly common pattern of an agent that runs on a schedule, compares system state against goals and decides what to do next — depend on this twice over: they need inspectable history to evaluate their own past runs, and they need somewhere durable to write what they concluded.

Which applications benefit most

Background and long-horizon agents — minutes-to-hours runs with hundreds of tool calls, where a mid-run failure is a certainty and restarting from zero is unaffordable.
Self-improving loops — cron-driven systems that assess state, act, and later review their own traces to tune prompts and metrics. They are execution-aware by definition.
Coding agents and software factories — multiple agents from different labs, side by side, where the orchestration layer must be neutral by construction.
Multi-agent and delegated systems — fan-out to sub-agents needs coordination, per-session tracing and a shared place to leave findings that outlive each child run.
Ops, triage and on-call automation — the runbook is the durable asset; the agent that reads it this quarter is not.
Regulated or audited deployments — where "show me what this agent did, and what it read" is a compliance requirement, not a debugging convenience.

How MDflow fits

MDflow is a durable knowledge layer — the part of the context layer that should outlive the harness on top of it. We are not an execution layer, and would not pretend to be: for durable execution, look at Inngest, Temporal, or LangGraph's checkpointing. What we do is keep the content half of the context layer out of the blast radius of your next rewrite.

What already lines up today

Markdown-native, no wrapper. Documents are stored as plain markdown, and every shared document has a raw .md twin any tool, model or CI job can fetch — this post included, at /blog/agent-architecture-half-life.md. The storage format is the interchange format, which is why it has no half-life worth measuring.

Open protocols, several of them. MDflow exposes a remote MCP server — Claude and the ChatGPT app connect with an OAuth sign-in and no pasted token, while Cursor, Codex and Claude Code authenticate with a Personal Access Token — plus a plain HTTP API with an OpenAPI spec, a VS Code extension and an n8n node for the workflow steps that never needed a model at all. Multiple interfaces onto one store is deliberate: when one of them shifts under you, the knowledge is still reachable through the others.

Retrieval that survives a model swap. Every folder carries a description stating what its documents are for, and mdflow_get_context ranks those descriptions above folder names and document titles — retrieval without a vector database, and so without an embedding index to re-pay for every time the plumbing changes. Workspaces scope a query to the right part of your work, so an agent reads three relevant documents instead of thirty plausible ones.

Agents write back. The MCP write tools are real, so an agent that concludes something mid-loop can record it in the workspace rather than lose it when the session ends. That is the difference between a system that accumulates and one that starts over — Farrelly's reviewer function needs somewhere durable to put its conclusions, and a chat transcript is not it.

Provenance and governance. Version history records every change with an actor, so agent-written content is reviewable rather than a silent update — useful when the writer is a background run nobody watched. Sharing, collections and comments scope what a person, a client or an agent can see, and client-side encryption covers documents that should never be readable by anything but you.

Where we are headed

Direction, not a dated commitment: serving a whole collection to an agent as one cross-linked bundle, so a spec, its decision log and its glossary arrive together rather than as three separate retrievals; richer typed frontmatter, so a document can carry status, owner and freshness as signals an agent can weigh; and tighter review round-trips for agent-proposed edits before they land.

The bottom line

Nothing in an agent stack is permanent, and pretending otherwise is how teams end up rewriting everything at once. The discipline is to know each layer's half-life and stop letting the fastest one set the pace for the rest.

Invest in execution: durable external state, resumable runs, flexible invocation, whole-session traces. Treat models, prompts and sandboxes as consumables. And separate the two halves of your context layer — throw the plumbing away cheerfully, and keep the knowledge somewhere that does not decay: plain markdown you own, reachable over open protocols, still there after the next three rewrites.

Start free · Connect an AI agent · Read the API docs

Frequently asked questions

What does it mean that an agent architecture has a half-life?

Half-life is the time it takes for something to decay by half. Applied to agent systems, it names the observed fact that different parts of the stack rot at very different rates: prompts survive weeks, model choices survive months, and execution logic can survive years if it is designed to. The problem is not the decay itself but the coupling — when the layers are tangled together, the fastest-decaying part drags everything else into a rewrite with it.

What are the three layers of an agent architecture?

Dan Farrelly, CTO of Inngest, frames a harness as three conceptual layers. The execution layer is the brain: flow, state, durability, retries, scheduling, observability. The context layer is the knowledge: models, prompts, tools, memory — the layer that changes fastest. The compute layer is the hands: sandboxes, runtimes, browsers. They are not components you install; they are a mental model for deciding what to couple and what to keep swappable.

Why is the execution layer the one worth investing in?

Because it is the only layer whose requirements have stayed stable while everything above it churned. Long-running agents need to resume mid-run after a failed step rather than restart, which means state must live outside the work. They need many invocation patterns — cron, event, API, human-in-the-loop, sub-agents — and full-session traces across tool calls, database errors and permission failures, not just LLM calls. Get those primitives right and you can swap the model, the framework and the sandbox without touching them.

Is a sandbox a good place to keep agent state?

No. Sandboxes are ephemeral and stateless by design, so using one for durability or checkpointing is an anti-pattern — the state is lost exactly when you need it, after a crash. The sandbox is the hands; the execution layer is the brain that gives it sequence, context and durability. Keep run state in a durable store outside the sandbox.

How do you keep the context layer from decaying with the rest of the stack?

Split the context layer in two. The plumbing — prompts, tool schemas, retrieval code, model wiring — genuinely has a short half-life and should be cheap to throw away. The content — decisions, specs, conventions, runbooks, corrections — is the longest-lived asset you have, and it only decays because teams bury it inside the plumbing. Store it as plain markdown you own, reachable over an open protocol, and it survives every rewrite above it.