Inside Claude Code Dynamic Workflows: The Architecture

For most of the last two years, an "AI workflow" meant a graph you drew yourself: a fixed sequence of nodes wired together in code, where every branch and every tool call was decided in advance by a human. Dynamic workflows in Claude Code invert that. Instead of you predetermining the path, Claude decides at runtime which steps to take, which tools to call, which skills to load, and when it is done — all inside a single agent loop. Understanding the architecture behind that shift is the difference between trusting the system in production and being surprised by it.

This article walks through the internals end to end: how a prompt becomes a turn, how context is assembled and re-assembled each step, how skills and MCP tools are discovered, how hooks and subagents extend the loop, and where the control boundaries actually live. The goal is a mental model accurate enough that you can debug a misbehaving run by reasoning about the components rather than guessing.

What a dynamic workflow actually is

A dynamic workflow is an agent loop in which the control flow — the order of operations and the choice of operations — is generated by the model on each turn rather than hard-coded by the developer. Claude Code is the harness that runs that loop: it owns the conversation transcript, the tool registry, the context window, and the lifecycle events that fire around each step. You give it a goal and a set of capabilities; it produces the plan by acting.

The key architectural property is that the plan is never materialized as a static object. There is no DAG sitting in memory waiting to be executed. The "workflow" exists only as the running sequence of model decisions, each conditioned on everything that has happened so far. That makes the system enormously flexible — it can recover from an unexpected error by trying a different approach — but it also means correctness comes from the quality of context and tool design, not from a diagram you can inspect ahead of time.

The agent loop, step by step

At the center sits a deceptively simple loop. The harness sends the assembled context to Claude. Claude responds with either a final answer or one or more tool calls. The harness executes those tools, captures their results, appends everything to the transcript, and sends the updated context back. The loop repeats until Claude stops requesting tools or a stop condition fires.

flowchart TD
  A["User goal + project context"] --> B["Harness assembles context window"]
  B --> C["Claude reasons over transcript"]
  C --> D{"Tool calls requested?"}
  D -->|No| E["Final answer returned"]
  D -->|Yes| F["Hooks fire: PreToolUse"]
  F --> G["Harness executes tools / subagents"]
  G --> H["Results appended to transcript"]
  H --> B

What makes this powerful is that each pass through the loop is a fresh decision. Claude is not following a script; it is re-evaluating the whole situation. If a tool returns an error, the error text lands in the transcript and the next reasoning step sees it, so the model can adapt — retry, try a different tool, or ask the user. The loop is the workflow.

How context gets assembled each turn

The most underappreciated component is the context assembler. Before every model call, the harness builds the window from layered sources: the system prompt and project instructions (the persistent CLAUDE.md and configuration), the running transcript of prior turns and tool results, any skill content that has been activated, and tool and MCP schemas the model is allowed to call. With a context window now reaching a million tokens, the assembler can keep far more live state than older agents could — but it still has to budget that space carefully.

Assembly is not static concatenation. The harness compacts older turns when the window fills, summarizing or trimming tool output that is no longer load-bearing while preserving the instructions and the recent decisions. This is why a long-running dynamic workflow can keep going for hundreds of steps without the early context evicting the goal: the assembler protects the high-priority layers and sacrifices the disposable ones.

Skills and tools: discovery vs. invocation

Two extension mechanisms feed the loop, and conflating them is a common source of confusion. Tools — including MCP servers — are things Claude can do: their schemas are presented to the model, and Claude emits a structured call that the harness executes. Skills are things Claude can read: folders of instructions, scripts, and resources that get loaded into context when relevant, teaching Claude how to use a tool or perform a procedure.

The discovery flow matters architecturally. Skills are progressively disclosed: the harness keeps only short skill descriptions in context until a skill becomes relevant to the task, at which point its full body is loaded. This keeps the window lean. MCP tool schemas work similarly — the harness advertises the available tools, and only the ones Claude actually calls produce round trips. Both mechanisms exist to let the model pull capability in on demand instead of front-loading everything.

Hooks and subagents: extending the loop safely

Hooks are deterministic interception points the harness exposes around lifecycle events — before a tool runs, after it returns, when the agent stops. They run your code, not the model's, which makes them the right place to enforce policy: block a dangerous command, inject an environment variable, validate output, or log every action for audit. Because hooks are code, they are predictable in a way model decisions are not, and a robust dynamic workflow uses them as guardrails around the non-deterministic core.

Subagents extend the loop in the other direction. When a task is large or benefits from isolation, Claude can spawn a subagent with its own fresh context window to handle a slice of work and report back a condensed result. This is how parallelism and context hygiene happen at once — the orchestrator stays focused while subagents do bounded research or edits. The tradeoff is cost: multi-agent runs typically consume several times more tokens than a single agent, so the architecture rewards spawning subagents deliberately rather than reflexively.

Where the control boundaries live

Putting it together, the system has a clear separation of concerns. The model owns what to do next. The harness owns context assembly, execution, and lifecycle. Your hooks own policy and safety. Your tools and skills own capability and procedure. Debugging a dynamic workflow means knowing which boundary failed: a wrong decision points to context or prompt design, a failed action points to tool schemas or error handling, and an unsafe action points to missing hooks.

The architecture is forgiving precisely because it loops. A single bad turn is rarely fatal — the next assembly includes the consequence, and the model adjusts. Designing for that recoverability, rather than fighting it, is what separates teams that ship dynamic workflows from teams that keep them in demos.

Reading the run as a trace

Because the entire workflow is a sequence of turns recorded in the transcript, the transcript is also your primary observability surface. Every model decision, every tool call with its inputs, and every result is laid out in order, which means debugging is closer to reading a stack trace than to staring at a black box. When a run goes wrong, you scroll to the turn where the path diverged and you can usually see exactly which input misled the model or which tool returned something confusing.

This is why instrumenting hooks to emit structured logs pays off architecturally rather than just operationally. The harness already produces the trace; hooks let you persist it, redact secrets from it, and feed it into your own monitoring. Over many runs those traces become the empirical record of how your workflow actually behaves under real inputs — the foundation for evals, regression checks, and the steady tightening of context and tools that turns a promising prototype into something dependable.

Frequently asked questions

How is a dynamic workflow different from a traditional pipeline?

A traditional pipeline has its control flow fixed in code before it runs. A dynamic workflow generates control flow at runtime from the model's decisions, so the same harness can handle very different tasks without you rewiring a graph. You trade predictability for adaptability and recover predictability through hooks and good context design.

Does the harness ever modify the context without my involvement?

Yes. The context assembler compacts and trims older transcript content when the window fills, preserving instructions and recent decisions. This is automatic and is what lets long runs continue, but it means you should put durable instructions in persistent layers like CLAUDE.md rather than relying on a message from fifty turns ago to survive.

When should I reach for subagents instead of one loop?

Use subagents when a subtask is large enough that its intermediate context would crowd out the main goal, or when independent slices can run in parallel. Because each subagent has its own window and multi-agent runs cost several times more tokens, reserve them for genuine isolation or parallelism rather than every small step.

Bringing agentic AI to your phone lines

CallSphere takes the same loop-and-tools architecture and points it at voice and chat — agents that reason turn by turn, call tools mid-conversation, and handle every call and message around the clock. See the architecture working live at callsphere.ai.

Source & attribution: This is an independent, original explainer inspired by Anthropic's coverage on the Claude blog. Claude, Claude Code, Claude Cowork, Claude Opus, and the Model Context Protocol are products and trademarks of Anthropic. CallSphere is not affiliated with or endorsed by Anthropic.