Quick Reference: Domain 1 — Agents and Workflows

Whoever decides the next step names the tier. That single line settles most Domain 1 items.

• Augmented LLM: one model call enhanced with retrieval, tools and memory. The basic building block; most problems need nothing more.
• Workflow: LLM calls and tools orchestrated through predefined code paths. Code owns the control flow, so runs are predictable, testable and cheaper.
• Agent: the model directs its own process and tool usage, deciding each step from environment feedback. Flexibility is the product. The price is cost, latency, a wider error surface and a guardrail burden.

Choosing: find the simplest solution possible. Steps known in advance and repeating → workflow. Step count unknown, each decision dependent on what the last one found → agent. On the exam: a stem naming a fixed, auditable, high-volume process keys the workflow; an agent's extra spend must buy something the workflow could not deliver. The bigger-model swap is the standing distractor for what is actually a control-flow decision.

The most-tested fact in the domain: subagents do not share memory. A subagent's context window starts fresh; the delegation prompt is the only channel from parent to worker. Anything agreed in the orchestrator's own conversation does not exist for the subagent unless the brief states it. The one exception, as of September 2026, is a Claude Code fork, which inherits the whole conversation. Fork mode is on by default in interactive sessions and off in the Agent SDK and -p runs unless you turn it on.

• Isolation is also the payoff: intermediate tool calls and file reads stay inside the worker. Only its final message returns, so the lead's context grows by a summary. Anthropic reported a lead-plus-parallel-subagents system outperforming a single agent by 90.2% on its internal research evaluation.
• Parallelism pays only on independent subtasks. Dependent stages must run in sequence; splitting them across parallel workers recreates the coordination problem at higher cost.
• Trace multi-agent failures to the orchestrator first: overlapping scopes produce duplicates, unassigned topics produce gaps, and spawning breadth on a trivial query is an effort-scaling failure in the lead. The fix is a better brief: objective, output format, tool guidance, task boundaries, every time.
• Results need not all pass through the lead. The multi-agent research post recommends that subagents store bulky work in external systems and pass lightweight references back to the coordinator.
• Other multi-agent shapes (as of September 2026): Claude Code agent teams are experimental and off by default (CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1), interactive only, with teammates messaging each other directly at a higher token cost. Named subagents can also message each other. Dynamic workflows put the plan in a script that decides what runs next, for dozens to hundreds of agents per run. A Managed Agents coordinator delegates one level only to a roster of at most 20 unique agents, which share the session's sandbox and filesystem.

The bare loop: send the prompt with tools; if the response requests tools, execute them, append the results, call again; stop when the model responds without tool calls or a cap trips. The raw Messages API imposes no loop semantics: no default turn cap, no termination token.

Exact names are keyed facts:

Both default to no limit. The docs call a budget cap a good default for production agents. The budget is cumulative: subagent requests count toward total_cost_usd, spawns fail at the cap, and the run ends with the budget subtype. Invented near-misses (max_iterations, budget_limit, turn_cap) are the distractors.

Subagent depth and concurrency (as of September 2026, environment variables through the env option): CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH defaults to three layers below the main agent, and 1 turns nesting off. The concurrency cap, CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS, defaults to 20.

Input modes: single message input (one query() with a prompt string) suits one-shot or stateless work. Streaming input (an async generator of messages, sent through ClaudeSDKClient in Python) is the preferred mode: a long-lived session with image attachments, queued messages and interruption.

Every run ends with a ResultMessage. The subtypes the exam leans on are success, error_max_turns, error_max_budget_usd and error_during_execution (the docs list a fifth, error_max_structured_output_retries, as of August 2026). Every subtype carries total_cost_usd, num_turns and session_id. The result text exists only on success, so code checks the subtype before reading it.

A limit result is not a model failure. The guardrail fired as configured. Documented recovery: resume the session (pass the captured session_id to the resume option) with a raised limit, tighten the brief, or split the work. Prompt nudges and model swaps do not change the arithmetic of an under-scoped cap.

• Who runs the harness is the deployment question. Self-hosted: your process runs the loop (custom or via the Agent SDK), full control, full operational burden. Anthropic-hosted: Claude Managed Agents, a separate product where Anthropic runs the agent harness and sandbox behind a REST API, giving stateful server-side sessions with minimal operations. As of August 2026 it is in beta (header managed-agents-2026-04-01), and the sandbox can be Anthropic-managed or self-hosted for data residency, so who runs the harness and where the sandbox lives are separate questions.
• Managed Agents details (as of September 2026): a self-hosted sandbox keeps tool execution, files and network egress with you, but tool inputs and outputs still flow to Anthropic's control plane. Agents are versioned: a plain agent ID runs the latest version, and passing a version object pins the session. Scheduled deployments run an agent on a cron schedule.
• Self-hosted SDK sessions write transcripts to local disk by default. A SessionStore adapter mirrors them to your own storage so another host can resume the session. Containers that spin down between visits need one.
• Write the loop yourself (Messages API plus client SDK) when the application needs full control of the cycle; the packaged SDK harness is the default for agent-shaped work.
• Prompts request, hooks enforce. A system-prompt rule is an instruction the model may not follow under adversarial input. A PreToolUse hook fires before a tool executes, can deny it with a reason returned to the model, and runs deterministically in the application process regardless of what the model was persuaded to attempt. Harness concerns (caps, budgets, retries, validation, persistence) live in code. Model-behaviour concerns (context, tone, approach) live in the prompt.

Names verbatim from Building effective agents, American spellings included:

Differentiators the exam drills: sectioning vs orchestrator-workers turns on when the subtasks become known; voting vs evaluator-optimizer turns on whether anything flows between attempts; a gate is a one-way pass/fail checkpoint, never a feedback loop.

An agent remembers nothing between sessions unless the design adds a mechanism.

• Memory tool: generally available on the Messages API as tool type memory_20250818. Claude gets create/read/update/delete operations over files in a /memories directory that your application executes client-side; curated state carries into any future session.
• Handler safeguards: map /memories onto real storage, reject paths outside it (canonicalise, refuse ../ and URL-encoded traversal), and cap how much a view returns, paging with view_range. In the multisession pattern, mark a feature complete only after end-to-end verification.
• Session resume restores one specific conversation. Memory files carry curated state into any future session. Different tools for different continuity needs.
• Context rot: recall degrades as token counts grow. The three documented long-horizon techniques: compaction (summarise and reinitialise the window; the Agent SDK does this automatically), structured note-taking (persist state outside the window, read back on demand), and sub-agent architectures (explore in clean windows, return condensed summaries). On the Messages API, as of September 2026, compaction is split into on-demand and token-threshold forms, and the docs recommend on-demand wherever it is available. Domain 1 keys the design move; Domain 6 owns the technique detail.

Match the stated need to what each framework leads with, never API trivia:

A framework buys pre-built loop, state and orchestration machinery at the price of a dependency and an abstraction between you and the model. Plain code beats a framework for a fixed pipeline. The simplest-thing rule applies to tooling exactly as to architecture.