Delivery Factory · Core concept

Delivery Factory · Concept

Delivery core concept.

A work item goes in, a pull request comes out. This page explains the idea in between: what is plain code, where a model is needed, and how a platform plugs in without the core knowing its name. Repo: github.com/agenticDraft/plugins

Built as plugins

Six Claude Code plugins. agentic-core drives the route and names no product. One platform pack, agentic-eds, says what each stage means for an Edge Delivery project. Four provider packs each fill one role: agentic-jira (tracker), agentic-github (scm), agentic-figma (design), agentic-playwright (browser).

Part one

The core

Everything in this part holds for any platform. The core defines the stages, the roles and the shapes; it never names a tracker, a design tool or a framework.

What it is

One command per ticket

Done by hand, delivering a ticket is a checklist. Done by one long prompt, it drifts.

One long prompt re-does work, carries every file it ever read, and nobody can say which step decided what. The core replaces it with one command, /agentic-core:run-route <item>. It reads the item, plans, builds, renders, compares against the design, lints, and stops for a human at the decisions that matter.

If you read only this

  1. A ticket goes in, a pull request comes out, from one command.
  2. The route is fixed: fifteen stages. The model never picks what comes next.
  3. Each stage runs as an isolated agent and reports back in five lines.
  4. Scripts decide what happens next; a model only does the work inside a stage. Three gates check the work, and a decision goes to a person.
  5. The core knows roles, not products. Jira, GitHub, Figma or EDS live in swappable packs.

Three layers

Where determinism stops

The core is not one program. It is three layers, and the useful thing to know is exactly where a model is needed.

Layer 1 · Scripts

No model, no tokens. A file goes in, one line and an exit code come out. Each script has its own test, so CI can prove this layer.

Layer 2 · Contracts

Markdown files that define each shape once: the result, the stages, the endings. Everything else points at them instead of restating them.

Layer 3 · The route driver

One skill, agentic-core:run-route. It owns control flow and nothing else. It is the only part that starts a stage, and it never reads what a stage wrote.

One run, step by step

What happens between command and pull request

Read top to bottom. Each row is one step, placed in the column that does the work.

One run of the route driverSetup · loop · end
One run of the route driver Nine numbered steps in three bands. Setup, once: scripts run the pre-flight checks, the driver spawns intake in a pack to read the ticket, and a script filters the fifteen stages to this run's list. Per stage, in a loop: the driver spawns the stage as an isolated subagent, which does the work and returns a five-line result; scripts read the verdict and save run state; right after readiness the driver creates the working branch; a question is handled by a script. End, once: a script resolves exactly one ending, delivered, blocked or failed. Violet steps are where a model works; cyan steps are deterministic code. STEP SCRIPTS · CODE DECIDES DRIVER PACKS · A MODEL WORKS next stage ONCE · SETUP 01 pre-flight checks config, packs, credentials, resume? → blocked calls 02 intake · tracker.fetch_item read the ticket as data, write the facts spawns 03 evaluate-stage-conditions.sh 15 stages → this run's list, once calls once PER STAGE · LOOP 04 stage · Skill(pack:stage) does the work in its own context spawns 05 run-stage.sh reads 5 lines: continue, question or end reads the verdict 06 write-run-state.sh state and progress saved, a run can resume calls 07 scm.create_branch once, right after readiness calls directly 08 handle-question.sh ask a person, then run the stage once more on question ONCE · END 09 resolve-terminal-state.sh exactly one ending calls ## Result, 5 lines the run ends in exactly one of delivered blocked failed

Scroll the figure sideways to see every column.

Deterministic code decides A model works Only after readiness
Inside the loop a model does exactly two things: the driver starts the stage, and the stage does its work. Every decision about what happens next is a script reading the five-line result.

The core's vocabulary

Everything the core knows

This is the whole vocabulary. A word outside it belongs to a pack.

Fifteen stages

Fixed, in the order a full route runs them. A pack implements a stage or declines it; no pack may add one. The three gates are outlined.

  1. intake
  2. readiness
  3. extract
  4. conventions
  5. serve
  6. baseline
  7. prototype
  8. verify-design
  9. plan
  10. plan-gate
  11. implement
  12. verify
  13. lint
  14. publish-gate
  15. deliver

Four roles

tracker
Where the work item lives.
scm
Where the change is published.
design
Where the design reference comes from.
browser
What renders and measures the page.

A stage calls a role, never a product. Project config binds each role to one provider pack.

The five-line result

## Result
verdict: pass | warn | fail | question
summary: <one sentence>
artifacts:
  - <path written or updated>
next_action: <short phrase, or "none">

Every stage ends with this block. The driver reads nothing else.

Verdicts

pass
Go to the next stage.
warn
Go on; the warning is recorded.
fail
The run ends. The driver never retries.
question
A person answers and the stage runs once more. With nobody to ask, the run ends blocked.

Three gates, three endings

readiness, plan-gate and publish-gate check with scripts first, then a reviewing model looks only at what survives. A gate may not change the project; the driver checks that before and after.

delivered

The last stage passed. The pull request exists.

blocked

Something is missing: an answer, a login, a tool. The run says what and where.

failed

A stage failed or broke a contract. The run names the stage.

Exactly one of the three ends every run.

Design against published guidance

How it lines up with Anthropic's advice

Each row pairs a design decision with the published guidance it matches.

What the core doesWhat the guidance says
A fixed route of fifteen stages. The model never decides which stage comes next.
Use a workflow, a predefined code path, when the task is predictable. Add autonomy only where it pays for itself.Building effective agents
Scripts before any model. Deterministic checks run first and cost nothing; a reviewing model sees only what survives.
Grade with code first and with a model only where code cannot decide.Demystifying evals
One isolated agent per stage. The driver's context grows by five lines per stage, never by what a stage read.
A subagent works in its own context window and hands back a condensed result.Multi-agent research system
The human decides. Three gates, and a question asked only between stages.
Keep a person in the loop for decisions that are costly to get wrong.Building effective agents
Tickets are untrusted input. intake cleans the item before anything acts on it.
Treat content the agent reads, such as tickets and documents, as data, never as instructions.Mitigate jailbreaks and prompt injections

Part two

A platform pack: agentic-eds

One worked example of how a platform binds the core's stages. Everything in this part is the pack's, not the core's.

EDS is one swappable platform pack. A pack implements or declines each of the fifteen stages and never adds a new one. A React or Next.js pack could bind the same stages its own way, with no change to the core.

The default route

Fifteen stages, four of them conditional

From agentic-eds/pack.yaml. Conditions are checked once, after intake; a skipped stage passes control to the next one in the list.

agentic-eds · route.dotConditions from the fact record
The agentic-eds default route Fifteen stages in three rows of five, in list order. Gates: readiness, plan-gate, publish-gate. Conditional: extract, prototype and verify-design run when design_source or design_mentioned is true; baseline runs when components are present. Edit budgets: verify-design 2, plan 1, lint 3. The driver creates the working branch between readiness and extract. After deliver, the run is delivered. delivered 01 intake always 02 readiness gate 03 extract conditional design_source OR design_mentioned 04 conventions always 05 serve always 06 baseline conditional components = present 07 prototype conditional design_source OR design_mentioned 08 verify-design conditional · 2 edits design_source OR design_mentioned 09 plan always · 1 edit 10 plan-gate gate 11 implement always 12 verify always 13 lint always · 3 edits 14 publish-gate gate 15 deliver always driver: scm.create_branch always conditional on the fact record gate: deterministic checks first, then a reviewing model the driver's own provider call

Scroll the figure sideways to see the whole route.

A dashed stage runs only when its condition matches what intake learned about the ticket.

Read from agentic-core 0.2.18 and agentic-eds 0.2.14 on main.

All parts · Repo