The tip described our problem

A tip showed up under the prompt in Claude Code:

You can control how big a workflow is just by prompting.

Then the examples: ask for a small workflow, cap it at five agents, set the default size in /config.

My first reaction was not engineering. It was: seriously? That is the thing I have been fighting for months.

What we were fighting

We build Mikoshi, a tool that lets coding agents take an engineering task from plan to merged change on their own. Plan it, read the repository, write the change, prove it, hand it on.

The model was never the hard part. The hard part is how much work an agent can invent for itself.

Give an agent a task and it starts subtasks. The subtasks start their own. Parallelism grows, context gets spent, checks run twice, and a small change turns into a little factory that produces work for the sake of work.

We have the receipts. Parallel sessions, one per git worktree, filled a disk over three weeks. Test runs across those worktrees left 1.4 million files in a temp folder and a Mac that would not boot. One measurement put our most careful mode at about twelve times the cost of the cheap one, for the same kind of task. Every stream we add costs roughly one more interactive session. None of that came from reading about the AI tooling market. It came from our own runs, our own bills and our own failed nights.

So limits stopped being settings and became architecture. In our list of guarantees, bounded resources and bounded retries are mandatory. A review loop has a round limit, and a limit running out never quietly allows a merge. And every change gets the cheapest path that still produces the proof it needs.

A cap is one line

It is tempting, for a second, to decide you were robbed. You spend months on a system, and the platform you build it on starts explaining the same principle to everyone.

That is a feeling, not evidence.

Capping the number of agents is not an idea only one person could have. The moment agent systems start spending real resources and spawning chains of work, controlling scale becomes an obvious engineering need. Anyone who runs agents long enough arrives there.

What the tip does show is that the problem is not ours alone. That is worth something.

And a cap is the easy part. Here is what one setting covers:

1. prompt
2. up to five agents
3. result

Here is what we found a task actually goes through when nobody is watching:

1. intake
2. admission
3. execution
4. proof
5. merge decision
6. merge
7. closure

A limit says how much work may run. It does not say who admits the task, what counts as proof, who may merge, when a stuck run is dead, or which decisions stay with a person. In Mikoshi the release and the publish stay with a human. Everything else the agents carry themselves, inside those limits.

Two features can look the same from outside and give completely different guarantees inside. That difference is where the actual engineering is.

The uncomfortable question

I build Mikoshi with Claude Code. So the obvious question: could the platform have learned from my decisions?

It helps to keep three things apart, because they are often blurred together.

1. Context sent to the model. Every prompt and every answer go over the network to the model. That is how the tool works. Turning telemetry off does not change it.
2. Telemetry. Usage metrics and error reports. According to the documentation, metrics never include code, prompts or file paths, and each kind can be switched off on its own.
3. Training. On consumer plans, whether conversations can be used to train future models is a separate account setting. It is not the telemetry switch.

One more channel sits outside all three. /feedback, /bug and /share send the conversation history to Anthropic, code included, but only when you run them.

None of that proves anything in either direction. Working through a platform is not evidence that a team there saw my architecture and built a feature from it. A claim like that needs dated artefacts, specific matches, and a reason to tie them to a source.

What I have is a coincidence. Not evidence of borrowing.

Why keep building our own

Because Mikoshi was never about one more setting for the number of agents.

The question is whether an engineering system can work on its own without becoming unmanageable. Whether it knows when to continue, when to stop, when to hand a decision to a person, and how to prove the work is actually done.

If a large platform starts solving one piece of that, it is not necessarily a threat. More likely it confirms the problem is real.

A product of your own only makes sense if you can say how it differs from a pile of similar features. Not by the number of components, not by how complex the architecture is, not by how many agents run at once. By the guarantees it gives, and by which problems it solves without handing the chaos back to a human.

I do not know whether someone at Anthropic saw this before me, at the same time, or entirely on their own. I am not going to pretend I know.

I do know why I started. I needed agents that do real work instead of growing their own activity.

If it turns out everyone else is now solving the same problem, that is not a reason to stop. It is a reason to see how far this can go.