Quick Reference: Domain 1 — Agents and Workflows

The tier depends on who decides the next step. That single line settles most Domain 1 questions.

• 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 decides 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. The benefit is flexibility. The disadvantages are cost, latency, more ways for errors to occur and the work of building guardrails.

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: if the question describes a fixed, auditable, high-volume process, the workflow is the right answer; the extra cost of an agent must bring a benefit that the workflow could not deliver. Changing to a bigger model is the usual wrong option when the real decision is about control flow.

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 way to pass information from the parent agent to the worker (the subagent). Anything agreed in the orchestrator's own conversation (the orchestrator is the parent agent) does not exist for the subagent unless the brief (the delegation prompt) states it. The one exception, as of October 2026, is a Claude Code fork, which inherits the whole conversation. Fork mode lets Claude start a fork on its own. From Claude Code v2.1.302, fork mode is on by default, including in the Agent SDK and -p runs. A deny rule for Agent(fork) in the permission settings stops forks, and CLAUDE_CODE_FORK_SUBAGENT=0 turns fork mode off.

• Isolation is also the benefit: intermediate tool calls and file reads stay inside the worker. Only its final message returns, so the context of the lead (the parent agent) grows by a summary. Anthropic reported results for a system with one lead agent and subagents that work in parallel. On Anthropic's internal research evaluation, this system outperformed a single agent by 90.2%.
• Parallelism helps 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 starting many subagents for a simple query shows that the lead did not match its effort to the task. 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 short references to that work back to the coordinator (the lead agent).
• Other multi-agent designs (as of September 2026): Claude Code agent teams are experimental and off by default (CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1). They work in interactive sessions only. Teammates message 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. It delegates to a list of at most 20 unique agents. These agents 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 is reached. The raw Messages API imposes no loop semantics: no default turn cap, no termination token.

The exam tests the exact names:

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 names that are almost right (max_iterations, budget_limit, turn_cap) are the wrong options.

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 disables nesting, where subagents spawn their own subagents. The concurrency cap, CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS, defaults to 20.

Input modes: single message input (one query() with a prompt string) suits single-request 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 tests 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 edits and model swaps do not raise a cap that is too low.

• Who runs the harness is the deployment question. Self-hosted: your process runs the loop, which can be custom or use the Agent SDK. You get full control and full operational burden. Anthropic-hosted: Claude Managed Agents, a separate product. Anthropic runs the agent harness and sandbox behind a REST API. This gives stateful server-side sessions with minimal operations. As of August 2026 it is in beta (header managed-agents-2026-04-01). The sandbox can be Anthropic-managed or self-hosted for data residency. So who runs the harness and where the sandbox runs 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 stop 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 work that fits the agent pattern.
• Prompts ask for a behaviour. Hooks enforce it. 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) belong in code. Model-behaviour concerns (context, tone, approach) belong in the prompt.

Names verbatim from Building effective agents, American spellings included:

Differences the exam tests: the difference between sectioning and orchestrator-workers depends on when the subtasks become known; the difference between voting and evaluator-optimizer depends on whether anything passes from one attempt to the next; 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; selected state stays available in any future session.
• Handler safeguards: map /memories onto real storage. Reject paths outside it: canonicalise the path, and refuse ../ and URL-encoded traversal. Cap how much a view returns, and page 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 keep selected state available in any future session. The two tools serve different needs for continuity between sessions.
• Context rot: recall degrades as token counts grow. The three documented techniques for long-running tasks: 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 tests which design to choose. Domain 6 covers the details of each technique.

Match the stated need to the main strength of each framework, never API trivia:

A framework gives you a ready-made loop, state handling and orchestration code. In exchange, you add a dependency and an abstraction between you and the model. Plain code is better than a framework for a fixed pipeline. The rule to find the simplest solution possible applies to tooling exactly as to architecture.