A five-minute check-in on my AI agent company – from the football sideline

This is a follow-up to imfund: two people and an entire company of AI agents.

Saturday morning. Sun, blue sky and my daughter's team warming up on the artificial grass. I was there to watch the match, with a coffee in my hand and my phone in my pocket.

Meanwhile, back home, a Linux server kept the work going without me.

What has changed since last time

In the last post I described how imfund is organised: two people on the board and a company of AI agents in Paperclip, each with a manager, a job description, a schedule and a budget. This time I want to show what that looks like on an ordinary Saturday.

Since then the company has grown from 16 to 19 agents: 11 in the build loop, 6 on demand and 2 paused until the roadmap reaches their work. Each one has a manager and runs on either Claude Code or Codex.

See the latest setup – every agent, how a task moves and every job description →

Two things are new.

1. It runs on its own. Paperclip now runs on my Ubuntu server at home. The agents wake on events: when a card is approved, the Chief of Staff wakes within seconds and hands it to the Architect; when a task is finished, the next agent in the chain is woken; a comment wakes the agent it is addressed to. A small recovery script runs every 15 minutes and restarts any agent run that got stuck or lost along the way. The agents pick up their cards, create branches, write code, run the checks and open pull requests. I don't need to be there for any of it.

2. I can talk to it from my phone. I created a Telegram bot with BotFather and connected it to Paperclip. The Chief of Staff now has its own Telegram account.

A quick check-in during the first half

At 10:46, during a break in play, I took out my phone and sent a single message:

Please give me a general status update on what agents are working on right now.

A minute later the answer came back:

The Engine Engineer was building a way for an administrator to upload and check a sample statement before it is imported. The Console Engineer was working on comparing portfolio and series values against the fund administrator. The Release Engineer was making sure that database changes on a branch stay away from the shared database. Every item linked to its card, and behind every card was a live agent run.

That was the whole interaction – five minutes at most. No laptop, no VPN, no dashboard. A question in plain language, an answer in plain language, and the phone went back in my pocket. Everything was moving, nothing needed me, so I went back to watching the game.

What I can do from Telegram

The point isn't to work from the sideline. It's to be able to check in quickly, without opening a laptop. From the chat I can:

• Ask for status – what's running, what's blocked and what's finished.
• See open cards – the board grouped by status, with the most recently finished work on top.
• Read a whole card – /conversation IMF-1073 gives me the full description and every comment, oldest first.
• Create a card – /create adds a new task to the board, labelled so everyone can see it came from me via Telegram, and puts it in Triage.
• Send a photo – a screenshot of a bug, for example, is attached to the conversation so the Chief of Staff can look at it.
• Ask the Chief of Staff to work on something – and have a back-and-forth about it, with the conversation remembered between messages.

The guardrails

Giving an AI agent a phone number sounds risky, so the same governance thinking from the first post applies here:

• Only I can talk to it. The bot answers one Telegram user ID in one group. Everyone else is ignored.
• The token is a secret. The bot's token is stored as a secret in Paperclip and never ends up in an agent's context.
• Talking isn't the same as doing. The Chief of Staff can answer questions freely, but new implementation work goes through Triage first. If I only ask a question, it says explicitly that it hasn't started or delegated anything.
• The agents merge – but only through a strict gate. Mauricio and I decide what gets built. Once a card is approved, the agents take it all the way to production themselves, including the merge. That's only safe because of the review chain below.
• The agents can't change their own rules. Their instructions live in a separate repository that they have no write access to.

The road to production

Letting agents merge their own code sounds bold. In practice, every change has to pass a long chain of checks, and every link in the chain is a different agent:

1. Evidence before review. The Architect has to show evidence for every acceptance criterion before the first review. A change that touches what a user sees is tested in a real browser by the QA & Test Engineer, with screenshots. A change to a financial number has to pass golden test cases built from examples Mauricio has accepted, checked by the Financial QA Engineer.
2. Four required CI checks. Backend linting, type checks and unit tests; integration tests against a real PostgreSQL database; the console's lint, type check, build and database tests; and a check of the documentation. All four must be green.
3. An independent code review. The Code Reviewer – an agent that didn't write the code and doesn't report to the chain that did – looks for bugs, broken rules and missing tests. It may only approve the latest commit, and any new push cancels its approval.
4. A second, separate review for access and data. If a change touches sign-in, roles, client data, exports, AI prompts or secrets, the Authorization Reviewer checks it too, independently of the Code Reviewer. A client's data must never reach another client.
5. GitHub enforces the rules – with no exceptions. The branch must be up to date with master, every review thread resolved and the approval given on the last push. Not even I can bypass it.
6. One release at a time. The Release Engineer checks every gate again, plus the deploy notes for any manual step, and only then merges – one pull request at a time.
7. Checks in production. The exact commit that passed CI is deployed to the backend, the background worker and the console. The Release Engineer watches every deploy and smoke-tests the console. If something fails, the Platform & Reliability Engineer diagnoses it and can roll back; a code fault is reverted through a new, reviewed pull request. Only if production stays broken does it reach the Chief of Staff – and, if needed, me.

So no human clicks "merge". But no change reaches production without passing at least three different agents – and up to six – four automated checks and a rulebook that nobody can bypass.

The final score

After the match I had a quick look at GitHub on my phone. It showed seven pull requests merged over the previous few hours: statement import with preview and deduplication, portfolio reconciliation, a fix for database changes on branches, stalled worker jobs, a test fixture for broker corrections, market calendar handling and a PDF font fix. All with approved reviews and green checks.

And on the pitch? They won 5–2. ⚽

I didn't miss a single goal.

What I've learned

The interesting change isn't that the agents write code. It's that the work keeps moving when I'm not there – and that I don't have to wonder how it's going. A short status update on my phone is enough to know that nothing is stuck. The real work – setting priorities and reviewing what comes back – I still do at a desk, when I choose to.

That only works because the governance is in place: clear ownership, cards that only humans let out of Triage, a review chain no one can bypass, and a trail of what every agent has done. It's the same principle I work with in master data and data migration – when the rules and the traceability are there, you can step away from the keyboard with peace of mind.

There's still more to do. I haven't yet tested how well the Chief of Staff delegates new work all the way from Telegram, and Mauricio should get access to the bot too. But a five-minute check-in and then full attention on my daughter's match – that's exactly how I want it to work.

Curious how AI agents could work in your own business – with the right governance from the start? Get in touch.