Your agent architecture has a half-life of 6 months

A new model arrives. A framework changes. A new tool-calling standard or agent pattern becomes attractive. Suddenly, the architecture you shipped six months ago no longer fits. Dan Farrelly, CTO and cofounder of Inngest, opens with a practical question: which parts of that system still run as originally written, and did they survive by design?

The question applies whether you adopted a framework, wrote a custom harness, or accumulated an architecture through successive changes. A diagram of components and connecting lines can describe the current implementation without explaining which responsibilities should remain stable. The talk instead develops a model of conceptual layers: a way to decide where a change belongs before it spreads through the system.

Farrelly divides an agent into three layers, using a deliberately simple analogy:

• Execution—the brain: flow, state, durability, and retries. This layer manages how work proceeds and survives interruptions.
• Context—the knowledge: models, prompts, tools, and memory. This is the layer he expects to change most often.
• Compute—the hands: sandboxes, runtimes, and automated browsers. These provide environments in which the agent can act.

The title’s “half-life” borrows the idea of decay from science. Here it is an architectural metaphor, rather than a measured replacement rate: Farrelly estimates that prompts may last weeks, models months, and well-designed execution years. The useful distinction is that these responsibilities age at different speeds. A prompt revision should not force a rewrite of the machinery that preserves completed work.

Coupling lets the shorter half-life spread. Orchestration can disappear inside a chain or framework; state can end up inside a sandbox; retry handling can become entangled with prompt logic. Each choice makes replacing one piece require changes elsewhere. A framework may make the first version feel magical, while a custom implementation may take weeks or months, but neither approach automatically creates useful separation. Abstractions can be missing, too high-level, or merged together.

Execution is the place to invest in stable primitives. Its job is to run code reliably and manage how, when, or whether each piece of work completes, independently of the infrastructure hosting it. For an agent, that includes planning, calling a model, running code, invoking a subagent, looping, retrying, and coordinating. The intended result is straightforward: swap the model, context, or sandbox while retaining the execution layer.

Resumability gives that separation an immediate purpose. Suppose a request fails at step thirty-eight of a long agent run. The system should retry, wait if necessary, and continue from there. Restarting from the beginning can waste tokens, money, time, and work the agent has already completed. A failed model or tool call should not erase the useful progress that preceded it.

For a three-hour run to survive the loss of its worker, its recovery state must live outside that worker. Memory and worker-local disk cannot be the sole source of truth. Farrelly calls for durable, external state. Manual checkpoints or a log that reconstructs state can address recovery, but they also create a design risk: checkpointing and restoration logic can leak into the rest of the harness, making unrelated parts harder to change. The talk establishes this requirement without specifying a persistence or replay algorithm.

Invocation needs its own flexibility. Different entry points and timing requirements should compose within the same execution machinery:

• Entry points: cron schedules, events, APIs, and human participation.
• Delegation: subagents and dynamically chosen workflows.
• Timing: synchronous calls, asynchronous work, and delayed invocation.

Without these primitives, the harness starts absorbing queues, workers, polling, backoff, and scheduling. The agent logic becomes responsible for infrastructure concerns every time a new pattern needs them.

Observability must follow the entire session. Model and tool calls are only part of the path: a database error, permission problem, trigger, or performance issue can determine what actually happens. A trace that starts at the trigger and follows work through the stack makes those causes available for debugging. It also provides the history needed to improve the agent; an incomplete trace leaves both developers and evaluators guessing about the missing work.

Sandboxes let agents execute code, browse, manipulate files, and work on disk. Farrelly treats them as ephemeral compute environments and warns against making sandbox snapshots the mechanism that keeps an agent run alive. If the sandbox owns the run’s state, losing that environment leaves the system trying to reconstruct its progress. A separate execution layer supplies the sandbox’s context, sequence, and durability while the sandbox does the immediate work.

This becomes more important as work moves into the background. A background agent has no person sitting in a request-response exchange waiting for the next message. It may run for minutes or hours and make hundreds of calls. Farrelly uses a possible two hundred tool calls to illustrate the exposure to failures, rather than giving a measured failure rate. Recovery and tracing have to span the process—or multiple processes—because there may be no interactive user present to notice where it stopped.

A loop adds another requirement: the system repeatedly assesses its current state against goals or criteria and decides what to do next. It may run continuously or on a schedule. That requires scheduling, delegation, reliable execution, and inspectable history. Emerging background agents, dynamic workflows, and autonomous loops can also combine, so their execution needs to be inspectable by both humans and agents. The architecture must support the combination rather than assuming one fixed conversational pattern.

The code example makes the layers concrete with a health-check system. Every thirty minutes, a cron-triggered function collects high-level system metrics and passes them to an LLM for a health assessment. If the assessment indicates a problem, the function can invoke a triage agent for the individual service. The useful code distinction is where that conditional invocation sits: scheduling starts the check, context informs the assessment, and the assessment determines whether deeper work runs.

The triage agent then gathers more context and detailed metrics. It passes that material to the LLM and enters an investigation loop, calling tools to seek the root cause. The work may take a minute or several minutes. It may need a sandbox, a cloned codebase, or commit analysis. These are possible investigation activities in the example, rather than a demonstrated incident with a reported root cause.

The conditional branch creates an operational question: did triage run at all? Its timing depends on the health assessment, and its duration depends on the investigation. Observing only the scheduled check would miss the delegated work; observing only model calls would miss why the investigation started. The execution history needs to connect the trigger, decision, and subsequent work so the system can be inspected later.

A third function reviews the system every week. It looks at the history of the health checks and triage work to evaluate whether the system performs as intended. Its questions are specific: do the prompts need adjustment? Are the metrics useful? Does the agent have the data it needs? Is it doing anything, or is it overreacting? The thirty-minute check and weekly review have separate schedules; the reviewer does not need to run immediately after every investigation.

How can a periodic check, conditional investigation, and independent weekly review fit together? The relationship below separates the trigger that launches triage from the history that informs review. This matters because reading past runs is an information dependency, not a requirement that each triage run invoke the reviewer.

The reviewer must understand orchestration as well as model output. It needs logs showing what executed, what the agent chose to execute, which subagents it fanned out to, and which workflows it called. With that history, it can analyze performance and either make a change or return recommendations about where the system underperformed. This is why execution awareness is part of evaluation: a reviewer cannot assess delegated work from the final answer alone.

The example stays deliberately small: three functions for checking, investigating, and reviewing. Their separate responsibilities make it possible to change the prompts, metrics, or investigation behavior without treating the entire system as one indivisible agent. Farrelly acknowledges that production becomes more complex; the example supplies a structure for that complexity, rather than a complete production implementation.

The execution layer also offers a place to connect evaluation data. It sits between user input and the work performed throughout the system; user feedback, actions, and session results can flow through it. Connecting those signals to the actual execution makes it possible to score what the agent did, rather than evaluating an output detached from the path that produced it.

Inngest is Farrelly’s product implementation of this execution layer. He describes durable steps, event triggers, scheduling, agent-to-agent coordination, and full session traces, with no infrastructure for the application team to manage. The intended integration lets the team bring its own model, framework, tools, sandbox, or browser. These are the capabilities presented in the talk; the code example does not compare providers or establish performance results.

Scoring can happen after execution, when the inputs, outputs, and full trace are available. It can also wait for additional events and attach them to the same session. This uses the same delayed-work and event-coordination primitives as the agent itself. The important timing change is that an evaluation need not end when the agent returns an answer: later activity may reveal whether the work was useful.

The ending gives concrete outcome signals:

• Triage: did the investigation lead the engineering team to act, such as opening a PR?
• Research: was the research saved, and was the report useful?

An engineering action is a possible positive signal, not proof that the diagnosis was correct. Farrelly’s point is that these downstream events can support outcome-based scores when they are connected to the originating session, extending evaluation beyond a thumbs-up or thumbs-down response.

The final advice is to build the harness with an explicit understanding of its layers. Models, prompts, and tools will continue changing quickly. Execution primitives that preserve progress, coordinate work, and connect traces to outcomes give those changes somewhere to land without repeatedly rebuilding the whole agent.