Part 1 of 3. The honest story of an autonomous agent ecosystem, built solo, on an 8GB box that used to be someone's office desktop. What it is, why it exists, and how nine AI agents got stood up in fourteen minutes. They did not, really. Keep reading.
I am a tinkerer. Always have been. Give me a constraint and a weekend and I will build something I did not strictly need, just to see if it works.
This is the story of the biggest thing I have built that way. It is an autonomous agent ecosystem. Nine AI agents that run the back office of my consultancy. They research the market, draft my content, watch my inbox, pitch me product ideas, and supervise each other, mostly while I sleep. The whole thing runs on a refurbished HP mini PC with 8GB of RAM that costs me somewhere between five and ten dollars a month to operate.
I want to tell you how it actually works. Not the glossy version. The real one, with the stack named, the failures dated, and the parts that hurt left in. Because the composable and AI world right now is drowning in agent demos and architecture diagrams, and starving for someone to just show the thing running and say here is what broke.
This is part one of three. This part is the what and the why and the build. Part two is the Monday everything silently fell apart. Part three is the strangest agent of all, the one running a local AI model on the CPU of that little box, and the week I realized I had built something Anthropic was about to ship.
Let us start with why a person does this to themselves.
One income source is a single point of failure
I run Fidget Labs solo. Right now, one contract pays the bills. It is good work with people I respect, but it is one contract. Any engineer who has ever drawn a system diagram knows what one of anything is. It is a single point of failure. The whole node is one bad day away from taking everything down with it.
You do not architect production systems that way. You add redundancy. You build the thing that keeps the lights on when the primary fails. So the question I asked myself was simple. If I would never ship a client a system with a single point of failure, why am I running my own business as one?
The agents are my answer. They are not a moonshot and they are not a product I am selling you. They are infrastructure. They exist to do the work that a marketing person, a research analyst, and an operations assistant would do at a company with more than one employee, so that the business can grow without my time being the bottleneck on every single task. The goal is boring and concrete. Buy back my own hours. Build something that compounds while I am doing other things.
That premise shaped every technical decision that followed. Hold onto it, because it explains the constraints, and the constraints are the whole story.
The shape of it
Everything lives on one machine. An HP EliteDesk 800 G4, the kind of small-form-factor desktop that offices buy by the pallet and retire after three years. Intel i5, 8GB of RAM, a 256GB SSD. It sits on a shelf and never sleeps.
The stack is deliberately, almost aggressively boring:
- VoltAgent, an open-source TypeScript framework for building agents. MIT licensed. It gives me the agent runtime and the structure. Everything else I built on top.
- PM2 as the process manager, the thing that keeps the system running and restarts it when it falls over.
- SQLite for state. A single file on disk. No database server.
- Markdown files for the agents' long-term memory. Literally a folder of text files.
- Slack as the surface where every agent talks to me and I talk back.
There is a hard rule written into the project spec: do not install Docker, do not install Redis, no external queue, no cloud database. It has to run on 8GB forever. Not because I could not spin up infrastructure. Because the discipline of not letting myself is what keeps the thing cheap, simple, and mine. When you cannot reach for a managed queue, you are forced to understand what you actually need, which is almost always less than you think.
The agents run on Claude. The reasoning-heavy ones use Sonnet. The cheap classification work runs on Haiku, because asking a frontier model to sort email by category is like hiring a surgeon to open your mail. And the strangest agent of all runs a local model directly on the mini PC's CPU, which is a whole story I am saving for part three.
Total model spend is five to ten dollars a month. That number surprises people. It is low because the agents only call a model when reasoning is actually required. All the data gathering, the fetching, the checking, the routing, is plain TypeScript hitting APIs. No model involved. The expensive part only fires when there is genuine thinking to be done. That single principle, use the model only where intelligence is required, is most of why this is affordable.
The cast
The roster grew over two months. It started as five agents and is nine today. Here is who is in the building and what each one actually does.
The Marketer takes a published Focal Point article and turns it into a distribution plan across all my channels. But it is not a megaphone that blasts the same text everywhere. It is a copy editor that has learned my voice from a corpus of my own writing, and it writes a different version for each platform. There is a wall built into its code that matters a great deal to me: it learns voice only from things I have actually written. Articles I admire from other people can influence what topics it suggests. They can never influence how it sounds. That wall is absolute, and part three will explain why I had to enforce it twice.
The Editor is my research analyst. It watches MACH vendor blogs, a few subreddits, Hacker News, and the engagement on my own posts. Every Monday it hands me five or six article topics, each with a draft outline. It is the reason I never stare at a blank page wondering what to write.
The Scout is my market analyst. It runs two scans. One tracks the composable and AI product landscape, with price history stored in SQLite so it can tell me when something shifts. The other tracks the queer gaming niche for my YouTube channel. It files a combined report every Wednesday.
The Supervisor does the weekly synthesis. It reads every other agent's output and connects dots that none of them can see alone, then posts a strategy brief. It is the closest thing the system has to a chief of staff.
The Entrepreneur is the idea machine. Every Thursday it pitches me digital products I could build once and then largely walk away from. This agent changed more than any other over the two months, and how it changed is genuinely instructive, so I am giving it its own section below.
Ops handles email and calendar. It polls two inboxes, sorts what matters from what does not, and drafts replies for my approval. It never sends anything on its own. It is the most safety-railed agent in the suite, and after part two you will understand exactly why.
The Curator is a lightweight agent that watches one Slack channel for links and documents I drop in, pulls the useful content out, and files it for the other agents. It runs on Haiku because the job does not need deep reasoning.
The Librarian is the memory keeper. It indexes the entire history of everything the agents have done, catches duplicate ideas, and flags stale information. It has two modes. One answers questions live when I ask them. The other runs every night and tidies the whole system's memory while nothing else is happening. That nightly job is called dreaming, and it is a bigger deal than it sounds. Part three again.
The Director is the newest and the strangest. It runs a local AI model on the mini PC itself, watches the whole suite, and drafts improvements to the system one at a time. It is the only agent that can write code, which makes it the most heavily guardrailed thing I have ever built. It earns its own article.
Nine agents. One little box. Now let me tell you about the fourteen minutes, because the honest version of that story is more interesting than the myth.
The fourteen-minute build that took weeks
Here is a thing that sounds absurd and is technically true. The skeleton of this entire system was committed to git in fourteen minutes and five seconds. The commit log proves it: ten commits, timestamped 18:43:39 to 18:57:04 on an evening in mid-April. Phase one, scaffold. Phase two, the shared memory. Phase three, the scheduler. Then one agent after another, a commit each, about a minute apart. Phase ten, verification passed. Fourteen minutes.
If I let you believe that was fourteen minutes of inspired typing, I would be lying to you, and lying in the specific way that makes AI content useless. So here is what actually happened.
Before any of those commits, I wrote a brief. It was 827 lines long. It specified the stack, the exact order of the build phases, the precise commit message for each phase, what to do when a phase failed (skip it, note it, do not block the build), and the hard constraints about no Docker and no Redis. That brief was the work. Writing it, thinking through the architecture, deciding the sequence, making the tradeoffs, that took real time and real experience. Twenty years of it, arguably.
The fourteen minutes was Claude Code executing that plan, committing each phase as it went, with the dependencies already installed before the clock started. The plan was the engineering. The agent was a very fast pair of hands.
I think this is the most honest and useful thing I can tell a fellow builder about working with AI agents in 2026. The speed is real. It is genuinely remarkable that a well-specified plan executes in minutes now. But the speed is downstream of the thinking. The agent did not design my system. I designed it, wrote it down with enough precision that it could not be misinterpreted, and the agent ran the play. The quality of what you get out is capped entirely by the quality of the plan you put in. Garbage brief, garbage system, delivered very quickly.
And then, of course, the fourteen-minute skeleton met the real world. The verification that passed at 18:57 verified that the thing booted. It did not verify that nine agents would coordinate correctly, that a scheduler would survive a long-running process, that an email agent would know the difference between a real message and a calendar notification, or that any of it would still be standing after 46 hours of uptime.
It would not all be standing. Two days later, quietly, several pieces of it fell over at once, and I did not find out for a day and a half.
That is part two.
The Entrepreneur, and why honesty beat enthusiasm
Before I close, I want to show you one agent's evolution in detail, because it is the clearest example of how this system got better by getting more honest.
The Entrepreneur started life as a hungry pitch machine. Shark Tank energy. Every Thursday it threw one to three passive-income ideas at me, scored each on a single "can you build it and walk away" number, and anything scoring seven or higher made the cut. It was fun. It was also mostly noise. The single score was too crude, and the agent kept pitching the same flavors of idea dressed in different clothes.
So I rebuilt it, and the rebuild was all about adding honest friction. The single score became a four-part gate, and a candidate now has to pass all four or it gets dropped on the floor:
- Build effort. Has to be a real one-off build with a finish line. Complexity is fine. Even a multi-week build is fine. It only fails if the work never actually ends.
- Maintenance load. Near-zero ongoing hours. This is the dominant filter, and it kills most ideas. Anything that needs constant moderation, payment babysitting, or regulatory tracking fails here.
- Demand signal. Cheap evidence somebody actually wants it before I build a thing nobody asked for.
- Distribution fit. Can I reach people through channels I already own, without becoming a full-time salesperson.
The most important change was the last one I made. The Entrepreneur no longer brainstorms in a vacuum. It reasons from an inventory of what I have actually built and can build again. Real projects as reference points. It is not allowed to pitch me a greenfield fantasy from nothing. Every idea has to connect to a capability I have already demonstrated.
The lesson there is not really about agents. It is about ideas. An idea machine with no constraints produces enthusiasm. An idea machine that has to pass four honest gates and reason from your actual track record produces things you might really build. The friction is the feature.
What this part was, and what comes next
So that is the system. Nine agents, one refurbished box, a boring stack held together with discipline, built fast on top of a plan that was slow to write, all in service of one idea: do not run your business as a single point of failure.
I have told you what it is and why it exists and left in the honest mechanics of how it came together. What I have not told you yet is what happened when it broke.
In part two, I will walk you through the Monday morning I discovered that several of my agents had been silently failing for a day and a half, that one of them had been running on outdated code for 46 hours, and that the whole thing taught me more about multi-agent systems than any amount of smooth operation ever could. It is the most useful failure I have had in years, and I wrote all of it down.
Where Does Your Organization Stand?
I build these systems for myself the same way I help organizations build theirs. Deliberately, on honest constraints, with the failures treated as the curriculum.
Our MACH and AI Readiness Assessment benchmarks your organization against enterprise leaders from the MACH Alliance 2026 Report. Free, about five minutes, and you walk away with a personalized read on where you stand on composable maturity and AI readiness.
Curious what a lean, deliberate agent strategy could look like for your team? Let's talk. Fidget Labs helps organizations cut through the AI hype and build systems that fit the problem.
