Controlled agentic engineering workflows

Teams using Claude Code for incident triage or code-quality sweeps should treat nested sub-agents as a configured workflow with a budget, an allowlist, and a depth rule. Claude Code v2.1.172 allows sub-agents to spawn sub-agents up to five levels deep, with each frame carrying its own prompt, model choice, and 200K-token context. That is useful for noisy jobs such as log search, where the parent session only needs a short verdict.

A practical setup is a project-level .claude/agents/<name>.md chain for one debugging path: an Opus triage agent, Sonnet repro agents, and Haiku leaf agents for grep, test generation, or log summarization. Each agent definition should use Agent() to name the only child agents it may spawn. Add a per-session spend cap before using the chain on production incidents. The article’s reported failures are large enough to justify this control: about 7x token overhead per branch per level, one user reaching 887,000 tokens per minute, and a reported $47,000 invoice after 23 sub-agents ran for three days.

The cheap test is one real incident replay. Measure tokens, wall time, number of spawned agents, and whether the parent session receives enough evidence to make a decision without raw log dumps.

Teams asking coding agents to move beyond small edits need a project contract that the agent can read before it writes code. The concrete artifact can be an AGENTS.md file or a small set of markdown files that state architecture boundaries, validation commands, coding rules, and release expectations. Pair that with a tiered gate the agent can run on its own: linting, type checks, unit tests, security scans, integration tests, UI tests, and rollout checks where the system supports them.

The operational pressure is shared validation capacity. The software-factory writeup says concurrent agent work stalls when requests share one staging environment, one branch, or one deploy slot. A useful first build is an agent-run verification script that can create or reset its own test environment, run the required checks, and attach the trace to the pull request. Human review then focuses on failures, risky diffs, and product judgment. Reviewer comments, incidents, and metrics should be fed back into the contract so repeated mistakes become explicit instructions.

Start with one service and one common request type. The pilot is successful if an agent can take a ticket, produce a pull request, run the agreed checks without a developer babysitting the environment, and leave enough evidence for a reviewer to approve or reject quickly.

Rails teams that accept AI-generated backend changes should add an invariant review to pull requests that touch money, reservations, quotas, roles, or inventory. The reviewer should require one sentence naming the data rule being protected, then check whether the database enforces it with the smallest suitable mechanism: a unique index, CHECK, SERIALIZABLE, a locked parent row, an advisory lock, or ordered locking.

This catches a common failure mode in generated Rails code. lock, lock!, and with_lock look simple, but their behavior depends on transaction scope, isolation level, adapter behavior, and query shape. A row lock can fix a single-row lost update. It cannot protect a rule over multiple rows, missing rows, or a predicate such as “no more than 100 reservations per event.” The article also notes that Seat.lock.find(id) without a surrounding transaction releases the lock immediately.

A lightweight adoption step is a pull request checklist and two concurrency tests for each risky path: one test for simultaneous writes to the same row, and one test for the broader invariant. If the second test fails, the fix belongs in the database rule or transaction design, not in another application-level guard.