The Inverted Agent: When the User Is the Planner and the Model Is the Step-Executor

Most agent products today implement a simple bargain: the model decides what to do, the user clicks "approve." This is the right shape for low-stakes consumer chat — booking a restaurant, summarizing an inbox, drafting a casual reply. It is catastrophically wrong for legal drafting, financial advisory, medical triage, and incident response, where the user holds the accountability the model never can, and where the cost of the wrong plan dwarfs the cost of any individual step.

The inverted agent flips the polarity. The user composes the plan as a sequence of named, reorderable steps. The model executes each step on demand — with full context, with tool access, with reasoning — but never decides what step comes next. The model can suggest, but suggestions are advisory, not autonomous. This is not a worse autonomous agent; it is a different product, with a strictly worse cost-and-latency profile and a strictly better trust profile, aimed at users who would otherwise decline to adopt the autonomous version at all.

The mistake teams keep making is treating "autonomy" as a default to push toward. It is a UX axis you choose per-surface. Get the polarity wrong and you ship a feature your highest-stakes users will quietly refuse to touch.

The Default UX Got Inverted Without Anyone Noticing

Walk back a decade. A workflow tool meant: the user defines steps, the system executes them deterministically. Airflow. Make. Zapier. The plan was the user's intellectual property; the platform was infrastructure. Failure modes were boring — a step retried, a connector broke — but nobody confused who owned the decision tree.

Then chat happened. Chat is conversational by design, and conversational interfaces make the model the active party — the one that decides, plans, and replies. The user types intent, the model returns an outcome. Plan-and-execute architectures formalized this: the planner module decomposes the goal into ordered steps, the executor realizes them. Both modules live inside the model. The user appears at two places — the prompt at the start, and the approval click at the end. Sometimes a checkpoint in the middle.

This shape is fine for tasks where the user's intent is fully expressed in the prompt and the steps are cheap to redo if wrong. "Find me flights under $400 to Lisbon" can tolerate the model picking the search strategy. "Draft a settlement letter for the Henderson matter" cannot.

The problem isn't autonomy itself. The problem is that the chat-first pattern smuggled in an assumption — the model is the planner — that nobody chose explicitly. Product teams ship chat UIs because the framework defaults to chat, and the chat shape determines the planner location, and the planner location determines who is accountable when the plan is wrong. Three architectural decisions cascade from one UI choice, and most teams only notice the third one when a regulator asks.

When Inversion Is the Right Default

Five conditions make the inverted agent the right product, not the wrong one:

The user has accountability the model doesn't. A lawyer signing a brief, a doctor signing an order, an SRE running a runbook during an incident. Their name is on the outcome. Liability frameworks for AI in regulated domains converge on one principle: the human in the chain remains the responsible party, regardless of how much the system did autonomously. If the user is going to own the plan in court, they should own it in the UI.

The cost of the wrong plan exceeds the cost of any individual step. In legal drafting, the wrong argument structure can lose a case even if every paragraph is well-written. In incident response, the wrong sequence of remediation steps can extend an outage even if every command runs cleanly. The plan is the load-bearing artifact. Moving plan authorship to the model means moving the highest-leverage decision to the least accountable party.

The user knows things the model can't observe. Surrounding case strategy. Patient context not in the chart. Political dynamics on the on-call channel. The user has private information that shapes which step should come next, and that information is never going into a system prompt because it's tacit, evolving, or explicitly out-of-scope for the system.

Reversibility is asymmetric. Some steps cannot be undone — sending the email, filing the motion, executing the trade. The user needs to be the one who decides when to cross those thresholds. Approving each individual call is too granular; the model has already framed the decision by then. The user needs to be the one who introduced the step in the first place.

The user is going to verify the output anyway. If a senior associate reads every paragraph the model produces, the supposed efficiency win of autonomous planning is illusory. The associate's review is the actual rate-limiter. Inverting the agent means the associate writes the plan once and the model fills in the steps — fewer roundtrips, not more.

When these conditions hold, the autonomous agent UX is solving the wrong problem. The user isn't trying to delegate the plan; they're trying to delegate the typing.

The Interaction Primitives the Inversion Requires

A chat box doesn't work for this. The interaction primitives are different in kind, not in degree.

Named, reorderable steps. The plan is a first-class artifact: a list of steps with stable identifiers, descriptions, and dependencies. The user can drag step 3 above step 2, rename step 4, split step 5 into two, or delete step 6 entirely. The plan is editable structure, not a chat message. Once the user has invested authorship in this structure, they own it in a way they never own a model's auto-generated outline.

On-demand execution per step. When the user clicks "execute step 3," the model runs that step — with the prior steps' outputs visible as context, with the relevant tools available, with full reasoning if needed. The model does not auto-advance. It does not preemptively run step 4. It does not propose to "just go ahead and finish the rest." The execution boundary is the step boundary, and the step boundary is set by the user.

Mid-plan checkpoints with judgment, not just approval. A checkpoint isn't a "Y/N continue" — it's a moment where the user examines the step's output, possibly edits it, possibly re-runs it with a different framing, and only then decides what comes next. The output of step N is the input to the user's next planning decision, not just an intermediate variable in a larger pipeline.

Model-suggests-next-step as advisory. The model can, after each step, propose what step N+1 might be. This is useful — the model has the local context fresh and may notice something the user wouldn't. But the suggestion is advisory: it appears as a draft step the user can accept, edit, or ignore. It does not self-insert into the plan. The default action is "do nothing"; the user has to actively pull the suggestion in.

Plan versioning and replay. Because the plan is the spec, plan changes need to be tracked. The user replans, re-runs, compares outputs across plan versions. "Did I get a different result because the model changed or because I changed the plan?" is a question the system has to answer.

These aren't decorations on a chat UI. They redefine the interaction model. A team that tries to retrofit them onto chat will produce something that feels like both a worse chat and a worse planner.

The Eval Framework Has to Change

Autonomous agents are evaluated against goal completion: did the system, given a user goal, achieve it? Trajectory quality is a secondary concern — interesting for debugging, not load-bearing for the product claim.

Inverted agents demand a different scoring axis: plan conformance. Did the model, given the user's plan, execute each step faithfully? Did step 3's output reflect what step 3 asked for, in the form the plan specified, using the tools the user authorized? Goal completion is now the user's problem, because the user owns the plan. The model's job is to be a reliable, predictable executor of well-specified steps.

This sounds like a smaller eval surface, and in some ways it is. But it also exposes failure modes the autonomous-agent eval suite never measured:

• Step drift — the model interprets step 3 as a slightly different step, because its training pulls toward the autonomous shape. Goal-completion evals would mark this fine if the result is good. Plan-conformance evals mark it as a regression.
• Implicit re-planning — the model, mid-step, decides the user's plan was suboptimal and reorders or fuses steps. Catastrophic in a domain where the plan is the spec.
• Premature optimization — the model skips a step because it judges the step unnecessary. This is exactly the autonomous behavior the inversion was supposed to prevent.
• Context bleed — step 3 implicitly executes a tool that step 2 was supposed to authorize. Audit trails diverge from the user's intended trajectory.

The eval suite for an inverted agent is closer to a workflow engine's conformance test than to an LLM's task benchmark. It scores fidelity to specification, not creativity in pursuit of a goal. Teams who reuse their existing agent eval rigs will not catch the failure modes that matter most.

The Cost-and-Latency Trade Is Real

The inverted agent is strictly more expensive and strictly slower than its autonomous sibling. The user is in the loop on every step, which means human latency dominates the wall-clock time. Each step is its own model call, with its own context assembly, its own tool round-trip. Aggressive caching helps but doesn't recover the autonomy gap. Token cost goes up because each step is independently grounded with full context rather than chained inside one long autonomous trajectory.

Pretending otherwise, or trying to optimize the latency back to chat-level, will pull the design back toward autonomy step by step. Resist that. The trade is the product. A user willing to spend 30 minutes composing a 12-step plan and reviewing each output is not the same user who wanted a 90-second answer in chat — and trying to serve both with the same surface produces a UI that fails both.

The cost frame teams should adopt: the inverted agent is competing with the user doing the work manually with no AI at all. The relevant baseline is "associate types every paragraph themselves," not "agent does it in 30 seconds." Against that baseline, even a slow, expensive, deeply-controlled assistant is dramatic leverage. The mistake is benchmarking against autonomous agents, where the inverted version always loses, and concluding the product is bad — when it's actually a different product for a different user.

The Org Failure Mode

The most common way teams ship the wrong UX: a product manager surveys "what do users want from AI" in a high-stakes domain, hears "I want it to help me draft," interprets that as "build a chat assistant," and ships a chat UI. The high-stakes users politely thank the team and don't adopt. The team concludes the model isn't good enough yet and waits for the next capability bump.

The next capability bump never fixes it. The problem isn't model quality; it's UX polarity. The user wanted the model to type for them while they planned. The team gave them a model that planned for them while they approved.

The corrective question, at design time: who owns the trajectory in this product? If the answer is "the user, by professional necessity," and the UI doesn't have first-class plan structure that the user authors, the UI is wrong. No prompt engineering, no eval improvement, no model upgrade will fix it. The bones of the product are wrong, and high-stakes users have professional pattern-matching that detects this within minutes of trying it.

Teams who ship the inverted agent on purpose, in the right domain, find the inverse — adoption among users who had explicitly refused the autonomous version. The constraint that felt like a step backward (slower, more clicks, more user effort) turns out to be the feature that makes the product trustable.

Autonomy Is a UX Axis, Not a Default

The framing that helps: agent autonomy is a slider, not a destination. Different surfaces sit at different points on the slider, and the right point is determined by accountability, reversibility, and the user's information advantage. A single product may need multiple surfaces — an autonomous chat for low-stakes lookups, an inverted planner for the high-stakes work — with explicit handoffs between them.

What teams should stop doing: treating "more autonomous" as the trajectory of progress. Autonomy is one product position among several, and for a meaningful slice of users in regulated, accountable, high-stakes domains, the right product is at the low-autonomy end of the slider — not because the model is weak, but because the user's accountability profile demands it.

The next generation of agent products will look less like chat and more like a structured editor where the user composes a plan, the model fills in each step on demand, and the audit trail shows exactly which decisions belonged to whom. This is not a regression. It is the UX shape that the highest-leverage, highest-stakes use cases were always going to require — it just took the industry a few years of building the autonomous version first to notice.