Running a One-Architect AI Studio
One human, an agent swarm, and the honest account of what actually scales
11 min read
One human, an agent swarm, and the honest account of what actually scales
"Capabilities, not coworkers"
Illustration by FLUX.2 Pro (fal.ai)
Feel free to send us a message with your thoughts, or learn more about us!
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.
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 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.
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.
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 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.
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 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.
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.
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.
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.
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.
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.
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.
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.
For developers
Don't build a swarm. Build a control plane, or one autonomous loop, whichever fixes your real bottleneck. Cap the spend, build the off switch first, and schedule the review. Add agents later, if ever.
A one-architect AI studio is a genuine multiplier, but the multiplier is the system, not a simulated crowd.
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.