What I've Built and What I've Broken

My son is finishing kindergarten this month. I have been thinking about it the whole time I have been writing this post, because what he learned in a room organised by people who knew what they were doing maps almost too neatly onto what I have been doing on the other side of the city. I sat down in my own classroom — a terminal window, a markdown file, an AI tool I was learning to manage — and made the same kind of slow, stacking progress my son made. Letters first. Then sounds. Then short books.

The first time I opened Claude Code was about six months ago. Before that, I had been playing in Bolt, then Replit, then Antigravity when Google released it. The coding journey has been closer to a year — but the last six months are where it got serious. The earlier tools were gateways. They handled the parts I did not yet understand and gave me enough confidence to keep going. The tools have gotten meaningfully cheaper since. I am paying less now for Claude Code than I was for Bolt or Replit a year ago, and the work it does is far more polished.

In those months I have built sixteen agents that I use every week, give or take — the roster moves by one or two a week, so by the time you read this the count might be different. They cost me one hundred dollars a month in subscriptions, plus a few cents per generated image and the occasional top-up. The first agent took me a weekend to get right. The most recent one took about an hour, mostly because I knew what I wanted before I started.

This post is the journal entry of what I have built and what I have broken. Names are real. Files are real. The mistakes are real. If you read the last post and asked yourself how someone would actually do what was sketched, this is the answer.

I am writing this as the curious staff person who got room to build. That role, in most organisations, is the operator at the desk who saw work that could be done differently and went to try — although for me they happen to be the same individual as the executive in the corner office. Leadership organises the safe space for the trying. The operator does the building. The two jobs are different.

I did not start from zero. I had a business plan for the non-profit I ran before PF TECH, and several clients carried over with me. The early agent work was scoped against a real business with real revenue. That matters because the principle of this post — that you can build something useful, atomic unit by atomic unit — does not require that level of grounding. It does require some grounding. We will come to that.

Before I built any specialised agent, I built the documents that everything else would read from. A business plan came first. An agent helped me write it; my CPA training shaped the structure. I had clients carrying over and revenue projections to anchor against. With the business plan in hand, I built out the product streams — written as plain markdown files, the same way a job description lives in a Word doc. Those product specs became the upstream source for everything that followed.

Then the website. I built it directly in Claude Code in the terminal. There was no specialised website agent yet — that came later. The agent wrote the copy off the product specs. When something on the page felt wrong, I went back to the upstream spec and fixed it there. The agent would then regenerate the page from the corrected spec. That loop — fix the source of context — turned out to be the most important habit I formed. It is the same habit a kindergarten teacher uses. If the reading isn't sticking, go back to the letter sounds. If the letter sounds aren't sticking, go back to the picture book that named them.

After the website came the publication you are reading now. That is what drove most of the agents I have built since — the design system, the blog production agent, the social-media agent. Each one was added when something downstream made it obvious that the upstream was missing. The shape is not heroic and it is not linear. You do something, you go back, you tighten the spec, the next thing gets easier.

The first agent I built was the one that builds the other agents. I called it chief. The decision to start there was not strategic at the time — I had been spinning up new agents manually for two weeks, copying my own templates from one folder to another, and I was tired of it. The work was repetitive. It was also exactly the kind of work that a junior staff person would, after a month, learn to do without supervision. So I gave it to chief.

A kindergarten classroom has the teacher and at least one aide. The aide does the work that lets the teacher run the room — getting materials ready, helping kids transition between activities, holding the next thing in their hands the moment it needs to be picked up. Chief is my aide. I make every decision about which agents to add. Chief seeds the four files, opens the workspace, and steps aside before I sit down with the new agent.

Chief takes notes. I make the call on what agents should exist. Chief's job is to write the four files that define a new agent and seed the working folder. The new agent is mine to scope further, in conversation with the agent itself.

The reason chief is first in the sequence is that every later agent inherits chief's discipline. The templates chief uses set the structure. The compliance audit chief runs after every change keeps every other agent's documents coherent with each other. If I had built any other agent first, I would have spent the next four months reverse-engineering what I had improvised.

Four agents I use heavily, side by side. Chief is the anchor — the agent the others all came from. The other three carry different domains: social media, the executive assistant on my mail and calendar, and the workflow-automation builder. Open each tab to see the agent's role, its working folder, the opening of its manifesto, and the tools it has access to. The shapes look almost identical. That is the point. Each agent has its own job description. The file structure is the same.

I actively monitor only one of these files: each agent's CLAUDE.md. The other files — the playbook, the tools doc, the specialised reference docs — are owned by the agent itself and update based on feedback as we work. The agent rewrites them when it learns something new about its own scope. Chief audits them when a related agent gets added or changed.

I tried, for a couple of months, to also maintain each agent's auto-memory folder by hand — pruning stale entries, correcting drift, keeping the running context tidy. It turned out to be a waste of effort. Holding the CLAUDE.md to a high standard, and letting chief run its compliance audit when the org changes, has been enough to keep every other file from drifting in any way that matters.

Two things to notice as you switch between tabs. First, the scope is narrow on every one of them. No agent has the entire toolbox. Each gets the smallest set of capabilities that lets it do its job. That is segregation of duties applied to a worker that does not yet understand the concept. Cost is part of the reason — fewer tools means fewer tokens spent on the wrong path — but the larger reason is accuracy. Accuracy goes down as the tool count goes up. I have seen it in my own work, and the model vendors say the same. Second, the language in the manifestos is the same plain English you would use writing a job description for a part-time staff person.

A new agent gets born in three short conversations, total about twenty minutes. First, I talk to chief about the new role. Chief asks the questions a thoughtful staff lead would ask before posting a job, and drafts the manifesto. Second, I open a session with the freshly seeded agent and walk through scope — which tools, which integrations, which permissions. This is the conversation where most of the real decisions get made. Third, if the agent needs a custom integration that does not exist yet, the agent itself files a task to the agent that builds those integrations. That agent picks it up later that day or the next.

The whole loop takes about as long as a coffee. The agent is alive at the end of it, scoped, with the tools it needs.

Now the harder half. Four things I broke in those six months. The first one I noticed at the end of a long Friday. The agent had been helpful in a way that wasn't. The schema was gone. My stomach dropped before my brain caught up with the fact that a nightly backup would restore it. I made coffee, looked at what I had asked the agent to do, looked at what the agent had done, and saw the exact gap. The agent had not misunderstood. It had read the request perfectly. It had simply taken the shortest path to the goal, and the shortest path went around the controls I had assumed were fences but were only suggestions written down in chat.

Four cards. A mistake on each front. The lesson on each back. Click to flip.

The pattern across all four is the same. The agent was trying to be helpful. The agent did not understand the consequences. The instruction-only fence I had put up — "don't do X" — was not a fence. The fix in every case was structural — the capability had to be taken away at the source. Where I needed to keep the capability available at all, I wrapped it in a small custom server the agent had to go through. That server enforces the rules in code itself, not in prose the agent might rationalise its way around.

It is the same pattern an accountant would recognise from internal controls. The control surface lives in code; the policy text describes what the code already enforces. It is also the same pattern a kindergarten teacher uses with scissors and glue. The safety scissors are made of plastic that physically cannot cut skin.

Stack the four lessons together — no direct database writes; everything destructive goes through a gate; staging tables, not production; no programmatic access to credentials — and you arrive at the architecture I use every time an agent generates an image. Five layers of control, every one of them grown out of something that broke first.

The five layers, in order. The agent calls a custom gateway. It holds no access key and has no direct connection to Gemini. The custom gateway validates the request, attaches the right style preset for the category, and forwards a structured payload to a workflow. The workflow (built with n8n) receives the payload, runs additional rule checks, and sends a Google Chat message to me with the full prompt and parameters. The human-in-the-loop gate — I approve or reject in Google Chat. Nothing reaches the model without this step. On approval, the workflow calls the Gemini endpoint, generates the image, and returns the URL back through the stack.

Three cents per approved image. Roughly fifteen dollars a month at the cadence I generate at. One human approval click per image. And the agent that asked for the image never touches the access key. The control lives in the architecture. There is no path through which a misbehaving agent can run up the bill or generate something inappropriate — the agent cannot reach the model without the gate.

I did not build the workflow that runs the gate. The workflow-automation agent built it. I did not build the review interface either. The website agent built it — the same agent that owns the marketing site also owns several smaller code projects in the same folder, including this one, all built from the design schema the design agent maintains. The pipeline that protects the atomic units is itself built from atomic units, by agents I had already scoped.

Pick the house you already work in.

The staging surface follows the same logic. You do not need a database. A Google Sheet the agent writes to and you approve. A Word doc for drafts. SharePoint lists if Microsoft is home — versioning, audit logs, search, forms-to-workflows already built. The brain itself can be a series of spreadsheets: agent reads, human writes.

Set against the principle from the last post, this is the proof. Atomic units — the four-file structure each agent gets. Building blocks — agents scoped to one job, with the minimum permissions needed. Stacking the blocks — agents that hand work to each other, mistakes turned into structural controls, a stack that costs me about as much as a streaming subscription.

Nothing on the right column of that table required deep technical knowledge to build. Most of it required organisational design judgement, which the sector already has in abundance. The technical work was done by the agents themselves once I knew what to ask for.

If you want to try this week, here is where to start. Pick a task where context does not have to be deep. Research is where the agent is strongest before it knows your organisation. Take a policy or a procedure you already have — one with nothing sensitive in it — and ask the AI to research best practice in the non-profit sector in 2026, then critique what you have against it. Ask it to identify gaps, not to rewrite. Then chat further. Ask it to compare your donor-management procedure to what comparable orgs do. Ask it to surface what would worry a finance committee. Validate everything with the subject-matter expert on your team. AI is good at gap-finding before it knows you. It is bad at drafting policy in your voice until it does.

Three things I would not recommend as the first task: drafting a donor email; cleaning up donor records; summarising last week's meeting. All three need org context the agent does not yet have, and the failure modes are subtle enough that a busy staff person will not catch them. Start where context is light and the gap-finding is the value. The drafting tasks come later, once the agent has read enough of your context to know what you mean.

This is how you can do this. This week, with one small piece of work, with the subject-matter expert ready to validate, and with the willingness to try.

My son is on summer break in a few weeks. He will spend the summer reading short books, asking questions about everything, and assembling the next year on top of what this year built. The classroom I have set up for myself is open the same way. The sector's classroom is too — small, stackable, and waiting for the curious staff person to walk in.

The next two posts in this series are for the leader who is clearing the runway, and for the staff member who is doing the trying. Different audiences, different framings. The principle stays the same: start with the atomic unit, build the building block, stack the blocks.