How I built the
AHP agent system.

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.

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.

In practice

• One private GitHub repo holds every agent, workflow and spec. Version control is the memory and the audit trail.
• Notion holds the operating databases: the CRM, the events approval queue, the sponsorship calendar, the deliverables tracker.
• Google Drive holds assets: images, proposals, documents.
• Secrets follow the runtime. GitHub repo secrets for scheduled workflows, a local environment file for supervised sessions, nothing ever committed. A password-manager vault holds the master copy of every key.

Every agent, the same layout

Opening the folder in the development environment primes the agent. The person then works with it conversationally.

The standard also 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, no invented sources.

No tool migration. The agents connect to the systems the business already ran: Notion, Gmail, Google Drive and Sheets, Xero, Shopify, Slack, Beehiiv, Canva, using the Model Context Protocol.

Two deliberate choices

• Connections attach to the surface, not the agent. Which agent can touch which service depends on which workspace is open. The bookkeeping agent has Xero; the newsletter agent does not.
• Read widely, write narrowly. Agents read from everywhere they need. Writing to live shared systems always shows the change first.

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.

1. Scrape. Discover events from source sites into a Notion approval queue.
2. Intake. Process paid and free event submissions into the same queue.
3. Enrich. AI fills the gaps on each queued event.
4. Image. Guarantee every event has hosted imagery.
5. Publish. Push approved events to the Shopify website, report the result to Slack.

Around twenty small scheduled scripts handle recurring checks: content reminders and ideas, partner hygiene and payment reconciliation, event staleness checks, finance reports. Each posts its result to Slack, so the humans see flags, not silence.

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.

1. New task, new window. One session does one job.
2. Start every session with one line. Work: agent. task to use an agent, Build: agent. change to change one.
3. Know the difference. Work produces things for customers and partners. Build changes how an agent behaves.
4. Branches and pull requests are the AI's job. In a Build session, the AI branches, commits and opens the pull request. The founder's only job is to read it on GitHub and press merge. She controls every deployment without ever touching git.
5. Mid-task ideas go to a backlog, not the current chat. "The agent should always do X" gets parked, then applied in a weekly batch as one reviewed change.

Four controls, all documented in the repo

• Drafts only. No agent sends email or writes to live shared systems without showing the change first. The human owns the send button.
• Merge is deploy. Nothing reaches production except through a pull request a human reviewed.
• Secrets discipline. Keys never committed; anything ever pushed is treated as compromised, rotated first and scrubbed second.
• Archive, never delete. A retired agent moves to an archive path with a one-line reason. History stays.

Once the system had run for a while, I audited it: 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.

Each verdict needing work became one backlog row. The review surfaced real findings: the most active folder in the repo was mislabelled and needed restructuring, the least-used agent went on a usage watch rather than being merged prematurely, and the unversioned scripts from step 6 were named the biggest governance gap.

• The Slack trigger surface, which lets the founder fire agents from her phone, is built but not deployed.
• The legacy scheduled scripts are still migrating into version control.
• 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.