The last mile is a person

There is a particular shape of failure that shows up once an agent stops answering questions and starts running a process.

The agent is fine. It reads the contract, extracts the terms, drafts the filing, picks the vendor, writes the email. Then it reaches a step where the next action is not a token: someone has to be commissioned by a state, or standing in front of a building, or personally on the hook for a judgment. The agent cannot do it, cannot fake it, and — this is the part that hurts — cannot buy it either, because the businesses that sell exactly that thing have no surface software can order from.

So the run stops. Not with an error. With a Slack message.

Long-horizon does not mean long context

There is a lot of work going into making agents run longer: better planning, better memory, better recovery from partial failure, sub-agents, checkpointing. All of it is real and all of it helps. None of it touches this failure, because this failure is not about the agent's capacity to keep going. It is about the world refusing to accept a token as the input to a step.

It is worth being precise about which steps those are, because "human in the loop" gets used for two very different things that need very different answers.

The first is supervision: a person approving what the agent already did. That is a permissions problem. It is solved with an approval queue, a spend policy, a threshold. The agent did the work; a human blessed it.

The second is fulfillment: a person doing a step the agent structurally cannot. A notarization needs a commission. A roof inspection needs a body on a ladder. A signed engineering opinion needs someone whose license is on the line if it is wrong. A call that has to come from a person has to come from a person. No amount of capability moves these; they are gated by law, by physics, or by the fact that accountability itself is what is being purchased.

Every serious agent framework ships something for the first case — an interrupt, a human_in_the_loop node, an approval callback. Almost none of them ship anything for the second, and they are not wrong to: an SDK cannot ship a notary. But the consequence is that the escape hatch built for supervision is the one everybody reaches for when what they hit is fulfillment. The interrupt fires, the graph suspends, and a human on the team becomes the fulfillment department — finding someone, briefing them, chasing them, checking the work, paying them out of band, and typing the result back in.

That is not a loop. That is a person doing a job the system was supposed to do, with an agent watching.

Why this gets worse as agents get better

The intuition is that better agents need fewer humans. For fulfillment steps it runs the other way.

A workflow that used to run once a quarter because it was expensive to run at all now runs weekly, because the ninety percent that was expensive got cheap. The ten percent that requires a person did not get cheaper — but it now happens ten times as often. Automating most of a process has a long history of increasing demand for the part that stays human, precisely because the whole process suddenly happens far more.

Which means the manual fulfillment step does not stay a footnote. It scales with your agent's success, linearly, in headcount. The better the agent gets, the more of somebody's week it consumes.

What a fulfillment step actually needs

If you are going to let software buy a real-world service, it needs more than a marketplace with a search box. Walk through what has to be true for an agent to complete the purchase without a human sitting behind it:

It has to find the right seller without reading prose. A directory of company descriptions is useless to software. The agent needs structured listings it can filter: what the service is, which jurisdictions it covers, what it costs, how long it takes. "We pride ourselves on fast turnaround" is not a turnaround.

It has to know what to send. Every service has required inputs, and an agent cannot infer them from a homepage. The listing has to declare its input schema, so the agent either has the inputs or knows immediately that it does not — before it spends money finding out.

It has to know the price before it commits. Not a range, not "contact us". An itemized fee preview, before the charge, that a spend policy can evaluate against a ceiling.

It has to trust the counterparty without meeting them. A human buyer interviews a vendor, or asks a colleague. An agent has neither move available. So verification has to be a property of the record: the business's legal entity checked, its license checked against the issuing registry, and the check re-run when the license renews. Not a self-declared badge.

It has to be able to answer a question mid-order. Real work generates questions — the ID has a middle initial the deed does not, the gate was locked, there are two units with that number. If the only channel is email, the agent is out of the loop and the order stalls anyway. Questions have to be typed and answerable programmatically, with a defined escalation to a human owner for the ones the agent genuinely cannot answer.

It has to get back something it can consume. A PDF attached to an email is a step backwards. The deliverable needs a declared schema, checked on arrival, so the agent's next node can just read it.

And when it goes wrong, the remedy has to be mechanical. An SLA that is only a sentence on a webpage is not an SLA. If the published turnaround is missed, the refund should happen because a clock ran out — not because someone escalated.

None of that list is exotic. It is the ordinary anatomy of a commercial transaction, written down in a form software can execute. The reason it does not exist yet is not that it is hard; it is that nobody needed it while every buyer was a human who could improvise the missing parts.

The supply side is the actual hard part

Here is what makes this a platform problem and not a protocol problem.

The businesses that can do these steps already exist. They are licensed, insured, reviewed, and busy. They are not looking for a new schema to learn, and they are, reasonably, suspicious of anything that smells like a gig platform — bidding, proposals, a race to be first, a cut off the top, and a rating system that punishes them for a customer's bad day.

So the offer to them has to be a genuinely better deal than the demand channels they already have, on the terms they care about:

• They set the price, and they receive the price. If the platform's fee comes out of the seller's revenue, the platform is taxing scarce supply — which is the wrong side of a two-sided market to tax when supply is the constraint.
• Scope is fixed before work starts. The listing is the contract.
• The clock is fair. If they are blocked waiting on the buyer, the SLA clock pauses, because the system knows whose move it is.
• They can decline. An order is a request, not an assignment.
• The reputation runs both ways. A buyer who sends incomplete inputs and answers questions in three days should be visible as such before the next order is accepted.

That last one is stranger than it looks when the buyer is software. An agent carrying a public track record — input completeness, response latency, behaviour when something goes wrong — is a real accountability primitive, and it is one that only exists if somebody builds it deliberately.

Where we think this lands

Our bet is narrow and, we think, checkable: the bottleneck on long-horizon agent work is not reasoning, it is that real-world steps have no purchase surface — and the fix is verified human supply sitting behind machine-readable commerce rails.

That is what ROJI is. Businesses publish machine-readable service catalogs. Agents search them over MCP, read the input schema, accept an itemized fee preview, and order. Payment is captured at order as a destination charge that settles straight to the business — ROJI never holds the funds, and the platform fee is charged to the buyer on top of the list price, so the business keeps 100% of what it published. Questions are typed. Deliverables are schema-checked. A missed SLA refunds automatically.

We are early, and we would rather say so than imply a directory that is fuller than it is. But the thing we are confident about is the shape of the problem. Agents will keep getting better at the ninety percent. The ten percent will keep being a person. Whether that person is somebody on your team, improvising, or a business you bought from in one call — that part is a design decision, and it is one somebody has to build the rails for.

If your agents are hitting that wall, the developer docs are the fastest way to see the shape of it, and MCP is where the ordering surface lives. If you run a business whose services agents should be able to order, start here.