A conference talk by Dan Farrelly, CTO and co-founder of Inngest, on designing AI agent architectures that survive rapid trend turnover. It surveys the shifting "right way" to build agents — RAG, ReAct, prompt chaining, orchestrator-workers, MCP, CLI patterns — where each new trend often forces a rebuild. Instead of predicting the next trend, the talk covers recurring core primitives in production agents, how moving decisions closer to code increases stack flexibility, and how the right execution layer enables faster iteration. # Channel Presentation Observations — Dan Farrelly (Inngest) Talk ## Speaker Identity & Explicit Self-Description - **Name and role:** "I'm Dan, I'm the CTO and co-founder at Ingest" (Inngest). - **Claimed expertise:** "I lead an amazing team over at Ingest. We build a system that reliably executes anything from agents to workflows to contact pipelines... I'm deep building AI infra every day and on top of that also building agents, not just pontificating up here in theory." - **Product self-description:** "This is what we built Ingest for. We're durable execution for AI agents. We're the execution layer." ## Intended Audience - **Practicing AI agent developers/engineers** with production experience: > "If you've been building agents for more than 6 months, you've likely rewritten something, maybe more than once." - Attendees of a **developer conference** ("You all are here", "if you've been to any of the sessions or keynotes") with a vendor expo floor ("come and find me at the ng-js booth... very bright and orange"). - Audience assumed to know current agent tooling concepts: harnesses, frontier labs, sandboxes, slash-loop commands, cron/queue/worker patterns. ## Claimed Scope of Content - **Architecture-level guidance**, not component specifics: > "I want to talk about the conceptual layers when you're building a system like this... Not specific components." - Core thesis: a three-layer model — **execution ("the brain"), context ("the knowledge"), compute ("the hands")** — with different "half-lives" ("prompts last weeks... models, months... execution can last years"). - Prescriptive claims: "think in layers. Decouple them"; execution layer must provide **resumability, flexible invocation patterns, and full-session observability**. ## Observable Presentation Patterns - **Technical conference talk format:** live speech with slide references ("let's look at just some examples of code. It's small on here"), open/close greetings, and a booth call-to-action. - **Practitioner tone with code walkthrough:** a concrete example of a health-check cron → triage agent → weekly reviewer loop ("It's three functions. It's pretty simple by design"). - **Conference-specific timeliness:** references "emerging" patterns "the last couple days" — background agents, dynamic workflows, autonomous loops, agent factories. - **Balanced framing of build options:** discusses frameworks, pre-built harnesses from frontier labs, and custom-rolled systems, critiquing each ("the abstractions either are not there at all or they're too high-level or the layers merge"). - **Vendor pitch integrated at the end:** most of the talk is generic architectural argument; Inngest is positioned as the embodiment of the "execution layer" concept in the final section. ## Claims vs. Demonstrated Patterns - **Creator claim:** expertise from building AI infra daily at Inngest. - **Demonstrated:** fluency in agent engineering vocabulary, concrete failure-mode reasoning (e.g., "a 3-hour run cannot hold state in memory or in disk"), and code-level examples — consistent with the claimed practitioner background. - **Creator claim:** framework-agnostic architectural argument ("You can swap the model, swap the context, swap the sandbox, the execution layer should be able to remain the same"). - **Demonstrated:** the argument resolves into an Inngest-specific pitch, indicating the talk functions as **thought-leadership marketing** for the speaker's company. # Delivery Observations — Dan Farrelly, "Your agent architecture has a half-life of 6 months" ## Tone & Register - **Conversational, plainspoken talk style** throughout — casual fillers and colloquialisms are constant: > "It's not a complaint. It's just the reality. Right, things move faster than ever." > "you don't know what the heck's happening" - **Repeated use of "Right?" and "All right?"** as rhetorical check-ins with the audience — appears many times ("It's just the reality. Right", "So, what is a loop? Right?", "It's going to run every week... Right?"). - **Self-positioning as a practitioner, not a theorist** — established early: > "I'm deep building AI infra every day and on top of that also building agents, not just pontificating up here in theory about how you should build it." ## Recurring Vocabulary & Phrase Patterns - **"I think" as a constant hedging/softening prefix** — one of the most frequent phrases in the talk: > "I think of this as the brain" > "I think that your architecture has a half-life, also." > "I think it's a difficult thing where the state gets lost" - **Metaphorical framing for layers**, repeated for effect: > "I think of this as the brain" / "this is the hands" / "So, I think of the sandbox as the hands and execution as the brain." - **"Half-life" as an organizing metaphor**, introduced and defined explicitly: > "what is half-life? ... it's a scientific term for the time that it takes for something to decay by half. And I think that your architecture has a half-life, also." - **Time-scale vocabulary**: "weeks, if you're lucky", "months", "years", "6 months", "3 months" recur as units of decay and change. ## Teaching Habits - **Rapid-fire rhetorical question sequences** to provoke audience self-reflection: > "Did they survive by accident? Or did you design it that way? Did they survive by design? How did you actually architect your agent? Did you architect it at all?" - **Enumerated structure**: announces "there are three discrete layers" then walks through execution, context, compute; later lists execution requirements as "First, resumability... So, next... So, lastly." - **Concrete worked example** late in the talk (the cron health check → triage agent → reviewer loop), narrated step by step: > "It's three functions. It's pretty simple by design." - **Problem-then-thesis structure**: problems first, then the prescriptive claim: > "So, my thesis is think in layers. Decouple them." - **Direct audience address**: "I want you to think about what you shipped 6 months ago", "You all are here." ## Filler & Disfluency Patterns - **Frequent "So," as a sentence opener and pivot** — extremely common ("So, let's talk about what I mean", "So, what does this look like", "So, to wrap up"). - **Stuttered repetitions under pace**: > "the the the chatbot to respond" > "these these these approaches" > "that that that the middle of the execution layer" - **Verbal stumbles and repairs**: "you can't re- you can't like swap any of these things out"; "cobble together maybe some manual checkpointing." ## Structure of the Close - **Vendor pivot near the end**: the technical talk transitions to product positioning ("So, this is what we built Ingest for. We're durable execution for AI agents.") — a common conference sponsor-talk pattern. - **Summary-and-invite closing**: "to wrap up, build your harness... thanks for listening. I'm Dan. Um come and find me at the ng-js booth. We're very bright and orange." ## Uncertainty Notes - **Video-only evidence**: no slides or delivery pace/tone-of-voice data beyond the transcript, so observations on vocal tone (e.g., enthusiasm, humor) cannot be made. - The transcript ends with music and an off-mic "Mhm," suggesting a Q&A or outro segment not captured here. # Observation Record: "Your agent architecture has a half-life of 6 months" — Dan Farrelly, CTO, Inngest ## Speaker - **Dan Farrelly**, CTO and co-founder at Inngest (self-introduced). He notes his credentials: leads a team building a system that executes agents, workflows, and pipelines; builds AI infrastructure and agents daily, "not just pontificating... in theory." ## Central Thesis > "Think in layers. Decouple them." - Agent architectures have a **half-life**: prompts last weeks, models last months, but **execution can last years "if you do it right."** - Most teams **couple everything together**, so one layer's short half-life "leaks and drags the other components down" — described as **technical debt by another name**. ## Three Conceptual Layers (mental model, not components) | Layer | Metaphor | Contents | Volatility | |---|---|---|---| | **Execution** | Brain | Flow, state, durability, retries | Stable; can last years | | **Context** | Knowledge | Models, prompts, tools, memory | Changes the most | | **Compute** | Hands | Sandboxes, runtimes, browsers | — | ## Problem Diagnosis (stated reasoning) - Teams pick frameworks ("super magical"), pre-built harnesses from frontier labs, or custom-roll systems, but: - Abstractions are missing, too high-level, or the layers merge. - Orchestration gets buried inside frameworks/chains; state lives in sandboxes; retries tangle with prompt logic. - Result: nothing can be swapped out without rewriting almost everything. - Frameworks "of 3 months ago were not designed to handle" emerging patterns; teams will need to design these systems themselves. ## Execution Layer Requirements 1. **Resumability** — pick up after failures (e.g., "a failed reflect step 38") without restarting, avoiding lost tokens, cost, time. State must be **durable and external**, not in memory or disk of a 3-hour run. Manual checkpointing/log-based hydration "abstractions start leaking into other layers." 2. **Flexible invocation patterns** — crons, events, APIs, human-in-the-loop, sub-agents, dynamic workflows; sync, async, delayed invocation. Otherwise harness logic absorbs queues, workers, polling, backoff, scheduling — "a mess [of] bad abstractions." 3. **Full-session observability** — traces from trigger through whole stack, including database errors, permissions, performance, not just LLM/tool calls; essential for debugging and improving. ## On Sandboxes - Sandboxes are "so hot"; agents need them, but they are **ephemeral and stateless by design**. - Using them for durability, snapshots, or state is an **anti-pattern**. - The execution layer gives the sandbox its context, sequence, durability. ## Emerging Architectures - Background agents, dynamic workflows, autonomous loops, "agent factories" — all **long-running, asynchronous, delegated**, needing inspection by humans and agents. - **Background agents**: not request-response; possibly hundreds of tool calls with "at least one failure"; undeguggable without proper infrastructure/observability. - **Loops**: run continuously/on schedule, assess state against goals, decide next actions — require crons, sub-agent delegation, inspectable history, reliability. ## Example System (cron health-check loop) Three functions, "simple by design": 1. **Cron** every 30 minutes pulls system metrics, asks an LLM "Is this healthy?" 2. **Triage agent** — pulls detailed context, investigates root cause in a loop with tools; may spin up a sandbox, clone code, analyze commits; runtime unpredictable. 3. **Reviewer function** — runs weekly, evaluates triage performance; must be **execution- and orchestration-aware** (pull logs, see what sub-agents/workflows ran), then self-adjust or report. ## Measuring Agents - The execution layer sits between user input and system activity — an **ideal hub for observability and scoring**. - Outcome-based scores over thumbs up/down: e.g., "did we open the PR?" — attach follow-up events to sessions to determine whether triage/research actually succeeded. ## Pitch (explicit) - Inngest: "durable execution for AI agents... we're the execution layer" — durable steps, event triggers, scheduling, agent-to-agent coordination, full session traces, no infra to manage; any model/framework/tool/sandbox pluggable. ## Closing Advice > "Get your execution layer right and think about the right primitives, everything else can quickly evolve around it." - Embrace the fast pace of change; the next 3–6 months will be easier if the execution layer is solid. ## Qualifications Preserved - Layer half-lives hedged: prompts "weeks, if you're lucky, maybe a single week"; models "months, again, if you're lucky." - Speaker repeatedly frames claims as opinion: "I think," "in my opinion." - Example system: "I know things get always a lot more complex in production." # Speaker Attribution Record ## Video **Title:** Your agent architecture has a half-life of 6 months — Dan Farrelly, CTO, Inngest **Format:** Conference talk (single presenter, live audience) ## Speakers ### Primary Speaker: Dan (Dan Farrelly) - **Role:** Speaker / presenter; self-identified as **CTO and co-founder at Inngest** (spoken in transcript as "Ingest"). - **Role type:** Creator-equivalent — a company founder presenting his own product and architectural viewpoints. - Self-described credentials (per his own statements, unverified): - Leads a team at Inngest - Builds "a system that reliably executes anything from agents to workflows" - Builds AI infrastructure and agents daily ### Unidentified voice - Brief off-stage exchanges at the start ("Going good." / "All right, good.") appear to be **pre-talk audio checks**, likely an interviewer, AV operator, or co-host — role **unidentified**. ## Provenance & Source Notes ### Referenced concepts (attributed to the speaker's opinion) - Three-layer architecture model: **execution layer**, **context layer**, **compute** - Claim that prompts last "weeks," models "months," execution "years" — speaker's opinion, no cited sources - References to "sessions or keynotes" at the event (uncited, generic) - Code walkthrough: cron health-check, triage agent, reviewer function loop — speaker's illustrative examples ### Third-party claims - None cited from named third parties; no external sources, studies, or frameworks are named. ### Promotional segments — FLAGGED - **Opening credential framing:** "Why should you listen to me? … I'm the CTO and co-founder at Ingest" — promotional self-introduction. - **Product pitch segment (near end):** "This is what we built Ingest for. We're durable execution for AI agents. We're the execution layer… no infra to manage." - **Closing booth call-to-action:** "Come and find me at the ng-js booth. We're… very bright and orange." ### Availability limits - **Comment availability:** Not specified in the provided source material. - **Curated metadata:** None supplied beyond the video title. - Transcript contains speaker disfluencies and apparent transcription of company name as "Ingest"; the title metadata spells it **Inngest**. ## Uncertainty Notes - The pre-talk voice(s) cannot be attributed to any named person. - Event name is implied ("ng-js booth") but not explicitly confirmed in the transcript. \>\> Going good. \>\> All right. There we go. All right. Hello everyone. All right, just checking voice. \>\> All right, good. \>\> All right, well uh my name is Dan and I'm here to talk to you about how your agent architecture has a half-life of 6 months. But first who am I? I'm Dan, I'm the CTO and co-founder at Ingest. And why should you listen to me? Well, first I lead an amazing team over at Ingest. We We build a system that reliably executes anything from agents to workflows to contact pipelines, whatever you want. I'm deep building AI infra every \[clears throat\] day and on top of that also building agents, not just pontificating up here in theory about how you should build it. So speaking of building agents if you've been building agents for more than 6 months, you've likely rewritten something, maybe more than once. A new model a new framework or framework version new tool calling standard, a new pattern, suddenly your architecture doesn't fit. It's not a complaint. It's just the reality. Right, things move faster than ever. You can see if you've been to any of the the sessions or keynotes. So I want you to think about what you shipped 6 months ago and how much of it still runs the way that you originally wrote it. Some parts of your code likely survives. But did they survive by accident? Or did you design it that way? Did they survive by design? How did you actually architect your agent? Did you architect it at all? It's okay. Uh did you use a framework? Did you custom roll something? Was the architecture an intentional design that you really thought through? Or just kind of evolved into what you have now? These are all various ways of where people are these days. So, a lot of folks have talked about harness architecture, building harnesses. But mostly, I think a lot of people draw diagrams and they talk about specific components. Draw just nice lines. It looks very similar like, you know, kind of simple. But I want to talk about the conceptual layers when you're building a system like this. This is maybe the mental model. Not specific components. So, in my opinion, there are three discrete layers. First, the execution layer. I think of this as the brain. It's where flow, state, durability, retries happen. Then there's the context layer. This is the knowledge. All right, this is models, prompts, tools, memory. This is the layer that changes the most. And then there's compute. There are um this is the hands, right? This is sandboxes, runtimes, browsers that you're automating. I think these layers are important to consider for the following reason. It's your half-life. And what is half-life? All right, it's a scientific term. And it's a scientific term for the time that it takes for your for something to decay by half. And I think that your architecture has a half-life, also. So, prompts last weeks, if you're lucky, maybe maybe a single week. Uh the models that you use, months, again, if you're lucky. Uh but I think that execution can last years, if you do it right. So, the problem is that I think that most teams couple everything together. And what happens then is that one layer's half-life kind of leaks and drags the other components down. You're building it's technical debt by another name. So, my thesis is think in layers. Decouple them. So, let's talk about what I mean. Teams run into a lot of issues with the approaches that they choose. You might choose a framework, it might feel super magical to get going. You might grab a pre-built harness from one of the frontier labs or wherever. And or you might custom roll the entire system yourself, and it might take months or weeks or whatever. But I think in a lot of these situations, the abstractions either are not there at all or they're too high-level or the layers merge. You know, like orchestration is buried deep inside the chain or inside the framework, and you don't know what the heck's happening. Uh state might be kept in a sandbox. Uh retries get tangled with prompts, the prompt logic. And what's hard is you can't re- you can't like swap any of these things out without rewriting almost everything. So, I think you need to embrace the change. Know that things are going to change. Know that things are moving fast. But I think also with that is I want to focus on a layer that I think is the stable layer here. Where you can invest and think about and get your abstractions right, so you don't need to rewrite a large component every 6 months. So, I'm talking about the execution layer. I don't think enough people talk about this. And I define it as the execution layer as being the system responsible for running your code reliably, managing how, when, or whether each piece of work completes. And that's independent of the infrastructure that it's on. So, what does this look like in an agent architecture? So, the execution layer manages the full life cycle. You know, plan, call a model, run code, invoke a sub-agent, loop, retry, coordinate. You can swap the model, swap the context, swap the sandbox, the execution layer should be able to remain the same. It's just the the fundamentals. And that's how you, I think, decouple and you build the system that it can evolve for change. So, let's talk about what the execution layer has to do. First, resumability. Your execution layer must enable your system to pick up after failures without restarting from the beginning. You know, agents are handling longer-running tasks than ever before. So, they must be able to resume when an LLM call fails, a tool call fails, everything flakes out. We all know. So, if you have a failed reflect step 38, you should be able to retry, wait, continue onwards, instead of having to go from the beginning, and you're going to lose tokens, costs, time, work that your agent might have completed. So, for this this to work, a 3-hour run cannot hold state in memory or in disk. The state must live outside of the work. So, this means that the state must be durable and external. So, without it, you might cobble together maybe some manual checkpointing. You might come up with a system that has like a log-based approach where you're going to be like hydrating the state back if you have to pick up where you left off. But, I think a lot of those abstractions start leaking into the other layers of your harness, right? It gets harder to change. So, next, a key aspect of the execution layer is that it must enable you to combine a lot of invocation patterns. You're going to need crons. You're going to need to trigger things with events. You're going to need APIs, human in the loop. Subagents or dynamic workflows also must be possible. You're going to need to be able to invoke these things synchronously, asynchronously, delaying invocation. And I think the key here is that flexible execution and orchestration primitives will enable you to build the pattern or the system the architecture that you actually need. So, if not, I think again, your harness logic starts absorbing other concepts like queues, workers, polling, backoff, scheduling. And now you end up kind of a mess bad abstractions. So, lastly, execution needs to provide observability across your entire session. Not just the LLM calls, the tool calls, but database errors, permissions issues, um triggers, performance. So, the full session trace across your entire run is essential. So, if you can't see the entirety of a trace from the trigger through the whole stack, it's really hard to debug it, let alone improve your agent and keep evolving it. So, what about sandboxes? Sandboxes are so hot. So, agents need sandboxes. We kind of like settled upon that at this point in time. They need to execute code. They need to browse. They need to manipulate files. They might work on disk. But, a sandbox is ephemeral and stateless by design. So, using it for durability, snapshots, or something in state, I think is an anti-pattern. I think it's a difficult thing where the state gets lost and you're kind of trying to peel pull the pieces back together. So, I think when you have the execution layer separate, the execution layer is what gives the sandbox its context, its sequence, its durability. So, I think of the sandbox as the hands and execution as the brain. So, So, what's next? All right, what are the next six months of architectures that you're going to need to handle? So, if you're paying attention, you're joining a lot of these sessions, you'll see what architectures are emerging and what each approach brings new engineering requirements. You know, you have background agents, dynamic workflows, autonomous loops, agent factories, whatever you want to call it, all these emerging trends that we're seeing the last couple days. They're all long-running. They're asynchronous. They're delegated. That means that you need to be able to observe them all uh down to the core. All right, they need to be inspectable by human and by an agent. So, the patterns, as you see, they as these things emerge, they must be mixed and combined together. So, what does this all have in common? I think that execution is fundamental to building any of these systems. So, let's just take one example here, background agents, right? They're not request response. There's no person just waiting there for you for the the the chatbot to respond. So, it could might run for minutes or hours. It's going to have maybe hundreds of calls to you know, maybe 200 tool calls. You're going to probably guarantee to have at least one failure in that. So, you can't even debug your background agent that's running asynchronously without the right infrastructure, without the observability, without everything that's going on in that process or multiple processes. And another example that we have is is loop architectures. Right? I think we're talking about slash loop commands and whatnot and coding agents, but I think where we're taking this is how are you building actual systems in your products that employ these these these approaches. So, like what is a loop? Right? A loop is a system that basically just runs continuously or on a schedule and it's assessing the state of the system against the the goals that you set or the criteria that you set and determines what to do next. So, you're going to need crons, sub-agent delegation, the history needs to be inspectable, and of course it needs to be reliable because you don't know when things are running or how the system is continuously continuing to evolve. So, the frameworks of 3 months ago were not designed to handle this. Right? Like you're going to need to design these systems yourself. So, I think you're going to need a proper execution layer. So, let's look at just some examples of code. It's small on here, but in general, let's just look at how we might put it together. In your loop, you're going to need some sort of cron. Maybe that cron here is some sort of health check system runs every 30 minutes, pulls down some key high-level system metrics, and it looks you pass to an LLM. You say, "Is this healthy? Is this looking okay? Should we do more? And it is it is healthy or not? What should we do?" And if it isn't healthy, maybe you just invoke a a triage agent that goes and looks at that individual service and goes and digs more. It's pretty simple looking, right? Now you have this triage agent itself. You've just triggered it. This should maybe pull some more context, pull some detailed metrics. It's just context. And then you're passing to the LLM to start that investigation. Putting in a loop, you're calling some tools, trying to get to the root cause. This may run for a minute. This may run for multiple minutes. It needs to spin up a sandbox, uh maybe clone code, maybe analyze commits. It's going to be doing a lot of work here, and you don't know when this is going to run. It might run, it might not. How do you know? How do you observe that system later? And then to complete the loop, there you may have a reviewer function, right? Like, are we Is the system actually performing as expected? Right? Like, it's going to run every week and look at the history of what just happened and evaluate how the triage system is working. Do we need to adjust the prompts? Do we need to do better metrics? Does this have the data that it needs? Is it doing anything at all? Is it overreacting? So, it needs to be execution aware. And I think it needs to be execution aware, orchestration aware, because it needs to be able to pull the logs of the system and understand, all right, what was executed? What did this agent choose to execute? What sub agents did it fan out? What workflows did it call upon? And then it needs to be able to analyze that and understand what happened and come back to you, either make the change itself or tell you this is where we performed or underperformed. This is what we can do, how we can improve the system overall. So, this completes this improving loop. It's three functions. It's pretty simple by design. It's flexible to iterate on. I know things get always a lot more complex in production, but I think about when when I think you think about the layers this way, makes things a little bit little bit easier to think about building such a complex system that feels like it's, you know, something that you might not be able to reach right now. So, in the spirit of the reviewing functions, what do you think about measuring your agent, how your agent is performing? You know, I think what's interesting is this execution layer sits between what your users' input is and what's happening throughout the system. So, user feedback, actions, um and the results of the sessions all flow through this execution layer. And I think this makes it uh an ideal place because it becomes the hub for observability. And it allows you to be able to score and understand what your agent is doing. So, to iterate on your application, you kind of need all this data connected and it needs to be aware of how your code is actually executing. Right? So, I think the the linking of this is is extremely important. So, this is what we built Ingest for. We're durable execution for AI agents. We're the execution layer. You can plug in any context layer, bring a model, framework, tool, any compute layer. Bring whatever sandbox you want. Bring whatever browser you want. You get durable steps, small primitives, right? Uh event triggers, scheduling, agent-to-agent coordination, full session traces, no infra to manage. And I think like I just mentioned with scores, we also think that that that the middle of the execution layer, when your agent is running, is a key place to instrument and score your agents. When you have access to the data that you need that's all flowing through there or you've just executed something, it's a perfect place to run something after and defer some scoring for with the whole trace information, maybe the inputs and the outputs. So, again, that's just execution orchestration, delayed task deferrals on and since there's also data flowing through, you can also wait for additional events and attach them to the sessions that you're building and understand did this did this actually work, right? If you're if you're running this triage, um was this triage successful? Did it result in an action by the engineering team? Then that means it probably was a positive result. Instead of a thumbs up, thumbs down, it's like did we open the PR, right? If it's a research agent, was this research saved? Was it a good report? That is these these things that are events that you should be able to attach and when you have a system that can connect all these pieces, I think it's really makes doing a lot of those things um like creating outcome-based scores a lot easier. So, to wrap up, build your harness. You know, understand the layers of the architecture. We have to embrace fast-paced pace of change. And I think if you can get your execution layer right and think about the right primitives, everything else can quickly evolve around it. And the next 6 months, the next 3 months will all be a lot easier for especially as everything continues to change. You all are here. So, thanks for listening. I'm Dan. Um come and find me at the ng-js booth. We're right on the other side of this wall. We're very bright and orange. So, thanks everyone. Appreciate it. \>\> \[music\] \>\> Mhm.