Agentic systems

What your agent harness decides before you do

Every claim about a vendor default below was checked against that vendor's documentation on 3 Oct 2026, and carries the version where the docs give one. Defaults move between releases, so the date matters as much as the value. The rows marked as built come from the Claude Code sessions that build this platform; the Codex and Agent SDK rows come from documentation alone.

The defaults at a glance

One row per decision. The sections after the table give the reasoning and the evidence.

Model: the worker you did not choose

In Claude Code, a subagent resolves its model in a fixed order: the model passed for that one invocation, then the model field in the subagent's definition, then the CLAUDE_CODE_SUBAGENT_MODEL environment variable, and last the main conversation's model, per the subagent documentation (read 3 Oct 2026). The last step is the default. Anything you leave blank is priced at whatever your coordinating session costs. The environment variable only became lower in that order at v2.1.251; before that it overrode both of the others, so the same setup behaves differently on an older install.

Two details change the arithmetic. The built-in Explore agent is not simply inherited: when the main session runs a Fable-tier model on a subscription, a Console account or an LLM gateway set through ANTHROPIC_BASE_URL, Explore runs on the Opus-class model the opus alias points to, while Plan inherits. And dynamic workflows use the same order, so a workflow stage with no model named runs on the session's model, per the workflows documentation.

Override: set model on every dispatch and in every subagent file, and treat a blank as a bug. If you want cheap exploration, define your own subagent named Explore with model: haiku; the documentation says a user-level agent with that name replaces the built-in one. This is where the one default with a price tag sits: Anthropic's pricing page lists Fable 5.1 at $10 input and $50 output per million tokens against $4 and $20 for Opus 5.5, the current Opus tier. We hit exactly this, and it is written up in the as-built section below.

Context: which of your rules arrive

Two built-in research subagents, Explore and Plan, start without your CLAUDE.md files and without the git status snapshot; the documentation gives speed and low cost as the reason. Every other subagent, built-in or your own, loads both unless its definition sets omitClaudeMd (subagent docs, what loads at startup). The failure mode is quiet: a research subagent breaks a repo convention that the main session obeys, and nothing in the transcript says why. Our Claude Code workflow lists this as a pitfall because it surprises people who delegate investigation.

Override: any rule that must hold during investigation goes into the delegation prompt, not only into CLAUDE.md. The documentation says the same, and its example is a rule such as ignoring a vendored directory.

A second context default catches teams that standardised on AGENTS.md for several tools. From v2.1.277, Claude Code reads AGENTS.md as project instructions only when no CLAUDE.md, .claude/CLAUDE.md or CLAUDE.local.md exists in your working directory or above it. Your user-level ~/.claude/CLAUDE.md, the managed file and .claude/rules/ do not count, but a personal CLAUDE.local.md does. So adding one local file to keep private notes can make a repo's AGENTS.md stop loading, per the memory documentation. Override: keep a CLAUDE.md that imports AGENTS.md, or set the project-instructions option to claude-md-and-agents-md, which reads both. We cover the file-layout side in the context-engineering workflow.

Codex has the mirror-image problem. It builds one instruction chain from AGENTS.md files from the repository root down to your directory, joined in order, and it stops adding files once the combined size reaches project_doc_max_bytes, 32 KiB by default (Codex AGENTS.md guide, read 3 Oct 2026). A large root file can therefore crowd out the nested file that holds the rule you care about. Override: raise the limit, or split instructions across directories.

Trust: the mode you started in

A permission mode decides what the agent may do without asking. In Claude Code the built-in starting mode is now auto, in which a classifier reviews actions instead of you. The permission-modes documentation gives the rule: from v2.1.283, interactive terminal and VS Code sessions start in auto; on earlier versions only on Pro, Max and Team plans with feature flags fetched. Three consequences are easy to miss. A project-level settings.json cannot set auto as the default, so a repo cannot opt your team in. A session run with claude -p or through the Agent SDK follows a different row of the same table and usually starts in default. And a subagent running under auto takes the session's mode and ignores the permissionMode in its own file, per the subagent docs.

Override: choose the mode with the --permission-mode flag or a user-level defaultMode, and decide it per repository by what a wrong action costs there. Our recommendation on the Claude Code workflow page remains acceptEdits, chosen deliberately, because the mode that ships as default is a vendor decision about the average user, not about your production repo.

Codex defaults the other way. Its documented default for the CLI and IDE extension is a sandbox that confines writes to the workspace and keeps network access off, with approval requested before anything leaves it (Codex approvals and security). Here the override is a loosening, set through network_access under [sandbox_workspace_write]. Loosen it for the task that needs a package install, not for the whole machine.

Reach: how far it fans out without being asked

Out of the box, a Claude Code subagent may itself delegate to further subagents, to a depth of three levels beneath your main session; the Agent tool is withheld only once that depth is reached. Dynamic workflows run up to 16 agents at once by default. The size notice is advisory: a workflow that schedules more than 25 agents, or projects more than 1.5 million tokens, shows a "Large workflow" notice and keeps going. Ultracode hands the choice of when to run a workflow to Claude and removes that notice, so the usual early warning is gone (workflows docs, cost; nesting). On a subscription the cost of fan-out shows up as quota: wide runs use up your session or weekly allowance faster.

Override: cap depth with CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH, pick a size guideline for dynamic workflows, or deny the Agent tool where delegation is not wanted. The question to ask is whether the task fans out for a reason you can name. Three subagents rarely need a dynamic workflow, and our Claude Code workflow page says so in its pitfalls.

Stop: who ends the loop

The Agent SDK, like claude -p, sets no turn or spend cap unless you do, and an unattended SDK service is where that matters most. Per the agent-loop documentation, maxTurns and maxBudgetUsd both default to no limit, and the same page says setting a budget is "a good default for production agents". Two neighbouring defaults matter for the same reason. Without a systemPrompt the SDK sends a minimal prompt that omits the safety instructions of the Claude Code preset, unlike claude -p, which uses the full one (system-prompt docs). And leaving settingSources unset loads user, project and local settings, CLAUDE.md files and skills from the machine the process runs on (Claude Code features in the SDK), which is convenient on a laptop and a surprise in a shared service.

Override: set both caps and pick the system prompt on purpose. For a service that runs more than one tenant, an empty settingSources is necessary but not sufficient: the documentation also calls for CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 and a separate filesystem per tenant, and managed policy settings still load whatever settingSources says.

Harness, runtime and SDK are three different decisions

A harness is the code around a model that turns it into an agent: the loop, tool dispatch, context assembly, permission checks and stop rules. You always have one; the question is whether you wrote it. A runtime is where that process lives and what keeps it alive: sandbox, session lifecycle, identity, scaling. An SDK is how you get a harness as a library instead of as a product.

The layers can be bundled, which is why the terms blur. Anthropic's Agent SDK overview lists a hosted option that runs the agent loop for you in a managed sandbox, and AWS documents AgentCore harness versus AgentCore Runtime as exactly this split: Runtime hosts code whose loop you wrote, while the managed harness supplies the loop as configuration and runs inside Runtime. Treat bundling as a purchase of someone else's defaults. When you pick the SDK you inherit different defaults from an interactive Claude Code session; when you pick a hosted harness you inherit a vendor's again, and you can override only what it exposes. For the hosting question on its own, see where to run Claude agents and Amazon Bedrock AgentCore; for the library, the Claude Agent SDK.

As built: a subagent that ran on the wrong model, and a loop with two numbers

By 15 Aug 2026 our coordinating Claude Code session ran on the most expensive model tier. Our written dispatch guidance still told people to let judgment work inherit the session's model, on the assumption that model was Opus. That advice had been right while the session ran Opus and was wrong the moment it did not. Every subagent dispatch that omitted a model was therefore running on the top tier at about twice the per-token price of Opus 5, and nothing in any run said so. The fix was a rule rather than a setting: the model is mandatory on every dispatch, the word "inherit" is banned from the guidance, and fork-style subagents are banned outright because a fork always runs the parent's model. The documentation agrees with that last point: a fork shares the main session's system prompt, tools, model and history (subagent docs, forks). It is recorded in our decision log as an owner directive: mechanically a two-way door (an edit to three files), but settled by the owner.

What this taught us is narrower than "watch your costs". A harness default is a function of configuration you changed somewhere else. The inherit-the-model default was harmless until the session setting moved. Re-read the defaults of any harness whenever a global setting changes, not only when the harness upgrades.

The other side of the ledger is the harness we wrote ourselves. The coach is a hand-built loop, and its stop rules are two constants at src/lib/coach.ts:30-31: MAX_TURNS = 6 and MAX_TOOL_CALLS = 8. The loop condition is while (turns < MAX_TURNS), and when the tool-call budget is exhausted it emits a visible annotation and ends with a distinct tool_budget stop reason instead of continuing. Owning the harness means every default is a line you can read. It also means every default is yours to maintain, which is why the Claude Code rows above stay as configuration rather than as code we carry. The pattern is documented on bounded agentic loop.

When not to override a default

• When you cannot name the cost. A default is usually somebody's judgment about the average user. Override it because you can say what it costs you in money, leaked rules or blast radius, not because explicit feels safer.
• When the override pins an assumption that will expire. The starting permission mode in Claude Code changed scope at v2.1.283: before it, auto was the start mode only on some plans; from it, on every interactive terminal and VS Code session. An explicit setting survives that; a comment saying "we rely on the default" does not. Write the version or date next to every override.
• When the override loosens a boundary. Tightening a default rarely hurts. Enabling network in a sandbox, or raising a step cap, widens what a wrong turn can reach. Scope those to a task, not a machine.

Frequently asked questions

Which default should I override first?

The model on delegated work and the stop limits on anything running unattended. Those are the two defaults that cost money without announcing it. The context and trust defaults are next, because their failures show up as quality problems, which are harder to trace.

Is an agent harness the same as an agent runtime?

No. The harness decides what the agent does and may do while it works; the runtime decides where the process lives and how long it survives. Some products bundle both, which is why the words get mixed.

Does Claude Code read AGENTS.md?

Yes, from v2.1.277, but only when no CLAUDE.md or CLAUDE.local.md exists in your working directory or above it, unless you change the project-instructions setting or import AGENTS.md from a CLAUDE.md.

Do subagents see my CLAUDE.md?

Most do. The built-in Explore and Plan subagents are the exception, so a rule they must follow goes into the delegation prompt.

Does the Claude Agent SDK behave like Claude Code?

Close, not identical. It runs the same kind of loop, but its default system prompt differs from claude -p and its start permission mode differs from an interactive session, so set them explicitly rather than assuming parity.