A companion to A Brief History of Agent Runtimes. That piece defined the runtime lineage, the critical/non-critical spine, and the execution envelope. This one is the rest of the Dreamliner argument—what the architecture replaced, why federated stacks stop being buildable, and why the envelope is still unstandardized white space.
Guardrails are not enough. By the time your car hits a guardrail, you have gone too far.
That line is the hinge. Guardrails are collision infrastructure—reactive by definition. An execution envelope makes the dangerous command unexecutable in the first place. In the previous piece, I argued that agent runtimes inherit this distinction from aviation: separate critical systems from non-critical ones, and keep critical work inside a containment envelope defined by the protected party, not by the machine’s tolerances. What I left out is the before picture, the threshold at which the old architecture stops being optional, and the uncomfortable fact that even aviation never standardized the envelope itself.
What the Dreamliner replaced
The Dreamliner’s shared architecture only looks like progress once you can see the system it left behind. That older design was federated in the literal sense: one dedicated box per function—an LRU, a line-replaceable unit—and one wire per relationship. The dominant bus was ARINC* 429: point-to-point links, miles of cable, complexity that scaled with every new pairing of systems. Each function got its own box. Each relationship got its own wire. Integration was a physical object you could weigh.
That is not a nostalgic detail. It is the commercial payload of the whole story. Point solutions are old airplane design. Every enterprise running a dedicated SaaS tool per function—CRM here, ticketing there, knowledge base over there, a new agent wrapper bolted onto each—is flying a 747: a box per system, a wire per integration, complexity scaling combinatorially. The Dreamliner argument is not that orchestration is elegant. It is that federated architecture was the default until it stopped being able to carry the plane.
The impossibility threshold
The Dreamliner was not orchestrated because someone preferred diagrams with fewer boxes. Past a certain systems count, federated architecture stops being buildable at all. The wiring weight, the integration burden, the failure modes—each new point-to-point link multiplies the places something can break—make it physically impossible to keep adding LRUs and cables and still get the thing off the ground. Orchestration on a shared substrate was not a taste. It was the only architecture that still fit inside the constraints.
The same claim holds for agents. Past a certain number of loops, tools, and handoffs, point-solution wiring is not inferior. It is impossible. You cannot keep adding a dedicated stack per use case, a dedicated integration per pair of systems, and a dedicated exception path for every failure mode, and still have something an organization can operate, audit, or trust. That converts the architecture from a preference into a necessity—which is the strongest form of the argument. You are not choosing the Dreamliner pattern because it is fashionable. You are choosing it because the 747 pattern has a hard ceiling, and most enterprises are already past it without admitting it.
Everything is data in, feature-reduced, acted upon
There is an escape hatch readers reach for here: we don’t move anything physical. Ailerons and displays feel like different worlds. They are not, architecturally.
Everything on the aircraft is data in, feature-reduced, acted upon. Whether the output moves a control surface or updates a display is irrelevant to the discipline of the loop. Sensors arrive noisy and abundant. The system compresses the signal to what the next decision needs. An actuator or a screen is just the last step. So the criticality rules—binary guarantees, isolation, an execution envelope—apply to pure information systems as hard as they apply to robots. A payment release, a patient-record write, a compliance decision: same shape as a surface deflection. Data in. Feature-reduced. Acted upon. If your agents only “move information,” you have not left the aviation problem. You are already inside it.
That is also why “rightsized context” undersells the work. More data confuses the system. Compression of the signal is critical engineering, not an editorial preference about tidy prompts. Feature compression is what keeps the essential path uncluttered by the non-essential—what the Dreamliner cockpit did when it stopped showing every button at once and started showing the controls for this phase of flight. An agent runtime that dumps the warehouse into the context window is recreating the button-saturated 747, one token at a time.
There is no standard for the envelope
Here is the finding that deserves a section of its own: there is no standard for the envelope.
The standards world covers almost everything around it. ARINC 653 and 664 standardize the substrate—the partitioned, networked environment the functions share. DO-178C standardizes the process by which software gets trusted. FAA Part 25 standardizes the outcomes the aircraft must meet. But the control laws themselves—Boeing’s C*U, Airbus’s normal law—are proprietary, certified case by case. Even the most standards-saturated safety industry on earth concluded that the substrate is commodity and the envelope logic is the crown jewel. You can share the bus. You do not give away the laws that decide which commands are allowed to become motion.
Map that to now. MCP—and the emerging interoperability layer around tools and agents—is the ARINC of the agent era: an open standard for how things talk on a shared substrate. Useful. Necessary. Commodity, in the long run. What does not exist, open or proprietary, is a standard for the execution envelope of agents: the control laws that decide which proposed actions are allowed to run, under what authority, with what stopping conditions, for which protected party. That is the white space. We are not implementing a standard. We are building the thing standards do not cover yet—the way Boeing and Airbus each had to.
Control laws are exactly the kind of engineering you cannot sprint. They are the ten-years argument one more time: the substrate can move fast; the envelope is where the decades of hard-won judgment live. Anyone selling you “guardrails” as a checkbox is selling crash barriers. Anyone serious about critical agent work is in the control-laws business, whether they use the words or not.
The short version
Point solutions are 747 design: a box per function, a wire per integration, until the wiring makes the plane unbuildable. Past that threshold, a shared substrate with real orchestration is not a preference—it is the only architecture left. Everything in that architecture is data in, feature-compressed, acted upon, whether the last step moves metal or bits. And the piece nobody has standardized—the piece that actually keeps people safe—is the execution envelope: not a guardrail you hit too late, but the laws that make the dangerous command unexecutable from the start.
Part One defined the runtime. This is why the envelope, not the guardrail, is the future of agent safety.
*ARINC (Aeronautical Radio, Incorporated) was founded in 1929 by airlines to coordinate air–ground radio and later became the namesake behind commercial aviation’s major avionics standards—429, 653, 664, and the rest. The company was acquired by Rockwell Collins (now Collins Aerospace); the ARINC name still marks the standards.
Disclosure: I'm co-founder and CEO of OneReach.ai and co-author of Age of Invisible Machines. The Dreamliner framing here continues the argument in A Brief History of Agent Runtimes—take it, and hold any vendor, including ours, to it.