← Back to Resources

The BVDLC Delivery Model

BVDLC's Three Pillars explain why delivery works differently in the AI era. The Six Phases explain what to do and when. The Delivery Model explains who does it and how — the team shape, the shared context, and the working cadence that turn the method into a real production team.

Who this is for: Engineering leaders, CTOs, architects, and program leads standing up an AI-native delivery org.
What you’ll leave with: A concrete picture of how humans and agents share work, what sits in the shared context, and how a single feature moves from first signal to measured value.
How to use it: Read this hub for the overview, then follow the deep links into each sub-page.

The four building blocks

The delivery model rests on four things. Miss any one, and the other three stop working.

1. Context as code

Business intent, domain rules, and design decisions live as Markdown in the repository — versioned, reviewed, and read by every agent session. No tribal knowledge. No out-of-date wiki.

2. Clear roles

Four roles hold the model together: Context Manager, Engineering Practice Lead, Squad Lead, and Squad Engineer. Each one owns a specific kind of decision that agents cannot make.

3. Delivery squads

Work runs inside small teams of humans and agents — a senior engineer plus a handful of mid-level engineers, running concurrent agent sessions against a shared spec.

4. The delivery workflow

Every feature follows the six BVDLC phases through fourteen concrete steps, with four sign-off points where a human decision moves the work forward: intent approved, idea validated, spec locked, verified for release.

The delivery model at a glance

Three columns. Roles that make the decisions. Artifacts that carry the context. A cadence that moves work from first signal to measured value.

Roles

  • Context Manager
  • Engineering Practice Lead
  • Squad Lead
  • Squad Engineer
  • Product Manager
  • Business Analyst
  • Quality Lead

Artifacts

  • Business-context documentation
  • Architecture decisions
  • Glossary and coding standards
  • features/<name>/feature-brief.md
  • specs/<feature>/requirements, design, tasks

Cadence

  • Setup: stand up context + squads
  • Feature kickoff: intent → locked spec
  • Work breakdown: spec → tasks
  • Build: squad + agents → PRs
  • Verification: human sign-off
  • Value review: did the metric move?
  • Context retro: what confused agents

What the delivery model enforces

Five non-negotiable principles. If any is violated, the model breaks down into the same AI chaos it was built to prevent.

The four delivery-model roles

Traditional titles (PM, tech lead, engineer, QA) still exist. The delivery model adds four roles on top — the roles that make a human-agent team actually work.

Context Manager

Owns the shared context. Maintains it, unblocks teams, captures improvements, and coaches. Makes the shared context smarter every week.

See the playbook →

Engineering Practice Lead

Directs agents on the hardest work. Maintains code patterns. Coaches engineers on when to let an agent run and when to stop it.

See the playbook →

Squad Lead

Runs one delivery squad. Reviews agent PRs against spec intent. Owns end-to-end delivery of a feature area.

See the squad pattern →

Squad Engineer

Runs concurrent agent sessions. Feeds them context, reviews their output, writes the integration tests agents struggle with.

See the squad pattern →

Deep dives

Each page below goes one level deeper. Start with the workflow if you want to see how work flows; start with the squad page if you’re shaping the team.

← Back to Resources