Multipath: Structured Reasoning for Agents That Outgrew a Single Prompt

Structured reasoning for AI agents becomes essential the moment a single agent has to do the work of several. Most agentic systems are one agent doing everything at once, behind one giant system prompt: a personality, a knowledge base, and hundreds of rules that have nothing to do with each other. That design works in a demo. It breaks in production, and it breaks most where the stakes are highest.

Multipath is built for exactly that situation. It came out of hands-on work with enterprises operating under heavy, often conflicting rulebooks, and it lets a single small model reliably run an operation that used to require a frontier one, at a fraction of the cost.

Why Multipath is necessary

Large corporates accumulate rules for years. Different teams, different eras, contradictions baked in. Most systems flatten all of that before they can function. Multipath is designed to work with it as it stands.

Consider a customer-facing agent: a support bot, a voice agent, an assistant. These agents don't just talk. They carry out the work behind the conversation, checking an order, applying a refund, escalating a case, reading the right disclosure. When one agent has to hold the whole operation, its system prompt balloons. One customer's ran past 10,000 tokens, roughly 7,500 words, about 25 pages.

Multipath makes a prompt that large work reliably on a small model, and switching it on takes one string. That is what moves a support agent from something that usually stays on-script to something you can actually put in front of a customer.

Why one giant prompt is the wrong shape

SERV Reasoning works as a drop-in for the OpenAI and Anthropic SDKs. You send your system prompt as always, and it turns that prompt into a compact, machine-native instruction graph, then runs your model through the graph instead of the raw prose.

For a single task, that conversion is straightforward. A task has a shape: steps, branches, an end. It fits into one clean graph a small model can follow.

A customer-service agent has no such shape. It is one agent expected to answer, decide, and act all at once, carrying rules that have nothing to do with one another. Force all of that into one graph and you are drawing a map of a place where the towns have no roads between them.

And some of it should never be a graph at all. You do not diagram a personality. Tone of voice is not logic, it is language, and it works best when it stays language.

So one graph is the wrong shape. Not because any single job is too hard to structure, but because all of them together do not fit one structure.

How Multipath works

Instead of forcing everything into one graph, Multipath turns the logic-heavy parts into many small instruction graphs, inline, each covering one self-contained concern. The refund rules become one graph. The escalation policy becomes another. The parts that are voice rather than logic stay as prose. The result is a single system prompt, machine-native where it should be, human where it should be, and your model runs against that.

You opt in the way you opt into everything in SERV. Where you would write gpt-5.4-nano, you write gpt-5.4-nano-multipath.

To be clear about what this is not: Multipath is not a panel of models. It is not three models answering in parallel while a fourth votes on a winner, the slow, expensive architecture the industry keeps rediscovering. It is one prompt, decomposed into the structure it always had, run by one model. The paths live inside the prompt, not across a fleet of them.

One model. One prompt. Many small graphs, each small enough to get right.

The cheaper path

Give a model its reasoning as structure, and a small model performs like a much larger one. In published benchmarks, bounded reasoning let small models match or beat models one and two tiers above them, with more than an order of magnitude better performance per dollar, on up to half the tokens.

The same held on a live customer-service workload. On a benchmark built from a client's real use cases, scoring decision accuracy, knowledge, and tone, a cheap open-weight model running Multipath matched a mid-tier frontier model at roughly one-fifth to one-seventh of the cost.

The frontier-quality answer was never one tier up. It was one string away.

Where "mostly" is not a product

For a demo, an agent that is mostly on-script is impressive. For a business, it is a liability.

In banking, a support agent that quotes the wrong policy or skips a required disclosure is not a clumsy reply. It is a compliance event, in writing, at scale. In healthcare, a member-services agent that gets a benefit detail wrong, or delivers it in the wrong tone to someone who is frightened, is not a support ticket. It is harm. In neither case is a human reading each message before it goes out. The rules have to hold on their own.

Two very different conversations, one requirement: every turn follows every rule, in the right voice. "Mostly compliant, mostly on-brand" cannot be a product.

Reasoning in the right shape

Reasoning is a process, not next-token generation. v2 fits more of that process to how agents are actually built today: Shadow Agents for verification, Verification Hints for steering, and Multipath for the agents that outgrew a single structure.

Customer service is just one example. Wherever a single agent is asked to do the work of several, every job packed into one prompt, Multipath is what holds it together.

The biggest agents don't need a bigger model. They need their reasoning in the right shape, and that is exactly what Multipath gives them.

Multipath ships with SERV v2.