Delivery Factory · Part 1

Delivery Factory · Part 1 · Architecture

The orchestrator that never reads code.

A ticket goes in, a pull request comes out, and fifteen steps run in between. The component that runs all fifteen knows almost nothing about any of them. That is the design. Repo: agentic-core, agentic-eds, agentic-jira, agentic-github, agentic-figma, agentic-playwright

Built as Plugins

Six Claude Code plugins. agentic-core drives the route. One platform plugin knows how to build on the project. Four provider plugins each talk to one tool: Jira, GitHub, Figma, Playwright.

The route and the rail1200 × 627
DELIVERY FACTORY · PART 1 Fifteen steps report up. The orchestrator reads five lines. EACH STEP AN ISOLATED AGENT ONE VERDICT PER STEP A HOOK BLOCKS EVERYTHING ELSE agentic-core · orchestrator sequences · reads the verdict · branches ## Result · 5 TICKET intake readiness extract conventions serve baseline prototype verify-design plan plan-gate implement verify lint publish-gate deliver PR .ai/run-context/ what each step read and wrote Read hook: blocked the orchestrator never opens what a step wrote
Every step runs as its own isolated agent and writes its work to files. What goes up to the orchestrator is a five-line verdict. The files stay where they are.

The problem

One agent that carries everything

The easy design for a long delivery route is one agent that walks every step itself.

One agent carries it all

Heavier every step

  • Every file it reads stays in its context.
  • Step fifteen pays for everything steps one to fourteen read.
  • It drifts into re-doing a step's work, because the material is right there.
  • When something breaks, nobody can say which step decided what.
The orchestrator knows almost nothing

Same weight every step

  • Each step runs as its own isolated agent and dies.
  • The orchestrator's context grows by one verdict per step.
  • It cannot re-do a step's work. It never sees the work.
  • Every decision has an owner: the step that returned it.

If your pipeline produced a wrong PR today, could you name the step that caused it?

Five lines

The only thing that crosses back

Every step, and every operation on a tool, ends with the same block. The orchestrator reads nothing else.

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

  • pass and warn continue

    A warning is recorded and the run goes on. Warn is never terminal.

  • fail ends the run

    The orchestrator prints the step and its summary. It never retries a step.

  • question stops for a human

    This is why the previous post's rule works. The orchestrator does not need to understand a problem to stop for it. It only needs to read one word.

The block is written by a script that refuses a field the verdict does not allow, and checked by another before the orchestrator branches on it. A run ends in exactly one of three states: delivered, blocked or failed.

One ticket

How the plugins talk

The plugins never call each other as programs. Everything goes through the Claude session, which invokes skills by name. Data moves through files and the closing block.

  1. You type /agentic-core:run-route ABC-123.
  2. The core reads the project config. It names which plugin plays which role.
  3. The core finds the platform plugin and reads its list of fifteen stages.
  4. The core starts the first stage, intake, as an isolated agent.
  5. That stage looks up which plugin is the tracker, and which skill fetches an item.
  6. It calls the Jira plugin's fetch-item by name. One script talks to Jira and returns the item.
  7. The stage writes the ticket to a file and ends with its own five lines.
  8. The core reads those five lines, and nothing else. Then the next stage.

The less the orchestrator knows, the longer the route it can run.

What it doesn't solve

A confident pass on the wrong thing

An orchestrator that reads only verdicts trusts them. Isolation does not make a step right.