Claude AI Agent: Claude Code, Sub-Agents and Controlled Delegation

You run a technical, product or IT team, and an agent built on Claude is about to work on a real code base: reading files, modifying them, running commands. This page is for those who have to set what this Claude AI agent is allowed to do, how to split it into sub-agents and how to recognize that it has finished.

It lets you decide the permissions policy that holds for every run, the output contract that makes each run reviewable, and the indicators that tell you whether the team is saving time.

What sets a Claude agent apart: long context and delegation

An assistant hands back text; an agent acts on an environment, observes the result and starts again. As soon as the system writes into files and runs commands, you are no longer deciding the quality of an answer but a scope of action, graded according to the four permission levels of an AI agent. On Claude agents, two properties govern that scope: the context held in one go, and delegation to sub-agents.

If the trade-off between families of tools is not settled at your company, the switching criteria are gathered on AI agent platforms. Here the tool is assumed to be chosen.

Long context is a resource to arbitrate, not a selling point

A large context window does not make an agent better: it gives you room to manoeuvre, to be spent according to a trade-off that comes up on the first slightly broad task.

That choice is made before the first run, not when results start to degrade. Two symptoms signal a task that is too broad: the agent asks again for information it has already been given, or contradicts a decision made earlier.

A long run changes what you have to watch

The second property comes down to duration: a Claude agent can carry a long task through without the hand being taken back from it. The durations that circulate cannot be compared outside the model and protocol measured: remember the property, not the ceiling. It is a supervision constraint: nobody watches the agent while it works, you reread a trace after the fact.

That shift in control calls for three markers.

• A budget, without which nothing stops an agent going round in circles.
• A usable log, without which you will not know what happened during the hours you were not there.
• An explicit stop criterion, without which the agent will decide for itself that it has finished.

Claude Code: an agent that acts on the project, not in a window

The difference between a chat and a development agent lies in the interface, not the model. In a conversation window, you receive code, run it and come back to report the error: you are the loop. With Claude Code, the agent operates from the terminal, on the project: it modifies files, runs commands and tests, reads the errors and starts again.

The tool is already present in teams: developers using Claude or Claude Code are estimated at between 41 and 68% (Faros AI, 2026), an order of magnitude to set alongside our set of Claude statistics. An agent confined to a window can break nothing; a Claude Code agent can.

The plan, execution, observation, correction loop

A reliable development agent follows an explicit iterative loop, and that loop is what you frame, not the code it writes. Impose a standard output at each step, otherwise you get a result with no idea how it was obtained.

• Plan: steps, files affected, assumptions, stop criteria.
• Execution: list of actions (creations, modifications), commands run.
• Observation: test results, useful logs, errors encountered.
• Correction: fixes applied, justification, fresh test pass.

The step most often neglected is the first. A plan handed over before any modification gives you a free stopping point: you correct the instruction before the agent touches the repository, the only moment in the cycle when an error costs nothing.

What the loop really produces on a repository

This loop holds up on tasks whose deliverable can be checked mechanically. Three of them account for most of the use.

• Refactoring or migrating means preserving a behaviour: ask for a proof strategy, tests before and after, a readable diff, incremental steps.
• Writing tests is the best lever for securing an autonomous agent: the success criterion is verifiable without human review, and the agent fixes until green.
• Documenting obeys a rule of its own, because nothing in it fails visibly: a false text reads as well as a correct one.

To avoid purely plausible documentation, force the agent to cite only what it has actually seen or run: file paths, function signatures, command outputs. Impose a fixed format too, in six sections.

• Prerequisites and installation.
• Common commands.
• Troubleshooting for frequent problems.
• Reproducible examples.
• What the module does.
• What it does not do, the section that prevents the most downstream usage errors.

Sub-agents: splitting by deliverable, and paying for the split

Delegating to specialized sub-agents becomes relevant when a task genuinely parallelizes: front end, back end, tests, review. The trigger is the presence of independent pieces, each judged on its own deliverable, not the size of the job.

The second trigger is context: a task that saturates the window gets split even when it is sequential. Beyond three or four sub-agents, you are scoping a coordination, whose patterns belong to AI agent orchestration.

Naming each sub-agent after its deliverable

Structure your sub-agents by deliverable rather than by vague intent. A sub-agent “that improves quality” hands back nothing verifiable and consumes budget endlessly. Three splits work almost every time.

• Tests sub-agent: adds or updates the test suite, then runs the test command.
• Migration sub-agent: applies a plan file by file and supplies a diff.
• Review sub-agent: lists risks, antipatterns and security impacts.

If you cannot say what the sub-agent has to hand back, it is not ready: write its deliverable before its prompt, and give it an explicit file scope. A “review” sub-agent that modifies code has crossed its boundary.

What passes between two sub-agents, and what the split costs

The weak point of a delegation lies in the handover from one sub-agent to the next. Never let raw context pass through: impose a short, standardized summary, always the same.

• What has been done.
• What is still open.
• The decisions taken and their one-line justification.
• The files touched.

That fixed format lets you reconstruct the sequence without reopening every run. The split has a price: each sub-agent consumes its own budget, because it restarts from an empty context, to be primed again with the instructions, the repository conventions and the state of progress.

That trade-off is measured in context window, tied to a dated model: 200,000 tokens for Claude Opus 4.5 (llm-stats.com, 2026). As long as the task fits comfortably inside it, a single agent costs less; the moment it overflows, the priming overhead pays for reasoning quality at the end of the job.

The output contract: schemas, evidence and stop criteria

To make an agent reliable, think “contract”: a context, constraints and an objective as input, a stable schema as output. A useful agent produces auditable artefacts (diffs, logs, test results, decision lists), and review is done on those, never on a prose summary.

Five mandatory fields, and a prompt that steers a process

The output contract for a refactoring task fits in five fields, and all of them are requested.

• files_changed: list of paths and type of action (creation, modification, deletion).
• diff_summary: a summary in 5 points maximum.
• commands_run: commands and results.
• risks: points to review manually.
• stop_reason: finished, to be reviewed, or blocked.

The last field makes a run sortable without being read: you sort fifty runs in a few minutes.

All of this assumes an instruction written accordingly: the prompt has to steer a process, not an answer. Four elements are mandatory on every task.

• An output format: tagged structure, sections, checklist.
• Expected evidence: diff, test command and its result, files modified.
• A stop criterion: tests green, minimum coverage, or escalation.
• A budget: number of iterations, maximum time, maximum cost.

Sources of truth and debugging: escalate rather than invent

A generative model remains probabilistic: without sources of truth, it will compensate with the plausible. So impose an explicit hierarchy, from the most reliable to the least.

• The repository’s code and tests, as operational truth.
• Versioned internal documentation: architecture decisions, technical notes, getting-started files.
• Tickets and merge requests, as a history of decisions.
• Failing that, human escalation instead of invention.

The same rule governs debugging, which fails as soon as the agent fixes before having reproduced. Impose the sequence of reproduction, hypotheses, minimal fix, then a test that fails before and passes after, detailed on the AI agent in VS Code. Do not ask for “correctness”, ask for “provability”.

Permissions, budgets and loops: what stops the agent drifting

A Claude Code agent handles files, runs commands and acts on version control. The question is not “can it do this?” but “within what scope?”. The answer is written once for every run, with the evidence expected, because an authorization with no trace is not controlled.

This grid applies to a repository the first three of the pillar’s four permission levels: read-only, controlled writing with human validation, supervised execution. Each cell is discussed once only with the technical team, and the grid holds from the first agent to the tenth.

Escalation and budgets: stopping the correction loop spinning

The human in the loop is an accelerator of reliability, not a brake: the agent does the heavy lifting, the human validates the critical points. The validation trigger is written as three rules.

• Full autonomy on reversible tasks: formatting, documentation, tests.
• Mandatory validation on security, authentication, payment and dependencies.
• Escalation if the tests fail after N iterations or in case of functional ambiguity.

The risk specific to agents that iterate is going round in circles: fixing one test while breaking another. Prevention comes through non-negotiable budgets.

• An iteration limit, three correction cycles at most, for instance.
• A scope limit: authorized directories and modules.
• A cost and duration limit, settled before launch.
• A mandatory final check: tests, plus a summary of the changes.

Secrets, isolated environment and clean failures

An agent that runs commands sees what your environment sees, and no command is safe by nature: running the tests, the lint or the build means executing code that comes from the repository (installation scripts, plugins, hooks) with the rights of the session. They are allowed by default because they are reversible, not because they are harmless. Four points are checked before the first run.

• Secrets outside the workspace: restricted environment variables, a vault.
• An isolated test environment, for routine commands as for the others.
• Log masking: tokens, API keys, customer data.
• Protected production branches, with a mandatory merge request.

Finally, an agent that acts has to know how to fail cleanly, with no irreversible partial action or dangerous repetition. Four mechanisms cover most cases.

Measuring an agent on a repository: logs, reproducibility, indicators

If your agent fails, you must be able to answer three questions: what did it do, why, and with what data? Replaying a run requires five elements to have been logged.

• The system prompt, the user prompt and the parameters: model, limits.
• The list of files consulted and modified.
• The commands executed and their outputs, with secrets masked.
• The results of tests, lint and build.
• The run identifier, the timestamp, the duration and the estimated cost.

Then comes measurement, where many teams pick the wrong unit: the quality of the code rather than the cost of reviewing it. On representative tasks and a constant protocol, six indicators hold together.

• The size of the diffs and the number of files modified.
• The test pass rate before and after.
• The number of iterations needed to stabilize.
• The human review time, in minutes, against agent time.
• The stabilization time, from the first failure to green.
• The rate of regressions detected after merge.

The fourth decides, provided it is read correctly: what counts is the sum of agent time and review time, compared with the time the same work takes by hand. Ten minutes of agent and forty of review make fifty minutes: set against several hours of manual work, the operation remains profitable. The alarm signal appears when that total approaches the manual benchmark, and that comparison decides the extension to other teams.

The sixth measures the real cost: a regression detected after merge cancels out several successful runs. As for reference scores, they are only to be cited tied to the model and protocol that produced them, and say nothing about your repository. Your acceptance criterion is written in green tests on your code base.

Continue reading

Depending on where your project is stuck, five articles take this one further.

• Your task is about third-party sites and interfaces, not a repository: a remote browser and taking back control are the subject of the ChatGPT AI agent.
• You want the method before the tool, or your agent goes beyond the scope of code: the full approach is set out in the guide to create an AI agent.
• You are stuck on the level of autonomy itself: thresholds, delegation tiers and what is never delegated are covered on autonomous AI agents.
• Your subject is becoming the contribution chain rather than local execution: branches, reviews and merging belong to the GitHub AI agent.
• Your constraint is where the processing takes place more than the tooling: open models are the subject of the Mistral AI agent.

If the agent to be scoped works on your data and business rules rather than your code, that is the framework of a personalized AI for your company.

FAQ on AI agents with Claude

What is a Claude agent?

A Claude agent is a system that uses the Claude models to plan and carry out tasks with a degree of autonomy, through tools: files, commands, integrations. It differs from an assistant because it acts on an environment, observes the result and starts again until a stop criterion you have set.

How does Claude compare with ChatGPT?

Both offer conversational models and a technical layer to call them; the gap plays out on the agentic ecosystem. On the Claude side, repository-oriented tools with Claude Code, a large context and sub-agents; on the ChatGPT side, an agent mode geared to the browser. The right criterion is what your agent has to touch.

How do you create an agent with Claude?

Follow a sequence in this order: define the objective and the indicators, then the authorized tools, impose a verifiable output schema, add the guardrails, and test on a pilot scope. The most frequent mistake is swapping the first two steps.

Is Claude Code essential for building a development-oriented agent?

No, but it is a decisive accelerator if your agent has to act directly on a repository. In a chat, you are the execution loop; a Claude Code agent operates across the whole project, launches the tests and iterates on its own. If your task touches no files, the benefit disappears.

How do you structure sub-agents to avoid losing context and making errors?

Split by deliverable, not by abstract role: a sub-agent must be judgeable on what it hands back. Between them, impose a short summary in a constant format (done, still to do, decisions, files touched). Keep splitting for parallelizable tasks, because each sub-agent restarts from an empty context and consumes its budget.

What guardrails should be in place before authorizing file writes or command execution?

Apply a minimal permissions policy: writing on a dedicated branch, routine commands in an isolated environment, secrets outside the workspace, a mandatory merge request on protected branches. Add budgets for iterations, duration and cost, and final evidence: green tests and the list of files modified.

How do you assess an agent’s reliability in real conditions?

Measure on representative tasks, with a constant protocol: tests, regressions after merge, iterations consumed, agent time and review time. The indicator that decides a wider rollout is the sum of agent time and review time, compared with the time the same work takes by hand; as long as it stays clearly lower, use can extend.

How do you reduce hallucinations and impose verifiable answers?

Do not ask for “correctness”, ask for “provability”: file paths, commands executed, test outputs, and for any claim beyond the repository, an explicit reference or an escalation. Give the agent its sources of truth as well, code and tests first.