Build your own AI system

The pattern behind your portfolio works for any job you hand to an agent more than once. Here are six moves, four beliefs that get in the way, one worked example outside web design, and a card to keep.

Why a system beats a bigger model

Before the workshop, I tested the checkpoint, the catch-up after a Block, with a small model. It had only the template, AGENTS.md and the skills. A script played the participant, with every reply written in advance. Two runs, for two different Blocks, in up to nine rounds. Its mistakes in the first rounds:

Each fix was a sentence in a file, not a bigger model. In the ninth round, both runs passed.

Six moves

The first five are the five parts from How it is built; the sixth is testing them.

1. Write the rules down once

Put what is true in every chat into one rules file, such as AGENTS.md: the order of the jobs, what the agent must never do, how it reports to you. In the workshop: the Roles in their order, one Role per chat, every change read back.

2. Give each job its own skill

Each job gets a skill with a description that says when to use it. Keep the skill short, and name the files it may change. In the workshop, the Analyst writes exactly two files, plus your photo through a tool, and touches nothing else. Write your own skill shows how, in five steps.

3. Let programs check what programs can check

A model's "looks fine" is a guess. Every question with a yes-or-no answer goes into a tool the agent runs: a schema check, a contrast check, a load-time measurement. In the workshop, the Analyst ran check-content.mjs until it said "ready".

4. Pass the work through files

Each job ends in a file, and the next job starts from that file in a fresh chat. The chat stays short, and nothing is lost when it ends. In the workshop: the spec, the content file and the brief.

5. Stay at the gates, and keep a way back

Let the agent ask before it runs commands, read every change before you accept it, and make going back cheap. In the workshop: Allow running this command?, Accept all, and the checkpoint, which resets the page to a known state. At home: Git commits and branches.

6. Test with a small model

Before anyone depends on your skills, write the person's replies first, in a file. Then start a fresh chat on the smallest model you can, with only your rules and skills, paste the replies one at a time, and note where it goes wrong. Change the instructions, not the model, and run it again. Instructions a small model can follow are clear.

Four beliefs that get in the way

"A bigger model makes all this unnecessary."
A bigger model guesses better, but it still guesses. Rules, skills and tools make the result the same on every run, and you can test them. A bigger model also uses up your quota faster.
"The agent remembers what I told it yesterday."
A new chat starts empty. What must last goes into a file the next chat reads, like the spec and the brief.
"More context gives better answers."
A long chat or a pile of files crowds out what matters, and the agent starts to mix things up. That is Common mistake 3: give each job only what it needs.
"One good prompt can describe the whole project."
Without a plan, the agent guesses your content, your audience and your look. That is Common mistake 1: a spec first, then small steps.

Worked example: a job-application assistant

Your content file from today already has your experience, your projects and your links. The same pattern turns it into an assistant that answers job ads, with you at every gate:

job-assistant/
├── AGENTS.md                   the rules for every chat
├── .agents/skills/
│   ├── researcher/SKILL.md     reads a job ad, writes docs/job.md
│   ├── writer/SKILL.md         writes docs/letter.md from content.json and docs/job.md
│   └── checker/SKILL.md        checks the letter against content.json
├── tools/check-claims.mjs      checks the letter's source marks against content.json
├── content.json                your content file from the workshop
└── docs/                       job.md, letter.md and fixes.md, the files that remember
  1. Rules. AGENTS.md says: use only facts from content.json, never invent experience, one job per chat, and read every letter back before it is accepted.
  2. Skills. Three jobs, three skills. The Researcher's description ends: "Use when the person pastes a job ad."
  3. Tool. The Writer marks every claim with the field of content.json it comes from, such as [projects.2]. check-claims.mjs answers the yes-or-no question: it lists every sentence without a mark and every mark that content.json does not have. The Checker writes them into docs/fixes.md, and the Writer starts its next chat from that file.
  4. Files. docs/job.md carries the ad's facts from the Researcher to the Writer, docs/letter.md carries the draft to the Checker, and docs/fixes.md carries the fixes back.
  5. Gates. You read the letter before it goes anywhere. The agent never sends an email itself.
  6. Test. Run the three skills on a small model with three real job ads, and fix the instructions until every run passes.

Start with the thinnest path, ad in and letter out, and add the Checker once that works. That is the tracer bullet from How I built it.

Reference card

Check yourself

Five questions on this chapter. Pick one answer each, then check them.

Why does every Role start in a fresh chat without losing your work?
Who decides whether your content file matches its schema?
How does the agent know which skill to use for "Start the Analyst step."?
In the test runs, a small model started the next Role in the same chat. What was the fix?
You build a job-application assistant. Where does the rule "never invent experience" go?