Contents 8
- News: Claude is shaping the workflow itself
- A dynamic structure does not remove the need for task definition
- The leader’s job is not to produce code; it is to manage transitions
- Isolated context and a shared file area are both necessary
- Two boundaries remain unchanged: budget and visibility
- Add this to your task board today
- Related articles
- Related posts
In AgentSpace, a leader agent sets the sprint plan while Claude worker agents take on real software tasks inside it. The central design question in Claude agent orchestration is not how many workers to launch. It is where the work packet handed from the leader to a worker begins and ends.
That distinction looks small, but it determines how a multi-agent system operates. Give a worker a broad outcome and the task definition, context, and checkpoints collapse into one place. Give it a narrow, verifiable packet and the leader’s coordination remains visible. Persistent agent memory and the task board in AgentSpace exist to carry that boundary.
News: Claude is shaping the workflow itself
latent.space covers Anthropic’s dynamic workflows feature, presented at AI Engineer New York 2026. In this approach, a leader agent makes a plan, then writes an orchestration program that launches agents, gathers their results, and manages the flow of information.
In the previous model, the developer defined both the coordinator and the list of subagents. In the new model, Claude decides how to divide the work. In the stock-screening example from the source, the first stage distributes separate securities to agents with isolated context; a later review stage turns the findings into a report.
A dynamic structure does not remove the need for task definition
The most useful part of the news is not the idea of leaving agents alone. It is that the leader can change the agent topology while work is underway. That recognizes that a fixed list of workers will not be the right list for every sprint.
In AgentSpace, a leader agent and Claude worker agents already operate in a sprint structure. The dynamic-workflows approach adds another checkpoint to that structure: the leader does not only distribute tasks at the start. As work progresses, it can determine whether a new research, review, or synthesis stage is required.
For that decision to hold up, every worker task needs a clear output. “Build this feature” is not a task packet. It leaves unclear which files should be examined, which change is expected, what must return to the leader, and what will verify completion.
A good packet is a unit of work a worker can complete in its own context. The leader’s ability to select the next step depends on this as well. When an output is vague, the leader receives not new information but a long piece of text that needs to be interpreted again.
The leader’s job is not to produce code; it is to manage transitions
In the source, the leader agent plans, launches agents, collects results, and manages information flow. I read this as the core job of the leader in AgentSpace. The leader’s job is not to redo every worker output from start to finish. Its job is to determine which output enters the next stage.
That is why a task board should not remain a simple work list. Each card should carry a transition contract:
- What question or change is the worker handling?
- What evidence or delivery does it return to the leader?
- Which next step can the leader choose after receiving that delivery?
The source’s screening example makes this sequence clear. The screening stage produces findings. The review stage evaluates a finding. The reporting stage writes an output that supports a decision. Giving all three stages to the same worker hides the visible part of orchestration.
Persistent memory in AgentSpace does not replace the task board here. Memory carries information that must survive across sprints. The task board carries who must deliver what in the current sprint. Compressing both into the same notes field makes it harder for the leader to distinguish past context from a new work output.
Isolated context and a shared file area are both necessary
In the dynamic-workflows example, screening agents operate in isolated contexts. The source also says that subagents can use a shared filesystem to exchange information. At first, those ideas can appear to conflict. They do not.
Isolated context keeps a worker’s research and implementation area narrow. The shared area holds deliveries that the leader and later stages need to see. This is where the design boundary belongs: a worker’s reasoning process can remain in its own context, while its decision, file change, or verification output must reach a shared work surface.
In AgentSpace, the task board is the coordination layer for that shared surface. Persistent memory is the layer for reusable context. A dynamic workflow makes this distinction more valuable because, when the leader launches new workers during the same sprint, they need the correct task packet and relevant memory record instead of searching through scattered traces of earlier work.
For that reason, carrying the same memory load into every task the leader creates is not a useful assumption. Provide context related to the task. Do not provide every note from the past.
Two boundaries remain unchanged: budget and visibility
According to the source, these workflows cost “much more” than a single-agent approach and are designed to produce more detailed findings. The speakers discuss evaluations and low defaults to prevent hundreds of subagents from being launched for simple work. The developer can also set a session budget; the model does not know its own budget while it runs.
That does not mean the leader in AgentSpace should choose unlimited parallelism. The opposite is true: parallelism should be tied to the value of the work packet. When a worker’s output does not raise the quality of the next decision, launching another worker adds coordination overhead.
Visibility needs the same protection. The graphing capability in the source makes it possible to inspect what the leader sent to a subagent and the transitions in the graph. In a leader-worker setup, a “completed” label on the task board is not enough without that visibility. The leader needs to track which output was produced from which input.
Dynamic workflows expand the leader’s ability to choose an organizational structure. Task packets, budget boundaries, and transition records make that flexibility portable.
Add this to your task board today
Use the following template for every new task between a leader agent and a worker agent:
TASK PACKET
Goal:
[The one task the worker will solve]
Input:
[Relevant task card, file, memory record, or previous delivery]
Worker delivery:
[Change / finding / review note]
Verification:
[The check that proves this delivery is complete]
Leader’s next decision:
[Merge / send to review / open new research / close]
Worker-launch rule:
[Do not launch a new worker unless this work is independent and verifiable]This template is not designed to give workers more work. It keeps clear which information moves at every transition and which decision is expected. That is where dynamic orchestration becomes practical.
I will keep sharing the operating model for teams building leader-worker sprints in AgentSpace with task packets, persistent memory, and a visible task board.
Related articles
- What Is an AI Agent? An 8-Agent Team in a One-Person Company
- Claude Opus 4.8: First Test in an AgentSpace Sprint
Related posts
Read to the end to awaken
Finishing marks the post as read. Saved only in this browser.
Next quests
Get new posts by email
The agent systems I build, the prompts that work, the real numbers. Ready to copy.
