# Your agent architecture has a half-life of 6 months Dan Farrelly, Inngest | AI Engineer World's Fair 2026 | 19:20 Source: https://www.youtube.com/watch?v=X1kp-ABIIxQ Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks. Page: https://aietalks.com/talks/your-agent-architecture-has-a-half-life-of-6-months Published: 2026-07-21 Tags: agents, observability, reliability, workflows ## TL;DR - Agent systems should separate execution, context, and compute because each layer changes at a different rate. - A durable execution layer should handle retries, resumability, scheduling, orchestration, and full-session observability independently of models, prompts, and sandboxes. - Background agents and continuous loops need inspectable, reliable execution infrastructure because they run asynchronously and can involve many tool calls and failures. ## Summary Dan Farrelly argues that agent architectures decay because teams couple fast-changing parts of the system to slower, more stable parts. He divides an agent into an execution layer for flow, state, durability, and retries, a context layer for models, prompts, tools, and memory, and a compute layer for sandboxes, runtimes, and browsers. The context layer changes often, while a well-designed execution layer can last for years. Execution should support resumability, external durable state, varied invocation patterns, and tracing across the full session. Farrelly applies this model to background agents and continuous loops, where work can run for hours, call many tools, and fail along the way. He also describes a health-check, triage, and review loop that uses execution history to improve the system. Inngest is presented as an execution layer for agents with durable steps, scheduling, event triggers, coordination, traces, and scoring hooks. ## Key ideas ### Agent systems need separate layers because their parts age at different speeds [02:42](https://www.youtube.com/watch?v=X1kp-ABIIxQ&t=162s) Farrelly divides an agent architecture into three layers. The execution layer is the brain, handling flow, state, durability, and retries. The context layer contains models, prompts, tools, and memory, and changes the most. The compute layer is the hands, including sandboxes, runtimes, and browsers. He compares software decay to scientific half-life: prompts may last weeks, models may last months, and execution can last years if designed well. When teams couple these layers, the short life of prompts or models drags the rest of the architecture into rewrites. ### Frameworks often hide the boundaries that teams need to change [04:21](https://www.youtube.com/watch?v=X1kp-ABIIxQ&t=261s) Farrelly says teams commonly use a framework, a prebuilt harness, or a fully custom system. Each option can leave abstractions missing, too high-level, or merged together. Orchestration may be buried inside a chain, state may live in a sandbox, and retries may be tangled with prompt logic. When that happens, swapping a model, tool, or execution approach requires rewriting much of the system. His recommendation is to expect change and invest in the execution layer as the stable part of the architecture. ### Durable execution lets long-running work resume after failures [06:40](https://www.youtube.com/watch?v=X1kp-ABIIxQ&t=400s) The execution layer should run code reliably and manage whether each piece of work completes. It should cover planning, model calls, code execution, sub-agent invocation, loops, retries, and coordination while allowing the model, context, and sandbox to change independently. Resumability is central. If a run fails during a later step, the system should retry or continue from that point instead of starting over. A three-hour run cannot keep its state only in memory or on local disk, so state must be durable and external. ### One execution layer should support many ways to invoke work [08:13](https://www.youtube.com/watch?v=X1kp-ABIIxQ&t=493s) Production agents need more than a single request-response path. Farrelly lists scheduled jobs, events, APIs, human approval, subagents, and dynamic workflows. These invocations may be synchronous, asynchronous, or delayed. Flexible execution primitives let the application choose the pattern it needs. Without them, harness code starts absorbing queues, workers, polling, backoff, and scheduling. Those concerns become tangled, making the architecture harder to change. ### Full-session traces are needed to debug and improve agents [09:01](https://www.youtube.com/watch?v=X1kp-ABIIxQ&t=541s) Observability must cover the whole session, not only model and tool calls. Farrelly includes database errors, permission problems, triggers, and performance in the trace. Developers should be able to see the run from its initial trigger through the rest of the stack. This is especially important for asynchronous systems, where nobody is waiting for an immediate response and failures may happen across multiple processes. Without the complete trace, debugging and iterative improvement become difficult. ### Sandboxes should provide compute, while execution provides durability [09:28](https://www.youtube.com/watch?v=X1kp-ABIIxQ&t=568s) Farrelly describes sandboxes as ephemeral and stateless by design. Agents may need them to execute code, browse, manipulate files, or work on disk, but using a sandbox for durable state or snapshots creates problems when that state disappears. The execution layer should supply the sandbox with sequence, context, and durability. In his model, the sandbox is the hands and execution is the brain. ### Background agents and loops expose the limits of short-lived frameworks [11:29](https://www.youtube.com/watch?v=X1kp-ABIIxQ&t=689s) Emerging systems such as background agents and autonomous loops are long-running, asynchronous, and delegated. They need to be inspectable by people and by other agents, and their patterns must be combinable. A background agent may run for minutes or hours and make many tool calls, making failure likely. A loop repeatedly assesses system state against goals and decides what to do next. It needs schedules, sub-agent delegation, inspectable history, and reliable execution, which Farrelly says frameworks from a few months earlier were not designed to handle. ### A review loop can use execution history to improve the agent [13:14](https://www.youtube.com/watch?v=X1kp-ABIIxQ&t=794s) Farrelly gives a health-monitoring example with three functions. A scheduled health check collects system metrics and asks an LLM whether the system is healthy. If it is not, it invokes a triage agent that gathers detailed context, calls tools, and may use a sandbox to inspect code and commits. A reviewer later examines the history, checks whether triage worked, and decides whether prompts, metrics, or inputs need changes. This requires access to execution logs, sub-agent fan-out, and workflow history. ### Execution data supports outcome-based scoring [15:43](https://www.youtube.com/watch?v=X1kp-ABIIxQ&t=943s) Because user input, system actions, and session results pass through execution, Farrelly sees that layer as a natural place for observability and scoring. Scoring can happen after execution, with access to the full trace, inputs, and outputs. Additional events can be attached later to determine whether an action had a useful result. A successful engineering triage might lead to a pull request, while successful research might produce a saved report. These outcomes provide more information than a simple thumbs-up or thumbs-down. ## Notable quotes - "So, my thesis is think in layers. Decouple them." (04:21) - "A 3-hour run cannot hold state in memory or in disk." (07:32) - "I think of the sandbox as the hands and execution as the brain." (10:14) - "The frameworks of 3 months ago were not designed to handle this." (12:52) ## Tools & references mentioned - Inngest - Buffer - Timezone.io - MailDev - LLM ## Who should watch - You have an agent built on a framework and expect to replace its model, tool standard, or orchestration pattern soon. - Your long-running or asynchronous agents lose work after failures, or their state and retries are tangled with prompt code. - You need traces and outcome data that cover triggers, tools, subagents, workflows, and the final result of a run.