The plan was the answer

Anthropic's documentation for its new workflow runs works through an example. You ask a contract-review agent which of 300 contracts contain a change-of-control clause. The agent writes a program, and the server starts it. The program has two phases, "Read the contracts" and "Reconcile the findings", and it spawns agents in parallel to do the reading. Seven minutes later, by the example's timestamps, the run ends with the result {"type": "completed"}, and the agent answers: "41 of the 300 contracts have one."

Then the documentation adds a tip. If you want to see the program that produced that number, wait until the session is idle and send the agent a message: "Print the workflow that you started the run with, word for word, in one code block. Do not start another run."

That is how you retrieve the code. You ask its author to recite it.

Dynamic workflows went into beta on Claude Managed Agents on 9 October. They are among the more interesting things a model platform has shipped this autumn, and I think they will be useful. They also settle a question architects have been putting off: when an agent orchestrates other agents, is the orchestration a design or a plan? Anthropic has answered "plan". The orchestration is generated per request, run by the server, and kept out of view, the way a relational database keeps its query plans. My argument is that the analogy is exact in mechanism and wrong in the one place that matters. A database may choose its plan in private because every valid plan returns the same rows. A workflow's plan decides which rows there are.

What the program decides

The documentation is careful about what the program does, and that is where the case is made. "An agent's result goes to the program, not to the agent that the session runs. The program determines which agents run next, and it writes their prompts." It can define agents of its own, called inline agents, each with "the system prompt the workflow wrote". It can fan out to as many as 64 agents at once and up to 1,000 over a run's life. It can loop: the documented example has "a draft revised until a review passes or a set number of rounds is used up." It decides what happens when one of its agents fails. The server usually retries a failed agent once. After that, "the program can handle the failure or let it end the run."

Read that list as an architect and it is a list of design decisions. How the work is partitioned. Which prompt each worker gets, which is to say what each one is told to look for. Whether a second reader checks the first. What "reviewed" means and how many rounds a draft gets before it is accepted anyway. Whether a contract that could not be read counts as "no clause" or as "not covered". In a hand-built pipeline, every one of those is a line someone wrote and someone reviewed. In a dynamic workflow, the model writes each one in the turn it decides to start the run.

And it does not wait. "There's no approval step before a run starts: the agent starts a run in the same turn that it writes the workflow." The documentation offers a workaround, a system-prompt line asking the agent to describe its phases and wait for your go-ahead. It then states the limit plainly: "There's no approval step before a run starts, so nothing enforces this." Permission policies still govern the tools a run's agents call, but they do not govern starting the run.

Why a database gets away with it

The query-plan comparison is worth taking seriously, because it is the strongest case for this design and the reason it will feel natural to many engineers. Nobody reviews the plan a database chooses for a join. The optimiser picks one per execution from statistics the author never sees, and most of the time this is a good thing: the system knows more about the data than the person who wrote the query.

But that arrangement rests on a contract. The query defines the result, and the plan defines only how expensive it is to obtain. A bad plan is slow. It is not wrong. That is why a plan can be private, chosen afresh each time, and absent from every design review in the building: nothing it decides is something anyone needs to agree to.

A workflow has no such contract. Two programs written for the same request about the same 300 contracts can return different counts and both end completed. One sends every contract to a second reviewer and the other reviews only the hits. One loops until a reviewer agent is satisfied and the other gives up after two rounds. One records an unreadable file as uncovered and the other quietly drops it. The documentation says outright that the run's status will not tell you which you got: completed means "the workflow finished running. The result doesn't say whether the work passed. A run can end completed even though work on its threads failed, or a thread couldn't be created."

So the user asked a question, and the program decided what an answer to it would consist of. That is not optimisation. It is specification, done at run time by the component least visible to the person who owns the result.

What you can see instead

The platform gives you a great deal to watch. Every run emits workflow_run.created with a name, a description and the phases the workflow declares. Phase start and end events follow. Each agent works in a thread you can list, read and stream. You can cap spend with a session budget, and runs pause when it is reached.

Look at what that telemetry is, though. The run's name, its description and its phase names are, in the documentation's words, "text the model wrote". They are the program's account of itself. The order of phases is not guaranteed by the API, and you are told to "handle more than one open phase, a phase that isn't in phases, and a listed phase that never starts, even in a run that completes." No event says which phase a thread belongs to. "No endpoint lists runs." And under the heading on visibility: "You don't see the workflow's code," and "you also don't see the tool calls the agent makes to start and manage runs, or the result each thread returns to the workflow."

That last clause is the one I would underline. The intermediate results are the evidence for the final answer. A reviewer who wants to know why the count was 41 needs to see what each reader returned and what the program did with it. What they get instead is the transcript of each thread and the author's word-for-word recollection of the code, asked for after the fact, with no way offered to check the recitation against what actually ran.

The case for not looking

The strongest objection is that I am asking for the wrong control. Nobody reviews the plan a human analyst forms in their head before reading 300 contracts either. We review their output, sample their work and hold them to account for the result. If the workflow's answer is checkable, check the answer. Requiring the orchestration to be a reviewed artefact would turn every request into a change ticket and throw away the reason to use an agent in the first place: that it can decompose a task nobody anticipated.

I agree with most of this, and the documentation agrees with some of it. It recommends steering the program through the system prompt. One example tells the agent to have "a second agent review every contract, not only the ones where the first agent found something." Another: "If an agent fails to read a contract, list that contract as not covered." These are good instructions. They are also coverage rules and quality gates, written as prose, and handed to a component that is free to interpret them. The design review has not disappeared. It has moved into the system prompt, where it is a request rather than a contract, and where its only evidence of compliance is the program you are not shown.

The analyst comparison also breaks on scale and on repetition. An analyst reading 300 contracts is one plan, carried out once, by someone you can question. The same agent definition serving a thousand sessions writes a thousand programs, each with its own coverage rule and stopping condition, none of them returned to you to diff. Sampling outputs tells you whether one answer was right. It cannot tell you whether the system has a consistent definition of done.

Where the design goes now

None of this argues against the feature, only for knowing what you have handed over. Dynamic workflows are on by default for an agent with the new multiagent_20261001 type, as are inline agents, which means the default configuration lets the model write both the orchestration and the system prompts of the agents it orchestrates. Teams that want the orchestration to be a design rather than a plan have two real levers. The first is to turn inline agents off and list the agents a workflow may use, so the workers' instructions at least come from versioned definitions. The second is to put the decisions that define the answer, such as coverage, review and failure handling, into the prompt as rules, and then build an independent check that the result honours them. That means counting the threads, reading what each returned, and not trusting completed to mean done.

The documentation already asks callers to assume the worst about one thing: "make the tools your agents call safe to call twice," because a run can create more than one thread for the same piece of work. That is the right instinct, applied to side effects. It should be applied to meaning as well.

A query plan earned its privacy by being unable to change the answer. Orchestration has always been able to change the answer, which is why we drew it, reviewed it and argued about it. What changed on 9 October is not that orchestration became cheap to write. It is that the most consequential part of a multi-agent system now exists, by default, only for the duration of a run, and the only copy of it you can ask for is the author's memory.

This piece argues from one party's record, Anthropic's documentation and release notes, read in this session. Other platforms' approaches to model-written orchestration were not examined, and nothing here is a claim about them.