HomeThe Build › Part 10
How We Built It · Part 10 of 10

Your Turn: The Start-Small Playbook

This is the part where we stop talking about what we built and hand the tools to you. Everything in this series, distilled into seven concrete steps you can start today — plus the full free Starter Kit to get you there faster.

You do not need a fleet of agents, a custom orchestration layer, or months of runway to get started. The honest truth from building all of this: the first 20 percent of the effort — the memory system and the handoff discipline — delivered more than half the total value. The rest is compounding on a solid foundation. So that is where you begin.

The 7-Step Path

Step 1 — Give your AI a memory

Before anything else, create three plain markdown files in your project folder:

At the start of every AI session, paste these files into context or instruct the agent to load them first. That is the entire memory system at its core. A fresh AI session with no memory is a goldfish. A fresh AI session that reloads these three files is a colleague.

The single highest-leverage thing in this series: structured memory that reloads at session start. It compounds every time you add a lesson or close a decision. Everything else in this playbook builds on it.

Step 2 — Add a handoff file

Create a fourth file: handoff.md. At the end of every session — before you close the tab — write three things: what you completed, what is in flight, and what the very next action is. Keep it short. Two to five bullet points is enough.

This file is the baton you pass to your next session (or your next agent). Without it, you spend the first fifteen minutes of every new session reconstructing where you left off. With it, you open context and you are already moving.

Hard lesson: the handoff file is only valuable if you update it before you close the session, not at the start of the next one. Sessions end unexpectedly — a crash, an auto-compact, an interruption. Write the handoff first, then wrap up. It is thirty seconds of insurance.

Step 3 — Write five operating rules

Before you add any automation, write a short constitution for how work gets done. Five rules to start:

  1. Verify before done. Nothing is complete until it has been tested through the real public surface, not just checked in a terminal.
  2. Report honestly. Say what you did not do as clearly as what you did. "Partial" is acceptable. "Done" when it is not is not.
  3. No placeholders in production. If a value is unknown, the page does not ship. A made-up number is worse than no number.
  4. Load memory before acting. Every session, every agent, loads the memory files before doing anything else.
  5. Keep working through interruptions. When a session resets or a task is interrupted, the next action is written in the handoff. Pick it up and continue. Do not wait for someone to re-brief you.

These five rules, consistently followed, prevent the majority of failure modes this series documented. They are not clever — they are just disciplined.

Step 4 — Add a quality gate

Now you can start generating content, but do not deploy it directly. The pattern is: generate to disk, review separately, fix only what is flagged, then ship only what passes.

The review pass should be a different prompt — a skeptical second reader whose only job is to find problems. Ask it specifically: are any facts in this piece invented or unverified? Is any number a guess? Does anything contradict what we know to be true? If the answer is yes to any of these, the piece does not ship until it is corrected.

Hard lesson from this build: in one bulk content run, roughly one in five pages contained an invented fact — a wrong etymology, an inaccurate date. The content felt confident. The gate caught it. "Low-stakes" content is where fabrication hides most comfortably, because nobody expects to fact-check it. Gate everything.

Step 5 — Add a second agent: the orchestrator

Once you have memory, handoffs, rules, and a gate working, you are ready for a second agent. Not another worker — an orchestrator. The orchestrator holds the plan, routes work to workers, and synthesizes the results. The worker executes a scoped task and returns structured output. The orchestrator commits and deploys.

Brief workers the same way you would brief a smart colleague who just walked into the room: clear scope, the relevant context files, a concrete description of what to return. "Based on your findings, decide what to do" is not a brief — that is an abdication. Decide first, then delegate execution.

The orchestrator is the only agent with permission to commit and deploy. Workers are read-only by default. This is not bureaucracy — it is the only way to prevent two agents from clobbering each other's work on the same file.

Step 6 — Add parallel work carefully

When you need to produce a large batch of content, fan workers out in parallel — but treat the shared rate budget as global. Firing several large concurrent jobs at once does not run faster; it trips limits and most of the work comes back empty. The recovered lesson: one controlled job at a time, batched in small groups, with the orchestrator managing the queue.

The good news: if a job hangs or fails partway through, work generated before the failure is usually recoverable from the job's own output. Nothing is truly lost — the system picks up from where the journal shows it stopped.

Practical rule: test your parallelism at a small scale before committing a full batch. If ten workers run cleanly, a hundred probably will not. Find the number that fits inside your rate budget and stay there.

Step 7 — Grow toward higher-value content

Not all content earns equally. Simple utility pages and thin game pages earn at one rate; educational, professional, and business-intent content earns at multiples of that. The strategic compounding asset is genuinely useful content — content that earns natural backlinks, that people bookmark, that an AI citation engine surfaces because it answers a real question well.

Volume for its own sake is a slow treadmill. The durable play is to use the system you have built to grow toward higher-value verticals on properties you own, rather than churning out pages that compound into noise.

The Full Starter Kit

Everything you need to run these seven steps is packaged below. Each piece is generic and reusable — fill in the variables for your own project and go.

Memory + Handoff Templates

Four markdown files: state.md, decisions.md, lessons.md, and handoff.md — each pre-structured with the right sections and example entries. Copy them into your project folder and start filling them in today.

Download Templates (ZIP)

Content Swarm + QA Gate Recipe

The generate → save → review → fix → ship checklist as a reusable, tool-agnostic document. Includes the skeptical reviewer prompt, the flagging format, and the go/no-go decision tree. Works with any AI tool you are already using.

Download QA Recipe

Operating Rules Starter ("The 5 Decrees")

A short, plain-language constitution adapted from the rules that run this system — with the five core rules expanded into a format you can paste directly into any agent's system prompt or session context. Edit, extend, and make it yours.

Download Rules Starter

memlint — The Open-Source Memory Linter (CLI)

A small command-line tool that checks your memory files for common drift problems: decisions without reasons, lessons without concrete fixes, handoffs older than a configurable threshold, and state files that reference pages which no longer exist. Run it before every session start to keep your memory clean. MIT licensed, no dependencies beyond the standard library.

download memlint.py from the kit above
memlint check ./memory/
Download memlint.py

A Few Honest Closing Notes

This system is not autonomous. At every step, there is a human setting direction — deciding which verticals matter, approving architectural changes, reviewing the lessons log. The agents are fast and tireless, but the judgment is yours. That is not a limitation to engineer away; it is the feature that keeps the output trustworthy.

The hardest part is not the technology. It is the discipline of maintaining the memory files, writing the handoffs before you close the tab, and running the quality gate even when the content feels fine. The gate is most valuable precisely when the content feels fine — that is when fabrication hides.

Start with Step 1 today. A single memory file, loaded at the start of your next AI session, will change how that session goes. The rest follows from there.

One concrete action: before you close this tab, create a file called state.md in your current project folder. Write three things that are true right now about your site or project. That is the beginning of your memory system — and the beginning of everything else in this series.

This series was researched, drafted, quality-gated, and published by the very agent system it describes — with a human setting direction at every step.

← Part 9: The Economics
Back to Series Index →
```