Agentic Use of AIDD-17

Why this is agentic

AIDD-17 is not only a documentation format. It is a way to coordinate work between humans, AI assistants, coding agents, review agents, and delivery processes.

The project definition acts as the shared operating context. Agents can work from that context, but they do not own product direction, architecture approval, or acceptance of work.

Agent roles

AIDD-17 works best when agents have narrow roles.

Common roles include:

Definition Agent — helps structure the project definition
Slice Agent — creates implementation slices from approved definitions
Implementation Agent — implements one approved slice
Review Agent — checks implementation against the project definition
Adversarial Review Agent — looks for drift, assumptions, security risks, and hidden scope
Documentation Agent — updates documentation after approved change

Agents may assist, but ownership remains with the project team.

propose implementation steps
write or modify code within a slice
generate tests
identify missing information
review work against the project definition
suggest follow-up slices
update documentation after approval

Standard agentic loop

Human defines or approves the project intent.
A slice is created from the project definition.
An implementation agent works only on that slice.
A review agent checks the work against the definition.
An adversarial reviewer checks for feature drift and hidden assumptions.
A human reviewer accepts, rejects, or redirects the work.
Approved changes update the project definition and implementation plan.

Agent instructions

Use bounded instructions when assigning work to an agent.

You are working inside an AIDD-17 project.

Use the provided project definition, implementation slice, decision records, interfaces, data structures, and verification criteria as the source of truth.

Implement only the assigned slice.

Do not invent product behaviour, architecture, interfaces, data structures, delivery rules, or verification criteria.

Do not implement future slices early.

Stop and report if required context is missing, contradictory, ambiguous, or would require out-of-scope changes.

Return:
- summary of changes
- files changed
- tests added or changed
- assumptions made
- unresolved questions
- potential feature drift
- suggested follow-up slices
- verification performed

Agent review instructions

Use a different instruction for review agents.

Review the implementation against the AIDD-17 project definition and assigned implementation slice.

Check for:
- missing behaviour
- unapproved behaviour
- scope drift
- architecture drift
- interface drift
- data model drift
- missing tests
- weak verification
- undocumented assumptions
- unresolved questions

Do not approve the work. Provide a review report and recommendation for the human reviewer.

AI consensus

AI consensus can be useful when the risk of drift is high, but it should be used as a review technique rather than an approval mechanism.

For higher-risk work, use multiple review passes:

one reviewer checks product intent
one reviewer checks architecture
one reviewer checks tests and verification
one reviewer checks feature drift and hidden assumptions

If reviewers disagree, the disagreement should be surfaced to the human reviewer. The goal is not to let AI vote. The goal is to expose ambiguity before acceptance.

Documentation update rule

Agentic delivery is only safe when the project definition stays current.

After accepted work, update:

project definition
implementation plan
decision records
interface definitions
data structures
verification criteria
follow-up slices

If the implementation changes the project but the documentation does not change, the system has drifted.