The symptom. Projects in my orchestration platform were occasionally created with names like {. A single brace. It had been happening for months and I had never traced it, because it was cosmetic and everything else worked.

The cause. The system captures agent output from a rendered view with a fixed window. Any response longer than that window lost its beginning, permanently, not into a buffer I could recover from.

The agent emits a title at the top of its response. The title scrolls out of the window. The parser finds nothing, falls through to a legacy path, and names the project after whatever fragment survived.

The same truncation was quietly handing worker agents plans with their instructions missing, which is considerably worse than a bad project name.

The first wrong fix. I identified a buffer setting, increased it, confirmed the setting had been applied, and declared victory.

The setting was inert. It could never have affected this class of view at all.

I had verified that the option was accepted, not that the mechanism changed. Those feel like the same act and they are not. The number that actually mattered was printed in the same line of output I was reading, and I read past it because I had already found what I was looking for.

The real fix was making the capture window twelve times larger. Response heads survive, titles parse, workers get whole plans.

Two things I took from it.

Confirming your config was accepted proves nothing. The question is never "did the system take my setting." It is "did the quantity I care about change." Those require different evidence, and only one of them is easy to check.

Your fixes interact, and the interaction is invisible from either side. Separately, I had spent weeks making agents terser. That work was correct. It is also what exposed this bug, because shorter responses stopped pushing stale markers out of the capture window, changing which failure mode was reachable.

Load-bearing assumptions do not announce themselves, and the ones that break are usually inherited from a version of the system that no longer exists.

https://openred.space/blog/agents-have-amnesia.html

On the orchestration side, when an agent classifies a failure incorrectly the cost is a wasted retry. The system notices, tries something else, and nobody outside ever knows. The judgment is internal: load-bearing for the machinery, invisible to the world.

On the publishing side there is no such cushion. The agent writes a paragraph, the paragraph goes into a brief, the brief goes to readers. A wrong classification announces itself. A plausible, well-written, subtly wrong sentence does not.

Same infrastructure. Completely different failure mode. Three things follow from that.

The role distribution inverts. On the orchestration platform, almost every agent call is a decision. On the publishing platform, five of the eight resident roles exist to write or edit reader-facing prose, and only one is doing internal decision-making. The infrastructure is identical and the shape of what runs on it is upside down.

Three agents read the same document and must not produce the same answer. When a release lands it goes to three roles pointed at the identical source with different jobs. A private analyst writing for one reader in the vocabulary of a specific framework. A public writer whose output goes in front of readers who do not work in finance. A structured scorer returning a classification, because parts of the system need a value rather than an argument.

That is not three prompts on one model. Each is a role with a standing definition that stays resident and accumulates context across everything it has read this week. Try it as a single call and you get mush: one paragraph hedging between two audiences and useful to neither. The reason to have an agent behind the endpoint rather than a model is precisely that it can hold a role.

Failure needs a taxonomy, not a retry. Unreachable is transient, so retry it. But an output you cannot parse, or one that arrived partial, must not be retried automatically. In a publishing context a partial answer is worse than no answer, because a missing analysis is visibly missing while a truncated one looks complete. It sits there reading like a finished thought with its conclusion silently amputated.

The whole thing turned out to be less like engineering than I expected and much more like editing.

The full piece is on my site, including the month of small embarrassments that taught me the audience lesson:

https://openred.space/blog/calling-an-agent-for-sentences.html

That is a human interface to a thing that does not require a human.

I spent the better part of a year building an orchestration platform that runs autonomous data operations on a schedule. 136 scheduled jobs, 2,242 runs, nearly 28,000 agent turns. The platform is what I set out to build. The piece I am actually proud of is smaller, sits underneath it, and took the longest to see clearly.

It exposes a coding agent as a webservice. That is all it does.

Why an agent rather than a model.

The metered API gives you a model behind an endpoint. Clean, callable, easy to integrate. What it does not give you is the agent: the thing that reads files, runs commands, iterates on a problem, holds a role definition across a long conversation, and knows when it is finished. That whole apparatus lives in the CLI product.

I could have rebuilt it. Reimplemented the tool-use loop, the file handling, the iteration, the skills scaffolding, and paid per token for the privilege of running my own worse version. Or I could take the agent that already exists and make it answer HTTP.

Two things fell out of that, both larger than expected.

The economics inverted. Flat-rate subscription rather than per-token billing means every architectural decision I would otherwise make to conserve tokens simply stops being a decision. I let agents be thorough. I add a verification pass because it improves the output, not because I have priced it.

And I inherited a product roadmap. Because the service wraps the real CLI rather than reimplementing it, every improvement shipped to that product arrives on my platform for free. Better reasoning, new tool handling, context management. I integrate none of it. The agents get better between Tuesdays.

The reusable idea is smaller than the platform.

The moment you put an HTTP endpoint in front of a capable agent, it stops being a tool you use and becomes a component you build with. Something a scheduler can invoke at four in the morning with nobody watching.

The invention was not the platform. It was noticing that the agent did not need a human in front of it.

The full piece covers the ten named roles, the pipelines they compose into, and the classifier that changed how I write code:

https://openred.space/blog/claude-code-as-a-webservice.html

Turned out two thirds of everything it was producing came from the one component that does no work at all. It was the manager, and it was reviewing paperwork nobody had asked for.

Same lesson as any org chart, honestly: managers should plan and sign off, not stand in the middle of people who can talk to each other.

https://openred.space/blog/multi-agent-middle-manager-problem.html