agents

The architecture fits on a beer mat

The complete chain behind the agent pipeline: an issue board, one small programme on the desk, and the subscription I already had. If you came for an architecture diagram, bring a beer mat.

Since the first post in this series went up, the most common question I get has not been about the agents at all. It has been about infrastructure. What does it run on? Which orchestration framework? People ask it the way you'd ask about someone's home lab, expecting a rack of servers, a message queue, perhaps a small dashboard with tasteful graphs. At a meetup recently someone assumed I was being modest when I said there isn't any of that. I was not being modest. There is my ordinary issue board in Linear, a small programme running on the Mac Studio next to my desk, and a coding agent that works without anyone sitting in front of it. The complete architecture fits on a beer mat, and this post walks through all of it, mostly so you can stop imagining something more impressive.

I promise to keep the plumbing light. If you run a product or a business rather than a terminal, the point of this post is not the commands. The point is what it costs to get here, which turns out to be the interesting number precisely because it is so small.

The chain, front to back

It starts where Part 2 ended: with an issue that can survive a reader who never asks questions. Acceptance criteria you can check, the things I explicitly don't want spelled out, a link to the standing project rules instead of a retelling of them. That issue sits in Linear like any other, and nothing about it hints that a machine will pick it up.

Then I drag a label onto it. That is the entire deployment ceremony.

The small programme on the Mac Studio checks the board every thirty seconds for that label. When it finds one, it claims the issue, sets up a fresh copy of the codebase, and hands the issue to Claude Code, the same coding agent plenty of developers already use as a chat partner, except here nobody is chatting. The agent reads the issue as its brief, builds, runs the tests, and writes up what it did, including the ASSUMPTIONS section where it confesses every decision my specification forced it to invent. The result arrives as a pull request, which for the non-developers among us is software's version of a proposal: here is the change, fully prepared, waiting for someone with judgement to approve it. The write-up lands back on the Linear issue, the little robot in my menu bar goes back to sleep, and at some point I wander past with coffee and find work waiting for me that I did not do.

Notice what is absent. There is no server I administer, no queue, no platform. The watcher on the Mac is the only piece of custom software in the story, and it is glue rather than machinery: read the board, prepare a workspace, start the agent, deliver the result. Everything load-bearing — the reasoning, the version control, the pull request — is done by tools that already existed and a subscription that was already being paid for.

Pull quote: The entire platform is a label, a small programme and a subscription I already had.

Why the machine is on my desk

The obvious question is why this runs on a Mac Studio at all, when every vendor is eager to run agents for you in the cloud. I tried the cloud route first, and the honest answer is waiting time and money, in that order.

A cloud agent, in my early attempts, spent something like a quarter of an hour setting up its environment before it wrote a line of code. The local version has the agent working within about half a minute, because the machine is already on and the codebase is already there. I haven't timed either with a stopwatch, but the difference is not subtle, and it matters more than it sounds. The whole point of Part 2 was small, reviewable issues, and when the unit of work shrinks, startup overhead stops being a rounding error and becomes the main cost.

The money argument is shorter. This runs on the Claude Max subscription, which means an evening of agent runs costs the same as an evening of not running them. I do not think metered billing is wrong, but I noticed what flat pricing did to my behaviour: I stopped rationing. I hand the agent small issues, speculative issues, issues where I suspect the spec is weak and want the ASSUMPTIONS section to prove it. You experiment differently when the meter is not running.

Someone will point out that one small programme on one desk is not production-grade, and they are right. It has no failover and no monitoring worth the name, and when the Mac sleeps, so does the pipeline. In practice that has not bitten me yet, for the unheroic reason that the machine is simply always on, but I won't pretend that's a strategy. If it worries you, the cloud versions of this exact loop exist, and you pay for the peace of mind with that quarter of an hour per issue. For me the trade is easy, because of what the failure mode actually is: when this system breaks, a pull request fails to arrive. Nobody is paged, no customer notices, and the fix is usually me squinting at a log for five minutes. I have run production systems whose failure modes were considerably less relaxing. For one developer feeding one review loop, this is the correct amount of engineering, and adding more would be a hobby pretending to be a requirement.

When this system breaks, a pull request fails to arrive. Nobody is paged.

The advantage of staying small

Keeping the chain this small has a side effect I did not anticipate: every failure is legible. When the very first run in Part 1 produced exactly nothing while every status light was green, it took one evening to find out why, because there was so little in which the answer could hide. A bigger system would have offered me a dozen more interesting places to look, all of them wrong.

The pattern has held since. Every time something goes sideways, the fix turns out not to be new infrastructure but a better sentence: a line added to an issue template, a rule added to the standing project instructions. The system does not get more robust by getting bigger. It gets more robust by the specifications getting better, which by now you will recognise as the running theme of this series wearing a different coat.

If you run a team, this is the part for you

The lesson I would take from this post, if I were reading it as a founder, product owner or agency owner, is not that you should buy a Mac Studio. It is that the entry ticket is now small enough that "we'd need a platform team first" has quietly stopped being true. The chain described above is a competent developer's afternoon, built from parts your organisation almost certainly already pays for. Infrastructure is no longer the moat, and neither is model access, because everyone's agents drink from the same tap.

What that leaves as the constraint is exactly what the last post said it was: whether your issues can survive a literal reader, and whether your team can review the resulting pull requests at the pace they now arrive. If pull requests already sit for three days in your organisation, agents will not fix that. They will queue behind it, and the pile will simply grow faster than it used to.

Infrastructure is no longer the moat. Everyone's agents drink from the same tap.

What's next

Now that the chain is on the table, the next post follows the money. Not because the amount is impressive, but because it isn't: the whole thing runs on a subscription that was already being paid, and a flat price turns out to change how you work more than any feature did. If you have ever caught yourself rationing a good tool because the meter was running, that one is for you.