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

Someone I follow posted a screenshot of their AI agency and I stared at it longer than I want to admit. Seventy-two agents. Nine departments. A chief strategist at the top, an orchestrator below that, every agent wired to a specific model. The creator, an account named @lucaxyzz, mentioned burning through roughly 100 million tokens in a single day. It was genuinely impressive. It was also, for me, a used car lot next to the sensible sedan I actually needed.

Because I am an SEO. What I have is a second-hand laptop from 2016 and a lot of repetitive work I was tired of doing by hand. So I did the opposite of what that screenshot suggested. I built four agents. On the old laptop. On purpose. And it never sleeps. The laptop runs 24/7 as an always-on server, so all four agents stay live and I can reach any of them anytime, anywhere, from any device, straight through Lark. This is the story of what that actually took, including the parts that broke.

The post that started it

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. Affording the big version was never the issue: 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.

I am an SEO, and the job just changed

Let me be precise about the seat I am sitting in, because it matters for everything that follows. I am an SEO and AEO/GEO specialist who also builds the websites himself. I did not switch professions to build this. I picked up the building side because the work needed it, and I stayed in the same seat 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.

What is left is verification. My job shifted from doing the work to checking the work: knowing which question to ask in the first place, rejecting an answer that sounds confident but is wrong, and judging whether the output actually fits the context it is going into. Daniel Cheung wrote a piece called "Why AI Rewards Critical Thinking and Imagination" that put this better than I could, and I am borrowing the frame, not claiming it. The short version: when execution gets cheap, the human's edge moves to judgment. A team of agents is worth owning precisely because I set the direction and verify the output, and they do the reps. Take away the verification and a team turns into a very fast way to be confidently wrong at scale.

From one bot to a whole agency

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 number that got me: 77

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: agents actually talking to each other in a thread I could watch, live, not a diagram of it.

The roster I earned, not the one I could afford

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, all real jobs, just jobs with almost nothing to do against my actual workload. The rule I set was "earn each agent", and a seat only exists where there is real, recurring work waiting for it. An empty seat is just overhead you still have to maintain.

How it runs now

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.

Watch the team actually work

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: reading Satya's draft and deciding whether it was right, while the actual typing of meta descriptions happened without me. Execution ran without me. Verification did not.

What actually went wrong

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.

And this is where the verification through-line comes back, because it is the deepest lesson of the whole project. The most dangerous moment is not when an agent fails loudly. A loud failure is easy. The dangerous moment is when an agent is confident and wrong. More than once an agent flatly refused to do something it was perfectly capable of, insisting it could not read a certain file because "there is no connector for that", when in fact it could. If I had taken that confident refusal at face value, I would have built around a limit that did not exist. My job in that moment was to not believe it. That is the work now: knowing when the machine is wrong, more than doing the task itself. If you want the technical companion to this, I wrote about engineering content specifically so answer engines read it correctly in "How to Become the Answer: Engineering SEO for AI Overviews", and the same discipline applies: trust the raw signal, verify the confident claim.

The machine that cannot run a modern game

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.

• 2 coresdual-core CPU
• 11 GB RAM~7 usable after the OS
• No dedicated GPUintegrated graphics only
• 2016 budget laptopcannot run a modern game
• Always-on hostthe thinking happens in the cloud

It runs a four-agent AI agency anyway. That is not a contradiction once you see what the agency actually is. The intelligence is not local. The laptop is just an always-on host, and the thinking happens through the Agent SDK talking to the models over a subscription. The agency is orchestration plus plain files plus a subscription, not local compute. The old laptop only has to stay awake and keep the connection open, and for that it is more than enough.

There is also a plain reason it is a second laptop and not my main one. My primary machine is a company asset, and I keep a hard rule that personal and venture data does not live as active files on a company device. So the whole agency lives on a separate, personal, second-hand machine. Just a boundary I decided to keep.

The cost story fits the same shape. I built it to add zero extra spend. It runs inside a subscription I already pay for, and when usage hits the cap the system stops until it resets rather than quietly billing me more. The infrastructure around it is free or self-hosted: the services that keep it running, the private remote access, the connection that lets a laptop behind a home router work with no public address, and an automatic hourly backup to a private repo. All plain markdown, so nothing is ever locked in.

Why lean beats big

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.

Skip the department. What you actually need is to know which questions are worth asking, and to be willing to tell a very fast, very confident machine that it is wrong.That, more than the laptop, is the whole trick.