I Built a Four-Agent AI Team on a Used 2016 Laptop. Run 24/7 as a Server

The maximalist version is seductive because it looks like capability. More agents, more departments, more tokens, more of everything. My instinct went the other way, and not because I could not afford the big version. I went lean because most of those 72 seats would sit idle for me. I do not run a design department. I do not have nine kinds of work waiting in a queue. An org chart that big, for one operator, is mostly scaffolding around empty rooms.

So the question I asked was not "how do I build the impressive version". It was "what is the smallest team that can actually do my work". The honest answer turned out to be four, and the honest cost turned out to be a discipline problem more than a hardware problem. Credit where it is due: the @lucaxyzz post put the idea in front of me. I just took it in a smaller direction.

Let me be precise about the seat I am sitting in, because it matters for everything that follows. I engineer my own SEO system instead of grinding it out by hand. I did not switch professions. I learned to build the thing my work needed, and I stayed an SEO the whole time.

Here is why owning a team of AI agents actually makes sense for someone like me now, and it is not the reason most people assume. For years the hard part of any task was execution. Doing the audit, writing the draft, shipping the change. That barrier is largely gone. An agent does the reps faster than I can, and it does not get bored on page 40 of a site audit.

None of this was the plan. The plan was small and boring: I had a personal assistant bot running on the Claude Agent SDK, and I wanted to add a second door to it, a way to talk to the same brain from Lark instead of only from one messaging app. That was the entire scope. Add a door.

Then I sat down for one long design conversation to figure out the door, and the scope quietly detonated. A dozen or more turns in, "add a second door" had become "build a whole agency". Along the way I verified three things against the official docs rather than my own assumptions: that the SDK can run several genuinely separate agents as independent sessions, that Lark has a real native handoff where one bot can mention and wake another, and that I could store files through the platform's own Drive API. Those three facts turned a daydream into a plan.

The part I am proudest of is what that session did not produce: a mature design, written down, and zero lines of code. Nothing got built. I set a gate for myself: nothing ships until I register the app and explicitly say go. Restraint at the design stage is cheap and restraint after you have written 2,000 lines is expensive, so I paid the cheap version.

The first thing that ever worked was almost stupidly small. Over the WebSocket connection to Lark, I sent a "ping" and got a "pong" back on the first try, success code and all. That should not feel emotional and yet it did, because it meant the whole transport layer was real: authentication, the live connection, receiving an event, sending a reply, none of it faked.

The moment that actually got me was "77". I had put a secret number in the file-based brain, then asked the first live agent, inside a Lark thread, "what is my secret number?" It answered "77". It had read my brain and answered me live. Right after that I watched two bots hand work to each other in the open, one posting a message with a real mention tag and the second one waking up, receiving it as a message from another bot, and replying in the same group. That was the proof the whole idea rested on. Not a diagram of agents talking to each other. Agents actually talking to each other, in a thread I could watch.

I could have spun up ten agents that afternoon. Instead I made myself earn each one, grounded in real work. I looked at the scope of an actual SEO client project, and it fanned out into three distinct crafts: the search and audit work, the content work, and the engineering to ship it. That fan-out was my proof that I needed three heads, not one, and not ten.

So the team is four. Larry orchestrates: he is the single front door, he takes a request, breaks it into tasks, and hands off to the right specialist. He does not do craft work and he is not the SEO brain. Below him sit three heads of craft: Alison does SEO, Satya does content, Durov builds the app and the code and then ships it. That is the whole roster.

The more revealing list is the one I refused to hire. No paid-ads agent, no social media agent, no separate head of design, no standalone analyst. Not because those are not real jobs, but because for my actual workload they would have had almost nothing to do. The rule I set was "earn each agent", and an agent earns its seat by having real, recurring work waiting for it. Empty seats are not capability. They are overhead you have to maintain.

The shape is simple to describe and that is the point. One human operator, one orchestrator, three craft heads. I set direction, I face the client, I validate the results. Larry routes. Alison, Satya, and Durov do the work, and when one needs a heavy lift, it spins up a temporary sub-agent in a fresh context so the main conversation stays light.

They are genuinely separate agents, not one bot wearing four costumes. Each has its own identity in Lark, its own persistent session, and its own budget. What they share is knowledge: one brain made of plain markdown files. Separate personalities, separate sessions, one shared memory.

Two choices hold it together. First, handoff happens in the open, inside a Lark thread. When I ask Larry something outside his lane, he mentions the right head in the same thread, that head does the work and replies, and the answer flows back to me in one place. Second, files are the source of truth and there is a human in every cycle. Every agent-to-agent loop stops at me, and for anything big a head has to post a plan and wait for my approval before a single thing executes. Above all of it sits a written constitution that I own. The agents can draft an amendment as text, but only I can change the actual document, and only I can add a new agent.

Here is one real job, start to finish, with the client details stripped out because they belong to the client. The request was a site-wide cleanup of meta titles and descriptions. Alison took it first. She audited every page herself, reading the raw rendered HTML rather than paying for an expensive crawler, and assembled a prioritized backlog of findings plus a direction for keywords. Then she handed off to Satya. Satya rewrote the meta copy for the priority pages in the brand's own voice, review-only, and sent it to me. I read it and approved it.

From there Durov implemented it, first to staging and then to production, without ever opening the page editor by hand, and then verified the result live by reading the raw HTML again. Everything passed, the visible page content stayed byte-for-byte identical, nothing broke. Alison closed the item, live in production. Through the whole relay, Larry logged every step with a date and a person responsible. The thing to notice is where I was in that chain. I was not typing meta descriptions. I was reading Satya's draft and deciding whether it was right. Execution ran without me. Verification did not.

If I only tell you the parts that worked, I am selling you the same screenshot I was skeptical of. So here is the honest ledger.

Now the fact I like most, because it is the one nobody can argue with. All of this runs on a budget laptop from 2016. Two cores. Eleven gigabytes of RAM, of which maybe seven are usable once the operating system takes its share. No dedicated GPU, integrated graphics only. It cannot run a modern AI model locally, it would choke on all but the tiniest quantized models, and it would struggle with a current video game.

The screenshot that started this had 72 agents and a hundred million tokens a day. My version has four agents and an old laptop. I do not think mine is impressive in the way that one is, and that is the point I want to leave you with.

Lean beats big when the intelligence is not local and the discipline is the design. When the models live in the cloud, your local machine stops being the constraint, and the real constraint becomes how well you have organized the work and how honestly you keep a human in the loop. A bigger rig would not have made my four agents better, and more agents would not have earned their seats. What made the thing work was restraint, plain files, a human in every cycle, and a constitution that sits above the agents.

And under all of it is the shift I keep coming back to. The barrier used to be execution, and execution is now cheap. What is left for the human is not typing faster. It is asking the better question, and verifying the answer harder, especially when the answer is confident.