Progressive Agentic Development

A repeatable system for building software progressively.

✶
Core Idea
Move the project forward with one development standard
Progressive Agentic Development is a repeatable way to build software step by step. It keeps the work moving forward through one development standard instead of restarting from zero. The three pillars below make that possible.
✎
Specification
Define the target before building.
Turn the request into clear scope, tests, and completion criteria.
✓
Test-Driven Development
Build against tests, not against guesses.
Write tests first, then implement and verify against a concrete target.
⟶
Handoffs / Long-Term Memory
Carry progress across chats.
Keep the current state, evidence, findings, and next owner visible so work continues instead of restarting.

Full Feature Journey

How the work moves from request to ready result.

↻
Main Flow
A feature moves forward only after it has been verified
A feature request moves through specification, implementation, and verification until the feature is ready. That journey can continue across multiple chats, with different session roles, without losing context.
Multi-Session
One feature can span multiple chats
A single feature does not have to finish in one conversation. It can move across multiple chats and session roles while the work keeps moving forward.
Continuity
Each session resumes the same feature from the active handoff
The next chat picks up the same feature from the latest state, evidence, findings, and next owner instead of starting over.
Acceptance
Verification decides the next move
Verification can move the work forward, request user review, or send it back to specification or implementation. The verifier makes the final pass decision.
flowchart TD
    A["Idea /
feature request"]
    B["Specification
session"]
    C["Implementation
session"]
    D{"Verification
session"}
    E["User manual
review"]
    F["Approved
implementation"]
    G["Feature
ready"]

    A --> B --> C --> D
    D -->|"Fix implementation"| C
    D -->|"Fix spec"| B
    D -->|"Manual review"| E
    E -->|"Review complete"| D
    D -->|"Pass"| F --> G

    style A fill:#4a6a8a,stroke:#3a5a7a,color:#fff
    style B fill:#3d5a80,stroke:#2c4a6e,color:#fff
    style C fill:#5a7a50,stroke:#4a6a40,color:#fff
    style D fill:#8a3d3d,stroke:#6e2c2c,color:#fff
    style E fill:#4a6a8a,stroke:#3a5a7a,color:#fff
    style F fill:#8a6d3b,stroke:#6e5530,color:#fff
    style G fill:#5e4b8a,stroke:#4a3a6e,color:#fff

Specification Session

Turn the request into a clear target.

✎
Session 1
Clarify the request before anyone builds
This session reads the workflow rules, works through open questions with the user, writes the spec, defines tests and completion criteria, and leaves the next step a clear target.
What Goes In
Request, workflow rules, active handoff
This session starts by reading the workflow rules, the current stage state, and the latest handoff for the work.
What Happens Here
Guided Q&A across the whole feature
The agent works through the request with the user from multiple angles, including UX, UI, data flow, and edge cases, so hidden requirements become explicit before the spec is written.
What Comes Out
A buildable spec and the next handoff
The output is a clear spec plus a handoff that lets implementation continue without guessing.
flowchart TD
    S0["Read the workflow rules
and the active handoff"]
    S1["Guided Q&A
with the user"]
    S2{"Enough clarity
to write the spec?"}
    S3["Write the stage spec"]
    S4["Define tests and
completion criteria"]
    S5["Update the handoff
for the build session"]

    S0 --> S1 --> S2
    S2 -->|"Yes"| S1
    S2 -->|"No"| S3 --> S4 --> S5

    style S0 fill:#3d5a80,stroke:#2c4a6e,color:#fff
    style S1 fill:#4a6a8a,stroke:#3a5a7a,color:#fff
    style S2 fill:#3d5a80,stroke:#2c4a6e,color:#fff
    style S3 fill:#3d5a80,stroke:#2c4a6e,color:#fff
    style S4 fill:#3d5a80,stroke:#2c4a6e,color:#fff
    style S5 fill:#8a6d3b,stroke:#6e5530,color:#fff

Implementation Session

Build against the spec, not against memory.

⚒
Session 2
Test-Driven Development: define behavior, then build
This session applies Test-Driven Development. It starts from the workflow rules and the active handoff, re-states scope, writes automated tests first, implements the work, re-runs tests and targeted checks, and leaves fresh evidence for verification.
What Goes In
Spec, workflow rules, active handoff
Implementation starts from the workflow rules, the current handoff, and the agreed target in the spec.
What Happens Here
Define the expected behavior before building
The agent starts by writing automated tests that describe what the feature should do. As the code changes, those tests are run again and again to show whether the implementation matches the target and whether new changes broke anything earlier.
What Comes Out
A working implementation and verification evidence
The output is working code plus a handoff with evidence, risks, and enough detail for verification to judge it honestly.
flowchart TD
    I0["Read the workflow rules
and the active handoff"]
    I1["Re-state scope
and non-goals"]
    I2["Write automated tests
first"]
    I3["Implement the feature"]
    I4["Run tests and
targeted checks"]
    I5{"Tests and checks
pass?"}
    I6["Write self-review"]
    I7["Update the handoff
for verification"]

    I0 --> I1 --> I2 --> I3 --> I4 --> I5
    I5 -->|"No"| I3
    I5 -->|"Yes"| I6 --> I7

    style I0 fill:#8a6d3b,stroke:#6e5530,color:#fff
    style I1 fill:#5a7a50,stroke:#4a6a40,color:#fff
    style I2 fill:#5a7a50,stroke:#4a6a40,color:#fff
    style I3 fill:#5a7a50,stroke:#4a6a40,color:#fff
    style I4 fill:#5a7a50,stroke:#4a6a40,color:#fff
    style I5 fill:#5a7a50,stroke:#4a6a40,color:#fff
    style I6 fill:#5a7a50,stroke:#4a6a40,color:#fff
    style I7 fill:#8a6d3b,stroke:#6e5530,color:#fff

Verification Session

Verification is the acceptance gate.

✕
Session 3
Only Verified Work Moves Forward
This session re-runs the relevant checks, reviews the evidence, brings in the user when manual review is needed, and then either approves the implementation or sends it back with exact fixes.
What Goes In
Implementation, evidence, active handoff
Verification starts from the current handoff and evidence, not from a vague claim that the work is done.
What Happens Here
Checks, verifier review, user review
Most of this session is agent-owned. The user joins only when human validation is needed, while the verifier makes the final pass or send-back decision.
What Comes Out
Approval or exact fixes
Verification either approves the implementation or sends the work back with exact fixes. That decision controls whether the feature moves forward.
flowchart TD
    V0["Read the workflow rules
and the active handoff"]
    V1["Re-run the relevant checks"]
    V2["Review evidence
and requirement closure"]
    V3["User manual review
when needed"]
    V4{"Verifier
pass?"}
    V5["Send back with
exact fixes"]
    V6["Approve the implementation"]

    V0 --> V1 --> V2 --> V3 --> V4
    V4 -->|"No"| V5
    V4 -->|"Yes"| V6

    style V0 fill:#8a6d3b,stroke:#6e5530,color:#fff
    style V1 fill:#8a3d3d,stroke:#6e2c2c,color:#fff
    style V2 fill:#8a3d3d,stroke:#6e2c2c,color:#fff
    style V3 fill:#4a6a8a,stroke:#3a5a7a,color:#fff
    style V4 fill:#8a3d3d,stroke:#6e2c2c,color:#fff
    style V5 fill:#8a3d3d,stroke:#6e2c2c,color:#fff
    style V6 fill:#8a6d3b,stroke:#6e5530,color:#fff

Active Handoff

The handoff is the system's working memory.

⟶
Continuity
Each new chat starts from the handoff
The handoff is not a side note. It is how the system keeps work moving without losing the current state.
Status
Where is the work right now?
The handoff tells the next chat whether the work is in specification, implementation, verification, or already approved.
Evidence
What proof already exists?
It carries the latest checks, results, and supporting notes so the next chat starts from evidence rather than assumptions.
Findings
What still needs attention?
If verification found problems, the handoff keeps them visible so they survive into the next pass.
Next Owner
Who owns the next move?
The handoff makes the baton explicit. The next chat knows whether the work belongs to specification, implementation, or verification.

This is what allows the system to span multiple chats without becoming vague. The handoff keeps the current state visible between passes.

Takeaway

Software becomes more reliable when progress, discipline, and continuity stay connected.

✦
Final View
Progress comes from one standard repeated across the whole build
The system works because it keeps the target clear, builds against tests, verifies honestly, and carries the state forward between chats.
Define
Start with a clear target
Specification turns the request into scope, tests, and completion criteria before implementation begins.
Build
Implement against tests
Implementation uses tests first and leaves evidence behind so the next pass can judge the work on something concrete.
Carry Forward
Preserve continuity between passes
The active handoff keeps the current state, evidence, findings, and next owner alive until the work is truly ready.

Thank You

Stay in touch.

Stay in Touch
Thank you
Scan the QR code to connect after the talk.
QR code for contact details
Evgenii Mosikhin
Progressive Agentic Development