All writing
·Saahil Panikar

The Agent Can Fly. Who Gets to Abort?

AI LeadershipAI GovernanceAgentic AI

An AI agent landed a crew on the Mun and brought them home. Nobody asked it to bring them home.

Josh Kaplan stayed with me one night while he was on a road trip, and we wanted to find something cool to do with AI. We settled on running a space program.

Not assisting one. Running one. The agent would write the flight software, build its own telemetry, design the vehicles after the first, launch, navigate, land, and come home, with no human-written control code anywhere in the stack. The test bed was Kerbal Space Program, a spaceflight simulator with real orbital mechanics, wired to a single Claude Opus 5.5 session through kRPC, a mod that lets outside code fly the game’s vehicles.

A quick translation for anyone who has not lost a weekend to this game. Kerbal Space Program gives its solar system its own names. Home is the planet Kerbin. Its moon is the Mun, and yes, it is pronounced “moon.” The astronauts are small, green, endlessly cheerful Kerbals, which is fortunate given how often early missions end.

We Wanted the Mun. We Started With Orbit.

Our first instinct was the obvious one: go to the Mun. Big objective, big story, big proof.

First, though, we had to test what was possible. Josh came at it as an engineer: what does the agent need to demonstrate before anything ambitious is even a fair test? I came at it the way I come at every enterprise transformation: what does failure cost at each step, and what do we learn before the stakes go up?

Both questions pointed to the same starting point: establish an orbit. Josh built a deliberately over-capable vehicle for a simple low-orbit flight, and we handed the agent the controls.

It got there. Once we confirmed the agent could reach orbit, we got creative, and the Mun was back on the table. Three more missions followed:

  1. An uncrewed orbiter to the Mun. Can it navigate somewhere that matters?
  2. A crewed landing and return. Can it carry consequence?
  3. Rendezvous and docking. Can it coordinate two vehicles with almost no margin?

Creative did not mean reckless. Each mission added one new kind of risk on top of a capability the agent had already demonstrated. An engineer calls that a test campaign. An executive should recognize it as a portfolio of bets, sequenced by consequence. Uncrewed before crewed. Orbit before the Mun.

Most enterprises deploying AI agents right now skip straight to the crewed landing.

The Capability Question Is Settled

The agent flew. All four missions reached their objectives, and Josh’s full write-up is worth your time for the technical detail. What matters for leaders is where things went wrong, because it was never where you would guess.

The first orbit came after a software version mismatch crashed the control link; the agent improvised and flew the circularization burn manually with a one-off script. The Mun orbiter arrived at a 19-degree inclination because its burn script only managed altitude. The first crewed landing was aborted, by Josh, after staging and fuel errors and a manual maneuver the agent attempted while its own automated control was still active. Docking took six attempts. The first five failed on control bugs the agent found and fixed in its own code. The sixth made perfect contact, both ports reporting ready, and nothing latched.

Josh’s diagnosis of the pattern is the most important line in his write-up: “None of that was physics. It was operational.”

The orbital mechanics were never the problem. The failures lived in the seams: two control systems flying the same vehicle at once, improvised recovery burns, a craft generator that quietly omitted the docking port’s module data. That is precisely where enterprise AI fails. Not in the model. In the code, the integrations, and the handoffs wrapped around it.

The docking fix is the part every operating executive should study. The agent could now bring the two craft together. It could not make them latch. Instead of another attempt in orbit, Josh had the agent build two rovers on the ground carrying the same docking ports, and practice latching on the surface. The agent agreed, describing it as a way to isolate the problem cheaply. Only once latching worked on the ground did it go back to orbit and try the connection again.

That ground test only worked because a runway existed. Most enterprises are flying agents in production without one.

“Nobody Approved Any of Them”

Here is the sentence from Josh’s post that every board member should read twice: “The calls it made on its own were often right, and nobody approved any of them.”

Consider what the agent decided on its own initiative. It released roll control mid-flight to stop an oscillation. It added a correction burn on the way to the Mun. It reloaded an earlier save when it ran short of fuel. And when asked only to land a crew on the Mun, it designed the mission to bring them home, “even though only the landing was requested.”

That last one is the decision I keep returning to. It was the right call. Nobody wants a landing without a return. It was also an unrequested expansion of scope, made by a system with no authority to make it.

Josh put it plainly: “On a real mission each of those is a flight director’s decision.”

Translate that into your organization. An agent that tightens a payment term it was asked only to flag. One that widens a customer remedy because the policy seemed too narrow. One that reroutes a shipment, reruns a failed transaction six times, or patches a workflow because the original path looked broken. Each could be the right call. None was authorized.

Being right is not the same as being accountable. An agent with good judgment and no defined authority is not a success story. It is a governance gap that has not been expensive yet.

Your Agents Are Flying on Telemetry. Is It True, and Is It on Time?

The fuel reload deserves a closer look, because it was not really a fuel problem. It was a telemetry problem.

On the way to docking, the agent miscalculated and burned more fuel than it planned. Its own telemetry never caught it. The craft was off track, the agent believed it was on track, and it kept flying until we told it otherwise. Once it knew, it chose the obvious fix inside a game: reload an earlier save and fly the maneuver again with full tanks.

That is a perfectly rational decision in a simulator. It is not available to a business. When an enterprise agent is working from bad data, there is often no one watching closely enough to tell it, and nobody gets to reload. The decisions it made while it was wrong have already gone out to customers, teams, and ledgers.

And the data enterprise agents fly on is usually worse than a fuel gauge.

Truth is only half of it. Telemetry can be accurate and still arrive too late. A burn window closes whether or not the data reached you in time. A lagging feed, a dropped connection, a batch job that runs overnight: the agent acts on yesterday’s picture, or the human who should step in sees the problem after the window has closed.

A financial services client I am working with had both problems. They use AI to make decisions about efficiency and team performance. The data sources feeding it were corrupted, and they were not real time. The AI did exactly what it was built to do, and its decisions made no sense. Not because it reasoned badly. Because it was reasoning about an organization that was not the one in front of it.

Decisions about team performance land on people. A signal built on corrupted data does not just waste a leadership meeting. It puts a team on trial for numbers they never produced.

This is the question I am bringing to the AI Leadership Forum in Zurich on October 22: who has the authority to light the Bat Signal? When an AI flags a team as underperforming, somebody decides whether that signal summons action, and somebody owns the data that lit it. If nobody owns either decision, the signal fires on its own, and the organization responds to it as if it were true.

An agent with bad telemetry and no flight rules is not a pilot. It is a false alarm with authority.

Your Boardroom Is Already Running This Experiment

The simulation compressed into a few days what enterprises are living through right now, at a much higher price.

IBM surveyed 3,221 senior executives across eight European and Middle Eastern countries and published the results on October 14. Eighty percent said an AI-related incident reached their board or C-suite in the past year. Only 40% of those organizations changed their AI governance in response. About 35% already run agentic AI in production, and 75% expect agents to make some decisions autonomously by 2027. Only 37% say their governance is built to scale with that autonomy. When deployment outruns governance, 56% keep going within agreed risk limits while governance catches up. Just 33% pause.

The engineering and business sides of the house are reading the same telemetry and reaching opposite conclusions. In Grant Thornton’s survey of 950 senior executives, 65% of technology leaders would authorize AI agents to make at least moderate-risk decisions. Meanwhile 54% of operations leaders cite regulatory and compliance uncertainty as a top agentic AI concern, against 20% of technology leaders. Same agents. Different risk models. No shared flight rules.

And the abort switch? A vendor survey from WRITER found 35% of executives say they could not immediately pull the plug on a rogue agent. Treat a vendor’s number with appropriate caution. IBM’s data is more telling: only 29% of its respondents expect to need the ability to halt agent activity across the enterprise by 2027. Most leaders are not yet planning for the abort.

Flight Rules Before Launch

Real mission control solved this decades ago, and the solution was never “trust the crew less.” It was deciding authority before launch. Flight controllers work from flight rules: decisions made in advance, in calm conditions, for situations they can anticipate, so that the call in the moment is execution rather than debate.

Agents need flight rules. Here is the structure I would put in front of any leadership team deploying them:

Agent owns. Corrections inside a defined envelope that are reversible and bounded. Releasing roll control to damp an oscillation lives here. So does retrying a failed API call twice, or reformatting a report. The agent acts and logs.

Agent proposes, human decides. Anything that changes scope, spends beyond a set budget, or touches a customer, a contract, or a regulator. Designing a crew-return capability nobody asked for lives here, however good the idea. The agent brings the recommendation and the reasoning. A named human says go or no-go.

Human only. Irreversible actions and the decision to abort. Josh made that decision on the first crewed landing, and that is exactly where the authority belonged.

Two engineering disciplines make those tiers real rather than decorative.

First, wrap a non-deterministic agent in deterministic safety. Josh lists “deterministic safety mechanisms” as essential future work for real hardware, and the enterprise version is the same. Your kill switch, spending caps, and escalation thresholds cannot depend on the agent agreeing to honor them. They have to be enforced by the system around it.

Second, one hand on the stick. The worst failure in the campaign came from manual and automated control acting at the same time. Most “human in the loop” designs in the enterprise are exactly that: a person and an agent both able to act, with no defined handoff. Design the handoff explicitly. Who has control, when it transfers, and how both sides know.

In the defense and aerospace programs I work inside, none of this is novel. Decision authority, configuration control, and traceability are written down before anything flies, because the alternative is measured in hardware and lives. Financial services, energy, and insurance carry their own versions of those consequences, through regulators, safety obligations, and policyholders. The organizations in those sectors that move fastest with agents will not be the ones with the most permissive governance. They will be the ones whose governance was decided before launch, so nobody has to improvise it on the way down.

What to Do Before Your Next Launch

Three moves, all achievable this quarter.

Inventory decisions, not agents. Most AI governance programs start by cataloging tools. Start instead by listing the decisions your agents are already making and the data each one depends on, then sort each into the three tiers. Name an owner for the data, not just the decision. You will find calls in the “agent proposes” tier that are happening with nobody deciding.

Sequence autonomy by consequence. Uncrewed before crewed. Give agents low-consequence, reversible workflows first, and expand authority only after they have demonstrated reliability with full telemetry. The mission order we chose in a simulator is the deployment order you need in production.

Build your runway. Create an environment where failure is cheap: a sandbox with production-shaped data, synthetic customers, and real integrations. Josh’s rovers let the agent practice the one maneuver it kept failing, where a failure cost nothing, instead of burning another attempt in orbit. If your only test environment is production, every defect is found by a customer, an auditor, or your board.

Josh closed his write-up with this: “The capability question is settled enough for me: the agent can fly.”

I agree. Capability is now the easy part. The part that belongs to leaders is the question he asked right after: who makes which decisions? Somebody in your organization should already know they are the one who can decide to abort.

If nobody does, that is your first flight rule.

This post is a collaboration with Josh Kaplan. For the engineering story, read his full write-up, Agentic Spaceflight. For more on why decision rights, not capability, are the real readiness gap, see 43% of Leaders Expect Significant Job Disruption in the Next 18 Months.

Sources

Work With Atlas

If the stakes are high, let's talk.

Atlas Revolutions partners with a small number of Fortune 100 and government leaders at a time. If you're navigating a transformation where getting it wrong isn't an option, start with a conversation.

Start the Conversation