A companion to What an Agentic Runtime Environment Is—and Isn’t. That piece defined the thing. This one places it in a lineage—and draws out the single design decision that matters most.
Why is it acceptable for some systems to fail and others not to? When is failure binary, when isn't it, and why should you never mix the two? These sound like questions for a reliability engineer. They are about to become the central questions for anyone running AI agents in production—and, like most things worth knowing about runtimes, they are not new. We have been answering them, in one form or another, for decades.
Runtimes are old news
A runtime is the managed environment that sits between the code you write and the machine that executes it. It handles the things you do not want every program reinventing: memory, scheduling, isolation, and failure. The Java Virtual Machine, the .NET CLR, V8 and Node, the browser, and the operating system itself are all runtimes. Each raised the level of abstraction so that developers could stop worrying about a class of problems and trust the environment to manage them.
That is the whole history of the discipline in one sentence: every generation of runtime absorbs a set of guarantees so the layer above can stop thinking about them. The agent runtime is the next entry in that lineage. What is genuinely new is not the idea of a managed execution environment—it is what we are now asking that environment to run. Not a program that starts and stops, but a loop: continuous, stateful, self-referencing execution that has to be supervised turn by turn. A runtime built for requests does not automatically know how to keep a loop bounded, and that gap is where most of today's failures live.
Runtime and orchestration are not the same thing
I have used the two words interchangeably in the past, and I was wrong to. Orchestration coordinates work: it invokes tools, calls APIs, and hands off between agents. A runtime guarantees the conditions under which that work is safe to run at all—isolation, stopping conditions, rollback, auditability. Orchestration is about getting things done. A runtime is about what happens on the bad day—the day a loop runs away, an input turns hostile, or an action has to be caught and undone before it causes harm. Orchestration assumes the happy path; a runtime is built for the moment it breaks.
So the first question is never "how do I orchestrate these agents?" It is "am I orchestrating critical systems or non-critical ones?" The answer changes everything downstream, because it changes what you are allowed to get wrong. I learned that distinction long before I was building software for agents. I learned it in a cockpit.
What the Dreamliner taught me
Decades ago, doing the user-centered design work that eventually led to founding one of the first UX agencies, I was part of a cross-disciplinary team tasked with redesigning the cockpit of Boeing's 747 for the 787 Dreamliner. The Dreamliner had a carbon-fiber cockpit, which allowed for bigger windows, which left less room for buttons—and it needed more functions than the already button-saturated 747.
Our solution changed the way I think about technology. We replaced the wall of buttons with large touchscreen panels that surfaced the relevant controls to pilots based on the phase of the flight plan the plane was in. The goal was never to make pilots less relevant; it was to give them a lighter cognitive load. To fly the 747, pilots carried massive manuals of step-by-step instructions for pressing buttons in sequence—manuals there was barely room for in the crowded cockpit. Flying became more intuitive because we could contextualize the pilot's needs from the flight-plan data and show only the interface that mattered. Context was the key to a better experience. The other takeaway has stayed with me ever since: if you can automate a 787, you can automate a company.
But there is a deeper lesson buried in that cockpit, and it is the one this piece is really about. The 787 draws a hard line between critical systems and non-critical ones. The flight controls are critical—they work or the plane does not fly. The cabin Wi-Fi is not—it can drop for an hour and no one is in danger. The architecture keeps those two worlds apart on purpose. A non-critical system is never allowed to share fate with a critical one. You do not run the flight surfaces and the entertainment system on the same guarantees, because the moment you do, the cheap thing can take down the essential thing.
The execution envelope
Separating critical from non-critical is necessary. It is not sufficient. Inside the critical systems, aviation has another concept that matters more for agents than almost anything else in the canon: envelope protection.
When a pilot pulls hard on the yoke, the plane does not do what the hands asked for. It understands the intent—climb as fast as we can—and then executes inside what is safe. It accelerates and climbs at the safest maximum rate. There is no direct connection from the stick to the surfaces. There is knowledge of optimal boundaries: a containment envelope. The same goes for descent. These systems are designed to work inside envelopes.
That is a design-values statement, not a technical footnote. The envelope is not defined by the limits of the machine. It is defined by what is safe for the passengers—the protected party. You want the same for a company. If someone jerks the yoke, the system should answer: we know what you mean; we will climb as quickly as is safe.
Guardrails are not enough. By the time your car hits a guardrail, you have gone too far.
Guardrails are collision infrastructure. They are reactive by definition. An envelope makes the dangerous command unexecutable in the first place. Every AI vendor in the market sells “guardrails.” An envelope is a different promise: not a barrier you bounce off after the mistake, but a boundary the mistake cannot cross.
This is also why dropping critical work into a non-critical apparatus fails so badly. Companies automate a use case that looks like writing a poem or drafting an email—human review, human edit, no big deal if it goes wrong—and call it a win. Then they drop a critical workload into that same stack. When the critical one fails, they ditch the whole thing. They never separated the systems that need an envelope from the ones that only need a human looking over a draft. The non-essential work was easy. The essential work needed knowledge of how to keep the plane level. They used one apparatus for both.
Input, output, and the right amount of data
The shift from the 747 to the 787 was also a shift in where the value lived. The 747 was mostly about input. Its systems were largely independent, each one controlled directly, and the pilot's job was to operate them. Output—what the plane told you—mattered less than the levers you pulled. The 787 moved the center of gravity to output: surfacing the right information, at the right moment, in the right amount.
And the operative phrase is the right amount. More data is not better. The right amount is better. Streamlining what reached the pilot was every bit as important as what the pilot could reach. This is exactly the discipline an agent runtime has to impose on a loop. Its job is not to pour every available signal into the model's context; it is to surface what is relevant to this turn, rightsized, and to keep the essential systems uncluttered by the non-essential. A loop drowning in data fails the same way a cockpit full of undifferentiated warnings does.
Binary, and not—and why you don't mix them
Some systems are binary. They work or they do not, and "mostly working" is just a slower way of saying broken: flight controls, payment capture, a medication dose. Other systems are graceful. They degrade, retry, and tolerate partial failure without anyone getting hurt: a recommendation, a first draft, a search result that could have been better. Both kinds are legitimate. The mistake is running them on the same guarantees.
Critical systems need binary guarantees—hard stops, provable rollback, isolation, an audit trail, and an execution envelope that keeps unsafe commands from running at all. Non-critical systems need throughput and flexibility, and choking them with critical-grade controls just makes them slow and expensive. Mix the two and you get the worst of both: you over-engineer the cheap work, under-engineer the work that can hurt you, and lose the ability to tell which is which. Deciding, up front, which loops are binary and which are graceful—and refusing to let them share fate—is the single most important design decision in an agent runtime.
If it's critical, don't build your own runtime
People love to talk about agents failing. Almost every one of those stories is really a story about running agents without a runtime that assumes failure in the first place. On the happy path, everything looks fine. It is the runaway loop, the injection attempt, the silent drift, the rollback nobody tested that separate infrastructure from a demo.
Which leads to the most practical thing I can tell you: if you are running anything critical, do not build your own runtime. Building one means rebuilding decades of hard-won guarantees—isolation, stopping conditions, versioning, auditability, exfiltration controls—and rebuilding them correctly, under deadline, while the stakes are real. That is not a weekend project layered under your agents. If your loops are non-critical, a lighter setup is fine. The moment any of them become critical, the guarantees have to already be there, because you cannot retrofit them after the bad day arrives.
Criticality migrates
And they will become critical, which is the part most people miss. Criticality is not fixed. Systems start non-critical and quietly become load-bearing. The internet began as something you dialed into—down by default, an optional convenience. Now it is assumed to be always on, and entire businesses stop when it is not. Nobody re-classified it in a meeting; the dependency simply grew until failure was no longer acceptable.
Agents follow the same path. The loop that drafts your email today is non-critical. The one that reconciles your books, releases a payment, or updates a patient record tomorrow is critical—and it is often the same loop, six months later, with more trust placed on it. Design for the day your non-critical loop becomes critical, because it will. That foresight is the whole job.
The short version
The model decides, the runtime makes the loop real and keeps it bounded—inside an execution envelope, not behind a guardrail. And a real runtime knows which loops are allowed to fail and which are not—and never lets them share fate. That knowledge, far more than raw autonomy, is the history of runtimes and the future of agents.
The rest of the Dreamliner argument—what federated architecture replaced, the impossibility threshold, feature compression, and why there is still no standard for the envelope—is in the companion piece: Guardrails Are Not Enough.
Disclosure: I'm co-founder and CEO of OneReach.ai and co-author of Age of Invisible Machines, which is where the Dreamliner story first appears. The framing here is the one we build our agentic runtime environment against—take it, and hold any vendor, including ours, to it.