ADLC — Agentic Development Life Cycle
ADLC — Agentic Development Life Cycle
Section titled “ADLC — Agentic Development Life Cycle”The Software Development Life Cycle (SDLC) was designed for teams of humans. It assumes that every actor in the loop reads specs the same way, follows conventions, asks questions when unsure, and learns from the codebase over time. That model starts to crack the moment an AI agent joins the team — not as a helper invoked ad-hoc, but as a first-class participant executing tasks day-to-day.
ADLC — the Agentic Development Life Cycle — is what the SDLC becomes once you take agents seriously. Okto Pulse is built from the ground up to support this cycle.
What changes
Section titled “What changes”| SDLC assumption | What breaks with agents | ADLC response |
|---|---|---|
| Specs are “best effort” context | Agents need explicit, machine-readable specs to act correctly | Spec is a first-class artefact with required fields |
| Work items flow loosely through stages | Agents jump stages without gates if permitted | Stage transitions are permissioned, explicitly |
| Roles are human job titles | Agents need surgical permission grids, not titles | Role = resource matrix (read/write/gate by artefact) |
| “Ask the team” for context | Agents can’t meaningfully ask a Slack channel | Context is linked in the artefact graph |
| Validation is PR review | Agents can out-throughput any human reviewer | Dedicated validator role gates spec/task/sprint |
The four moves of ADLC
Section titled “The four moves of ADLC”01 · Intent is specified
Section titled “01 · Intent is specified”Every unit of work traces to a spec. No “just try this and see” tickets. Upstream roles (humans, or agents in the Spec preset) own ideation → refinement → spec. Downstream executor agents can only act on specs that are approved.
02 · Agents execute
Section titled “02 · Agents execute”Executor agents (human-driven, AI-driven, or mixed) pick tasks linked to specs. They never touch the spec itself — that would be a conflict of interest. MCP exposes the board so any MCP-aware agent (Claude Code, Cursor, Windsurf, custom orchestrators) gets the full API, role-permissioned.
03 · Gates validate
Section titled “03 · Gates validate”The Validator role has exclusive rights to submit spec/task/sprint validations. An agent executing can mark a task “ready for validation” but cannot close it. A validator agent (or human) evaluates against the original spec and either passes or rejects.
04 · Everything is traceable
Section titled “04 · Everything is traceable”Task → Sprint → Spec → Refinement → Ideation. The chain is enforced at the data model. Every shipped card is auditable back to the motivating idea. This isn’t governance theater — it’s what lets you ask “why did we build this?” six months later and get a real answer.
How Pulse implements ADLC
Section titled “How Pulse implements ADLC”- Pipeline model — 5 explicit stages, each with artefacts and gates. See The Pulse Pipeline.
- Role system — 5 built-in presets + Custom, mapping the ADLC roles above. See Agent Roles.
- MCP server — 150+ tools spanning the entire board, role-aware. See MCP Integration.
- Local-first data model — SQLite on your machine. You own the trace graph.
Why “life cycle” and not just “workflow”
Section titled “Why “life cycle” and not just “workflow””Workflows are task-by-task. Life cycles are about how intent becomes a shipped unit of work and how knowledge accumulates across many cycles. ADLC is the latter — it names the whole loop, not just the kanban lane.
Further reading
Section titled “Further reading”- The Pulse Pipeline — the five stages in detail.
- Agent Roles — how the ADLC role model maps to built-in presets.
- MCP Integration — wiring agents into the cycle.