# The Agentic Pipeline Starter

**The written structure that lets AI agents produce work you would sign.**

This file is extracted from a working pipeline: one person running research,
product design, front-end, and marketing for a live product, with AI agents
doing most of the production. Every mechanism below is in use — none of it
is theoretical, and none of it requires you to be an engineer. The examples
are from design; swap the nouns for your craft.

The one-line version: **agents don't fail from lack of skill, they fail from
lack of written context.** A fresh session has no memory of the last one and
no access to your head. Everything here is a way of putting your judgment on
paper once, so you stop re-issuing it forever.

**Contents**

1. [Roles, not tools](#1-roles-not-tools)
2. [The rules file](#2-the-rules-file)
3. [The pass gate](#3-the-pass-gate)
4. [The log](#4-the-log)
5. [The decisions ledger](#5-the-decisions-ledger)
6. [Drift checks](#6-drift-checks)
7. [The weekly loop](#7-the-weekly-loop)
8. [Starting from zero](#8-starting-from-zero)

---

## 1. Roles, not tools

Every tool is replaceable; the shape is not. A working pipeline has four
seats, and the question that runs it is never "which tool should I use?" —
it is "which role is missing?"

| Role | Its job | My instance | The artifact it owns |
| --- | --- | --- | --- |
| Research | Reads what you collected, argues back | Claude | themes, summaries, briefs |
| Execution | Produces the work, inside written rules | Claude Code | screens, components, code |
| Memory | Every version, with what/why attached | GitHub | the history |
| Documentation | The pages every role reads and writes | Notion | decisions, briefs, the ledger |

Fill in yours:

| Role | In my work | Tool I'll audition | The artifact it owns |
| --- | --- | --- | --- |
| Research | ______ | ______ | ______ |
| Execution | ______ | ______ | ______ |
| Memory | ______ | ______ | ______ |
| Documentation | ______ | ______ | ______ |

Start execution on a short leash: throwaway drafts, then work you can check
cheaply, then production inside the rules below. Hand more over each time
reviews stop catching mistakes a written rule could have prevented. Judgment
is never handed over — it is written down (§2) so the agent can borrow it.

---

## 2. The rules file

The core document. A style guide tells an agent what things *are*; it never
says *when* or *why*, and that gap is where every generated screen, draft,
and deck quietly drifts. Write three layers:

### Layer 1 — Closed sets

Your recurring choices, as short fixed lists. The power is in what they
exclude. Real lines from mine:

> Radius: 4px and 8px. **That is the whole scale.** Do not introduce a third
> value.
> Spacing: 4 · 8 · 12 · 16 · 20 · 24 · 32 · 40 · 48 · 64. If 12 is tight
> and 16 is loose, ship 16 — the gap between steps is the hierarchy signal,
> and filling it in destroys it.
> Motion: four named transitions (enter 200ms · exit 120ms · layout 200ms ·
> settle 320ms). One of them is right. Inventing a duration is like
> inventing a color.

A writer's closed sets: the product vocabulary, the heading forms you use,
the three lengths a piece can be. An analyst's: the metrics that exist, the
one definition of each.

### Layer 2 — Judgment

When to use which, and why — the layer that lives in your head, which is
exactly why an agent can't follow it until you write it. Two habits make
this layer strong:

- **Record the tradeoff, not just the verdict.**
  > "Blue marks the single element that is active, running, or awaiting
  > you. Never decoration, never a default fill — if two things are blue,
  > neither reads as the action."
- **Record reversals.** When a decision gets made twice, write down both the
  answer and the fact that it was once wrong:
  > "Balances are per agent, not per workspace. **This was reversed once
  > mid-design; do not rebuild it as a shared pool.**"
  A rule that carries its own history stops the third debate before it
  starts.

### Layer 3 — Guardrails

The never-list. Short, absolute, and where possible written as *data* so a
check can enforce it (§6). Mine includes a banned-vocabulary list — seven
words the product never says to a user (jargon like "runtime" and "tenant";
we say "credits", never "tokens") — and it is enforced mechanically, not by
hoping everyone remembers.

**The test of every rule:** a stranger with no context could follow it and
produce work you'd keep. An agent session *is* that stranger. If a review
catches the same mistake twice, that review comment is a rule you haven't
written yet.

---

## 3. The pass gate

The mechanism that lets an agent build without letting it decide. The
boundary in one line, straight from my working agreement:

> **Compose freely from what exists. Invent nothing at the decision layer.**

New arrangements of existing decisions need no permission — the agent
assembles screens from existing components all day. A new *decision* (a new
color, a new claim, a new pattern, anything that changes what the work
means) goes through a queue:

```md
## DR-7 · Line chart component
- Status: proposed → approved
- Needed: the dashboard charts growth over time; nothing in the
  system draws a line.
- Smallest version that unblocks: single series, hairline grid,
  one accent dot. Multi-series is deliberately out of scope.
- Approved-by: <name>, <date>, "<the actual words>"
```

Four working rules:

- **Statuses are** `proposed → approved / rejected → built`. An approved
  entry must name its human approver — in my repo, automation fails the
  change if it doesn't.
- **Don't block on the queue.** Propose, then keep building everything
  else.
- **Ask for the smallest version that unblocks.** The version the agent
  invents is the version you'll have to argue with later; give it less to
  argue with.
- **Label guesses on the work itself.** When the agent builds something
  speculative (approved but never properly designed), the artifact says so
  on its face — one line, "built to a reasonable interpretation, no spec
  exists." A reviewer knows in one second whether they're looking at a spec
  or a guess.

Keep an **invented-work table**: everything built as a guess, what it stands
in for, what would replace it. When the real decision arrives, *replace* the
guess rather than adjusting it — adjusted guesses keep the shape of the
guess.

---

## 4. The log

Every change to anything protected — the rules file, the system, the
published work — gets a log entry *in the same change*, answering three
questions:

```md
## <date> · <what changed, as one honest sentence>
- What: the change, concretely.
- Why: the reasoning, including what was wrong before.
- Decided by: who called it — with their actual words.
```

Mine opens with a confession that doubles as the argument for its own
existence: *"The first entries below are reconstructed from git history,
because the log did not exist when the changes landed. That gap is the
reason it exists now."*

Two details that make a log work:

- **"Decided by" quotes the human verbatim.** "Owner: 'the h1 header should
  still be there. It's gone from all the pages right now'" is evidence;
  "per feedback" is not. Six months later, the quote settles arguments the
  paraphrase would restart.
- **It is enforced, not encouraged.** In my repo, a change that touches a
  protected surface without a log entry fails automatically. Thirty seconds
  of writing in exchange for never reconstructing intent from a diff three
  weeks later.

Non-engineer version: one running document, newest first, same three lines
per entry, written the moment the change ships. The discipline is the
system; the software is optional.

---

## 5. The decisions ledger

The hardest problem is that your tools cannot talk to each other. The agent
that researched a decision cannot hand it to the agent that builds — except
through a page both can read. So documentation is a *role*, not a chore,
and its main artifact is one ledger:

```md
> Running ledger of ratified decisions and what's still open.
> Update this page whenever something locks — it is the team's memory.

# Open (needs a decision)
1. ______ — what's blocking, who decides

# Ratified <date>
- ______ — the decision, one line, with its reason
```

And per piece of work, a **brief** addressed to the executing agent by
name, with a sources-of-truth header so conflicts resolve themselves:

```md
Audience: <the executing agent>.
Sources of truth: visuals = <the design file> · behavior & copy = this
doc · product questions = docs 01–03.
Where sources conflict: <which one wins, for what>.
```

The session ritual, both directions: **start** by reading the rules file
and the newest ledger entries; **end** by writing one entry back. My
ledger's own convention line says the rest: *"Discuss before executing;
execute decisively once greenlit."*

---

## 6. Drift checks

Drift is not the tool failing. Drift is a decision you haven't written
down, being re-made — slightly differently — by every session. Left alone
it compounds into the classic symptoms: three button heights, four grays,
a folder named `final_FINAL_approved`.

Catch it mechanically where you can:

- Mine runs a check on every change: no raw color values, nothing off the
  spacing scale, no invented durations, none of the banned words in
  user-facing text. Machines are better than promises.
- The non-engineer version is a **monthly side-by-side**: this week's
  output next to last month's. Same hand? For every mismatch, ask which
  rule was missing — then write it (§2) instead of just fixing the
  instance. Fixing one instance guarantees the next batch repeats it.

---

## 7. The weekly loop

Fifteen minutes. The pipeline is a garden, not a machine.

- [ ] **Drift:** side-by-side check; every repeat-mistake becomes a rule.
- [ ] **Rules:** did any rule get ignored because it was wrong? Change it —
  and log the change (§4). Rules are living, not laws.
- [ ] **Gate:** review the queue. Approve, reject, or shrink each proposal
  to its smallest version. Anything `built` without an approver's name?
- [ ] **Ledger:** current? A stale ledger is worse than none — agents act
  on stale decisions confidently.
- [ ] **Roles:** what did you do by hand this week that a role should own?
  That's the next thing to pipeline.

---

## 8. Starting from zero

In order, and each step is small:

1. **Write ten lines of rules** (§2): your closed sets, two judgment lines
   with their tradeoffs, three nevers. Ten honest lines beat a manifesto.
2. **Create the ledger** (§5) and put today's first decision on it, with
   its reason.
3. **Point one agent at both** and give it real work on a short leash.
   Every correction you make, ask: is this a missing rule? Write it.
4. **Start the log** (§4) the first time the agent changes something you
   care about. Three lines per change, human quotes included.
5. **Add the gate** (§3) the first time the agent invents something you
   didn't ask for. That moment arrives on its own schedule; the queue is
   how you say yes safely instead of saying no.
6. **Add the second role** only when the first has earned it. The bridge
   already exists — the new agent reads the same ledger.

You'll know it's working when the corrections trend from repetition toward
taste, when "why is it like this?" is a lookup instead of an argument, and
when a new tool can join in an afternoon because everything it needs to
know is written down. The judgment is still yours — on paper, where a crew
can borrow it, and in your hands, where it stays.

---

*From "Building an agentic design pipeline" —
https://www.hribhav.co/experiments/agentic-design-pipeline*