How I built the AHP agent system.

The ten steps

1. 01

   Map how the business actually operates, before building anything

   The first artefact was not code. It was a process map of the whole operation, written with the founder: how the weekly newsletter gets made, how the events pipeline works, how partner sales run. Every activity got one of three colours: automated, AI-assisted, or manual. This map became the ground truth; every later build decision traces back to it. The single most important finding: the founder was the throughput point for everything, so the system had to reduce what flowed through her, not add to it.

   Rule this produced. Never build an agent for a process you have not mapped first.

2. 02

   Decide where everything lives, and write the rule down

   Agents live in the repo, state lives in Notion and Drive, and secrets live with the runtime. No agent keeps private state on one person's laptop. One private GitHub repo holds every agent, workflow and spec; Notion holds the operating databases; Google Drive holds assets; secrets follow the runtime, with a password-manager vault holding the master copy of every key.

   Why this order matters. Every later capability, including letting a non-technical founder deploy changes, only works because this separation exists.

3. 03

   Build agents as folders, to one standard

   Every agent has the same layout: a plain-language job description and rules, a README for humans, inputs the AI never edits, durable knowledge, working context, dated append-only outputs and scratch space. Opening the folder primes the agent; the person then works with it conversationally. The standard carries the hard rules every agent inherits: drafts only, never send; Australian English; the brand system for anything client-facing; one source-of-truth document that wins on any disputed fact; and provenance, meaning everything in an output traces to something in the inputs.

   Build order. Start with the agents carrying the most weekly weight, and only add more once those are earning their keep.

4. 04

   Connect the tools the business already uses

   No tool migration. The agents connect to the systems the business already ran, Notion, Gmail, Google Drive and Sheets, Xero, Shopify, Slack, Beehiiv and Canva, using the Model Context Protocol. Two deliberate choices: connections attach to the surface, not the agent, so which agent can touch which service depends on which workspace is open; and agents read widely but write narrowly, with every write to a live shared system showing the change first.

5. 05

   Build the one fully automated machine: the events pipeline

   Most of the fleet is supervised. One process justified full automation because it is high-volume and low-judgement: event listings. Five workflows on GitHub Actions form a production line: scrape, intake, enrich, image, publish, with the founder approving the queue before anything goes out.

   The human stays in the middle. Each workflow only earns its schedule after repeated clean manual runs. Automation is granted on evidence, not assumed.

6. 06

   Add the scheduled layer, and make the mistake

   Around twenty small scheduled scripts handle recurring checks, each posting its result to Slack so the humans see flags, not silence. For speed, these scripts were set up on an always-on local machine rather than in the repo. It worked, and that was the problem. Months later, a fifth of the operation was running production work that could not be versioned, reviewed or rolled back, and the machine pulling the main branch every few minutes meant any merge deployed instantly with no protection.

   The lesson, now a rule. Everything starts life in the repo, even a five-line script. Convenience infrastructure in week one becomes governance debt by month three.

7. 07

   Design the human operating model

   This is the step that makes the system usable by a non-technical founder, and it is the one most builds skip. Five rules, and nothing else to remember: new task, new window; start every session with one line; know the difference between Work and Build sessions; branches and pull requests are the AI's job, so the founder controls every deployment without touching git; and mid-task ideas go to a backlog, applied in a weekly batch as one reviewed change.

   The fifth rule is the learning loop. Feedback that sounds like a standing rule gets parked, and the same lesson parked twice is definitely a rule. This stops agents rewriting their own instructions unreviewed.

8. 08

   Write the governance so it survives without me

   Four controls, all documented in the repo. Drafts only: no agent sends email or writes to live shared systems without showing the change first. Merge is deploy: nothing reaches production except through a pull request a human reviewed. Secrets discipline: keys never committed, and anything ever pushed is treated as compromised. Archive, never delete: a retired agent moves to an archive path with a one-line reason, and history stays.

9. 09

   Review the fleet on evidence, not affection

   Once the system had run for a while, an audit: sixty days of git activity per agent, a folder audit against the standard, and overlap tests between agents with similar jobs. Every agent got one of four verdicts: keep, optimise, rewrite or retire, and each verdict needing work became one backlog row. The review surfaced real findings, including naming the unversioned scripts from step six as the biggest governance gap.

   Why this step matters. An agent fleet without a retirement process only grows. The review is what keeps it a workforce instead of a museum.

10. 10

    Keep an honest list of what is unfinished

    Open at the time of writing: the Slack trigger surface that lets the founder fire agents from her phone is built but not deployed; the legacy scheduled scripts are still migrating into version control; and the pipeline schedules go live one at a time as each earns trust. All three are on the prioritised backlog, in dependency order, with the blockers named.

    The point. A system that claims to be finished is a system nobody is reviewing.