In traditional Agile, the ticket is in Jira, the code is in GitHub, and the reasoning behind every decision lives in whoever ran the session. They don't reference each other. When the developer who talked to the agent leaves, the context goes with them.
Agentic Agile defines six artifacts. Each flows from the previous. None exists on its own.
The Spec File
Every team has some version of a shared plan. What's different here is what it must contain. The Spec File isn't a backlog. It's a live record: what was planned, what was built, what the Review surfaced, and what decisions were made. Every other artifact traces back to it.
The Spec File is where the plan and the reality meet.
Format is your call — markdown, Jira, Linear, Notion. What we've found matters is what it contains: a phase entry before Build begins, and a Review Record after it closes. Teams that treat the Spec File as a planning document and not a living record tend to lose most of the benefit.
The Ticket
A ticket is a scope statement. It defines the outcome, not the implementation. The Product Owner approves it before Build begins. The Developer may decompose a ticket into phases if the work spans more than one agent session — but each phase gets its own completeness criterion: one sentence that says exactly when the work is done.
If the ticket is vague, the phase will be vague. The agent will fill the ambiguity with its best guess. That guess may be reasonable. It will not be what you meant.
The Command
The Command is a file the Developer writes before the session begins — not during, not after. It encodes intent explicitly: which phase, which ticket, what done looks like, and who the agent is for this session. The agent doesn't infer scope from context. It acts on what the Command says.
Writing the Command before the session is the moment the Developer commits to a specific outcome. It's also when they discover whether the ticket is actually clear enough to act on. If the Command is hard to write, the ticket needs more work.
The Review Record
After Build, the Agent leads a Review. It asks the Developer questions about what was built, surfaces gaps in understanding, and flags divergences from the Spec File. The transcript of that exchange — questions, answers, and any unresolved items — is the Review Record. It gets appended to the Spec File phase entry.
The Review Record is what turns the Spec File from a plan into a history. The gap between plan and reality is exactly the information that disappears in traditional Agile. Here it gets written down.
The Pull Request
The PR is evaluated against the Spec File, not just for technical correctness. The Agent summarises what was built and how it maps to the phase criteria. The reviewer's question is "does this deliver what the spec said it would?" — not "does this code look right?" That's a different review and a more useful one.
The Anchor File
The anchor file is a repo-level artifact — a single file at the project root that maps tickets and phases to the actual files they touch. It is not embedded in source files and is not part of the Spec File. It sits alongside both.
An anchor entry records which ticket, which phase, which files were touched, who owns it, and what the acceptance criteria were. Over the life of a project it becomes a complete, queryable map of what was built and why. Entries can be written by hand, generated by the agent at phase close, or maintained by editor tooling — the format is open, any tool can read it.
The anchor file makes any file in the codebase traceable back to a decision.
Editor plugins can surface this inline when you open a file: ticket ID, phase, assignee, acceptance criteria — no context switching, no hunting through Jira. The information follows the code. But the artifact itself is independent of any editor or plugin.
In practice
The team has a feature in flight — FEAT-10, User Account Security. One of its tickets is PROJ-42: add authentication to the API. Here's the moment that ticket becomes a spec entry — the handoff from team work to agent work.
Add user authentication to API endpoint
Users need to be able to log in. The POST /login endpoint should accept email and password, verify credentials, and return a signed token.
Acceptance criteria
- ✓POST /login returns a signed JWT on valid credentials
- ✓Returns 401 on invalid credentials
- ✓Token payload contains user ID only — no email or sensitive fields
SPEC.md
## Phase 2: POST /login endpoint
Ticket: PROJ-42
Status: Spec
Criterion:
POST /login returns a signed JWT on valid credentials and 401 on invalid.
Constraints:
- Token payload: user ID only
- JWT_SECRET from environment — do not hardcode
- Route handler lives in src/routes/auth.ts
The ticket defines the goal. The spec entry narrows it to one phase with one testable criterion. That translation is the Developer's job — and it's done before the agent starts. Here's what the Review looks like after Build closes that phase.