DCYFR Labs is one person: me. No team, no roster, no payroll.
Instead there is a private swarm of specialized AI agents, a written control plane, and an autonomous daemon. That system lets a solo studio operate like more than one person, running cheap enough to leave on.
This is the honest version of the "AI agent team" story. I'll tell you what works, and (the part that matters most) exactly where it stops scaling. The temptation is to dress a swarm up as a company: name the agents, give them job titles, talk about "the team." I'm not doing that, and this post is partly about why.
Why I Say "I," Not "We"
When you run a studio on AI agents, there's a fork. One path: present the swarm as a team. Name them, give them personalities, build a Slack org chart. It demos well and looks like fifteen people. The other path: call it what it is. Tools I built and operate. Say "I."
I take the second path, not out of modesty. Personification is bad description. If I say "my code-review agent and security agent collaborated on this," I've invited you to picture colleagues. That picture is wrong: no judgment behind those agents that isn't mine, no accountability that isn't mine, nothing they catch that I didn't design them to catch. Dressing them as coworkers hides all of that.
The personification oversells the agents (they have no judgment that isn't mine) and undersells the achievement: the routing, control plane, guardrails, economics. A simulated headcount is theater. A solo operator running a real system is the interesting thing.
If I believed the swarm was a team, I'd trust it like one: delegate judgment, assume someone's watching, relax the review. That's the failure mode that turns a useful system into an unsupervised one. Saying "I" keeps accountability where it lives. So: I. Throughout. Even when an agent did the typing.
The Swarm: Capabilities, Not Coworkers
The swarm is specialized agents scoped to bounded slices: orchestration, design review, aggressive code review, knowledge curation, external research, security watchdog, spec-following implementation.
That's division of labor, but notice what each item is: a capability, not a coworker. "Architecture review" is something the system does, like a test suite. Nobody calls their CI pipeline a teammate.
Think of each agent as a specialized tool (profiler, linter, fuzzer): scoped, composable, valuable precisely because it's narrow. A profiler answers one question extremely well and shuts up. The agents are the same: I handle orchestration and judgment.
A narrow agent with a clear job is reviewable and predictable. The code reviewer doesn't decide what to build; it tears apart proposals and I read the teardown. The security watchdog surfaces findings and I decide. Each agent does one thing I can verify. Treat AI like a junior you review, not an oracle you obey. The swarm runs more juniors in parallel, each on a tighter leash, with me reading the output.
OpenSpec: A Solo Studio Needs a Control Plane More Than a Team Does
Solo, there's no standup to catch drift. On a team, coordination happens by accident. Someone mentions what they're working on, someone notices a PR that contradicts a decision. The shared context exists via friction and collision.
Solo with agents, that friction is gone. Drift stops being a personal failing and becomes systemic risk: agents build toward a half-specified goal, confidently, in the wrong direction.
The control plane has to be written. For me that's OpenSpec: changes and specs are canonical truth for what's being built and why. Not a Kanban board of vibes, not one-line tickets, not my head. A document plane where a change has written rationale, spec, and tasks, and "what are we building" has a single authoritative answer agents and I can both read.
A team can run on partially-shared memory because the sharing is distributed across people. A solo operator running agents has exactly one head holding the context, and agents that will execute confidently against whatever's in the spec, including the gaps. The written control plane isn't bureaucracy. It's the only mechanism that keeps me and the swarm pointed at the same target. The discipline that feels like overhead on a team is load-bearing for one person.
The payoff is concrete. When I hand a slice of work to an implementation agent, I don't hand it a vibe. I hand it a spec it can read. When I come back to a change three weeks later, the rationale is right there, not reconstructed from memory. And when an agent proposes something, I can check it against the spec instead of against my mood that afternoon. The control plane is the thing that lets one person stay coherent across more parallel work than one person should be able to track.
The Daemon: A Teammate That Never Sleeps
The daemon runs unattended on a loop: observe, triage, think, act, record, forever. It reads project state, decides what's worth doing, handles a bounded slice, and writes what happened for me to review. It handles maintenance: service health, dependency hygiene, backlog ranking, production triage.
It's the part of the system that doesn't need my attention to keep moving. Everything else (swarm, control plane) runs on loops that start with me. The daemon is the exception.
The value isn't labor. I could restart a service or rank a backlog myself. The value is doing that without spending my attention, on a schedule, while I'm focused on judgment work. Maintenance doesn't cost time; it fragments focus. Offloading it to a loop that never logs off buys back contiguous attention. "A teammate that never sleeps" is useful shorthand for what it feels like. It's a process I built, on a leash I hold.
Cost Discipline Is a Design Input, Not an Afterthought
An agent swarm only works if most of it is cheap. It's not a footnote; it's structural.
An assistant you prompt by hand costs you only when you use it. A swarm runs all day whether it's producing value or not. If every action reached for a frontier model, I'd have built an expensive way to mostly discover there's nothing to do. The economics would kill autonomy.
Money is a design input from the start. The studio is local-first: cheap, on-device models handle high-volume, low-stakes work (triage, classification, routine passes). Heavier reasoning escalates to a private GPU. Only work that earns it reaches a frontier API. A free model decides before a paid one acts.
The cost ceiling isn't a limitation on the system. It's the thing that enables it. Because most of the swarm costs nothing to run, I can afford to run it constantly, which means it's actually there when something needs doing. A studio you can only afford to operate occasionally isn't a one-architect studio with leverage; it's a person with an expensive habit. Designing for cheap from day one is what turns "I have agents" into "I leave them on."
The other half of the economics is subtler, and load-bearing enough that it got its own post: prompt-cache discipline. Every compatible model provider keys its cache on the prefix of the request. Hit the cache and you pay a fraction of the cost at several times the speed; mutate the prefix mid-conversation and you torch the cache for the rest of the session. The expensive mistakes look innocent: injecting a timestamp into a system prompt, reformatting it "harmlessly," adding a tool mid-conversation. Each one quietly multiplies the bill. When you're running a swarm constantly on a tight budget, that discipline isn't an optimization. It's the difference between a system you can afford and one you can't.
The honest version: I don't treat the budget as a number to come in under at month-end. I treat it as a parameter the architecture has to satisfy, the same way I'd treat a latency target or a memory ceiling. Spend is something I design for, not something I reconcile after.
Where It Breaks
Everything above is real and a genuine multiplier. But a multiplier acts on whatever you feed it. There are things you cannot feed it: things that don't delegate, don't parallelize, and don't get cheaper with agents. Here's where it stops scaling.
Taste and judgment don't delegate
The swarm can implement a design. It cannot decide whether the design is good. It can propose three approaches and argue each one. It cannot tell you which one is right for this product, this user, this moment, because that judgment isn't a computation over the repo, it's a stance, and the stance is mine. Every time I've tried to delegate taste, I've gotten output that's locally reasonable and globally wrong: correct code building the wrong thing, clean abstractions over a bad decision. The agents are excellent at "is this done well." They are useless at "is this the thing worth doing." That second question doesn't scale with headcount, simulated or real.
Accountability is still entirely mine
When the studio ships good work, I shipped it. When it ships broken work, I shipped that too. The agent that wrote the bug was running on my leash, against my standards, inside my guardrails. "The agent made a mistake" is never an excuse because the agent making a mistake I didn't catch is my mistake. Accountability doesn't distribute with agents. It concentrates. All of it lands on one person, by design.
Agents amplify intent, including a vague one
Clear intent gets amplified into good work; vague intent becomes confident, plausible mess. A team has friction that slows bad ideas: clarifying questions, pushback. The swarm has no friction. Hand it a half-formed goal and it executes beautifully at speed in the wrong direction. The leverage cuts both ways. Clearer thinking buys more value. Fuzzier thinking buys a polished wrong thing.
The promise of an agent swarm is that it removes the bottleneck. It doesn't. It moves it. The constraint used to be typing: how fast I could turn a decision into code. Now the typing is nearly free, and the constraint is upstream: deciding well, specifying clearly, and reviewing enough to catch the confident mistakes. A swarm that produces ten times the output needs a human who can decide and review at something like that rate, or it produces ten times the drift. I removed the easy bottleneck and exposed the hard one.
The swarm needs a reviewer, or it drifts
Left alone, the system degrades. Agents find creative interpretations of "helpful," small misalignments compound, and what was pointed right three weeks ago aims elsewhere now. The trail every agent records is my early-warning system, only if I read it. The review is the job. An outer loop you never close is an inner loop you stopped supervising. Unsupervised agents generate plausible artifacts nobody asked for.
What's Real and What's Theater
Theater : named agents, simulated org charts, the "we" implying payroll. Headcount cosplay. It demos well and it's hollow: a costume over one person. None of the value lives there. Delete the names tomorrow and the studio's capability doesn't change.
Real : routing that keeps work cheap and local, a control plane that aligns me and agents, a daemon holding the night shift, guardrails bounding what it can do, and underneath: a single human deciding, specifying, reviewing. The achievement is that it doesn't need to be a team.
The interesting thing about a one-architect AI studio was never "it's secretly a team." It's that one person, with the right systems, can operate at a scale that used to require one. The systems are the story: the model routing, the written PM plane, the autonomous loop, the cost architecture, the review discipline. Strip the personas and you lose nothing real. Strip the systems and you lose everything. Build the systems. Skip the costume.
If You Want to Try This
Don't read this as "go build a swarm." A swarm is the last thing you add, not the first. Most value comes from one or two systems, and a swarm with no control plane and no review is a faster way to make a mess.
Start with one system that fixes your actual bottleneck.
- Losing the thread of what you're building? Start with a control plane: a written source of truth for what's in flight and why. Specs and rationale, not tickets. Highest-leverage first move. Zero AI required.
- Maintenance toil fragmenting your focus? Start with one autonomous loop. Pick a scheduled task needing no judgment: triaging alerts, flagging stale dependencies, summarizing failures. Build the smallest observe-decide-record loop. Build the off switch first. One loop teaches you more than a swarm you can't supervise.
- Decide the budget before you turn anything on. Treat spend as a design input. What's the ceiling, what fails closed, what's the cheapest tool for each job.
- Add specialized agents only once you have a thing to point them at. A code reviewer is leverage with a spec to review and a human who reads it. Capabilities earn their place doing one verifiable thing. Add them one at a time.
- Schedule the review and actually do it. The trail is worthless unless you read it. The review is the whole job now.
This isn't a story about how much I can do alone. It's a template for any solo builder who's drowning in the gap between what they can imagine and what one pair of hands can ship. The systems close that gap, not by faking a team but by being honest leverage. Start with one. Earn the next. And keep saying "I," because the accountability was always going to be yours anyway.
The Honest Account
A one-architect AI studio is a genuine multiplier, but the multiplier is the system, not a simulated crowd.
- It's one person. Me. The swarm is capability, not headcount.
- The systems do the lifting. Bounded specialists, a written control plane, an autonomous daemon, and cost architecture keeping it cheap enough to leave on.
- Cheap is load-bearing. Local-first routing and cache discipline make constant operation affordable.
- It stops at judgment. Taste doesn't delegate, accountability concentrates, and the swarm amplifies whatever clarity you bring, including none.
- The bottleneck moved. From typing to deciding well and reviewing enough.
The personas were theater. The systems were the point. Build the systems, keep accountability where it lives, and you can run a studio like more than one person without pretending to be one.
I, not we. Capabilities, not coworkers. A system, not a costume.
Running something similar or thinking about it? Tell me which system you'd start with. The breaking points are where the real learning is.
Top comments (0)