Cycle step 5 · /sdd exec

Agent Execution — orchestrate without saturating

Agent execution is the step between the OPEN Gate (SQS ≥ 4/5) and Validation. It is the moment when the Product Engineer orchestrates the AI agent with an optimized context — enough context to succeed, never enough to saturate.

The prerequisites — abort if a single one fails

/sdd exec systematically checks its prerequisites before any launch. If one of them fails, the agent is not launched and the corrective command is indicated (/sdd gate, /sdd spec, /sdd research…).

The structure of the launch prompt

The assembled context splits into two layers: the permanent context — condensed AGENT-GUIDE (ALWAYS/NEVER rules, conventions, vocabulary) and ARCHITECTURE summary (≤ 500 tokens) — and the task context — ONE single SPEC, complete, with the relevant source files listed in §6. Never two unrelated SPECs, never the full PRD.

## Context
[Condensed AGENT-GUIDE]
[ARCHITECTURE summary]

## Task
[SPEC §2 — Expected Behaviour]

## Success criteria
[SPEC §3 — Acceptance Criteria]

## Constraints
[Applicable ALWAYS/NEVER rules]
[Applicable governance (regulatory-veto output)]

## Files to modify/create
[List]

The placement rule matters as much as the content: the Intent and the active SPEC go at the top of the context, to counter the lost-in-the-middle effect — models' tendency to degrade their attention over the middle of a long context. The total budget is checked by the context-budget skill before launch: beyond about 50K tokens — an assumed sobriety heuristic, not sourced, not a technical limit —, you condense (summaries of large files, interface extraction) rather than "inject everything and hope". Governance is qualified by regulatory-veto: a Tier 1 VETO forbids the launch.

An implementation plan before the code

The agent never starts by coding: /sdd exec requires an implementation plan that the PE validates before the first line. Since §3.6, this plan is phased into testable vertical slices (.aiad/exec/EXEC-<SPEC-id>-plan.md): each slice declares its objective, its files, its tests — mandatory — and its "Done". A mini-gate (npx aiad-sdd mini-gate <SPEC-id> --phase N) validates each slice before the next. This avoids the classic trap: 1,200 lines of horizontal code before a single test.

Keeping the agent in scope

During the session, the PE observes: is the agent following the SPEC? Are signs of drift appearing? An agent that drifts is not at fault if the SPEC was imprecise — that is a Human Learning, not a Lesson Learned. More than two re-prompts for the same SPEC signal a SPEC that is too ambitious: head for /sdd split. The prompt also carries the JNSP contract: facing an undecidable area, the agent writes // TODO-JNSP: <question> and stops, rather than inventing the missing value.

Stop points during execution

Authorised to write on a validated SPEC, the agent is not thereby authorised to do everything: the authority continuum excludes any action outside the SPEC's scope and, a fortiori, any undeclared irreversible action. During the session, the agent comes back to the human at the planned stop points — approval, expert opinion, plurality of viewpoints, witness —, specified where relevant in the "Agent stop points" section of the SPEC. If the SPEC declares an irreversible action, its stop threshold applies: any observed overreach of autonomy halts the agent and triggers an immediate human review, not an after-the-fact report.

A permission mode is not a control

Harnesses offer permission modes — manual approval, automatic classifier, allow-lists. They reduce friction; they do not constitute an enforceable guarantee. In August 2026, Johann Rehberger bypassed Claude Code's automatic mode in 80% of his attempts, and in some cases the classifier allowed the malicious process and then blocked the remediation command launched by the agent. The protection of an execution session rests on isolation: container or virtual machine, restricted network egress, no superfluous credentials (SSH keys, cloud keys) in the agent's environment. The permission mode comes as a complement, never as a substitute — see Agent autonomy.

Delegating to sub-agents: delegate early

The cost of a delegation depends on the harness mechanism. If the sub-agent inherits the parent conversation — the default in some harnesses —, its cost is parent context at the time of the fork + its own work, not a marginal cost. Three consequences:

• delegate early, while the parent context is still light;
• the fork point is an explicit cost item in the Context Audit;
• if inheritance is disabled, the sub-agent starts from a blank context and must be given the Intent Statement and the active SPEC explicitly.

Messaging between agent sessions does not exempt you from traceability: any decision taken between agents that changes a behaviour is reported in the SPEC (Drift Lock).

Resuming an interrupted session — /sdd resume

Interruptions (timeout, error, conversation limit, voluntary pause) are normal — not a failure. /sdd resume rebuilds a minimal context instead of re-injecting the whole session: an inventory of the work done (git status, git diff), covered vs. remaining criteria, then a resume prompt containing only the condensed AGENT-GUIDE, the full SPEC and the state summary.

SESSION STATE — SPEC-NNN
══════════════════════════════
Files created      : [list]
Files modified     : [list]
Tests added        : X (Y passing, Z failing)
Criteria completed : X/Y

Remaining work:
- [ ] [Uncovered criterion]

The feedback loop — /sdd context

After each session, /sdd context compares the budget estimate (SPEC §6) with reality: tokens consumed, observed degradation, actual duration. The recommendations it produces improve the next session — the framework's empiricism applied to the Context Engineering Budget itself.

Machine-verifiable annotations in the produced code

All application code produced during the session carries the v1.10 traceability annotations — this is what makes the Drift Lock algorithmically measurable:

/**
 * @intent INTENT-042
 * @spec SPEC-042-1-flow-auth
 * @verified-by tests/auth/oidc.test.ts
 * @governance AIAD-RGPD
 */

@spec is mandatory (cardinality 1..n) on all application code; @intent, @verified-by and @governance complete the Intent ↔ SPEC ↔ Code ↔ Tests chain. Annotations are accepted in JSDoc, // or # comments and Python docstrings. Once every slice is validated and the tests are green: head for /sdd validate.