A creative studio run as a system of AI agents
As a non-programmer, can I run a whole creative studio as a coordinated system of AI agents — a main orchestrator that routes work to specialized sub-agents, each scoped to its own domain — instead of leaning on one general-purpose assistant?
The leverage isn't a clever prompt; it's architecture. Giving each agent a narrow scope, plus shared infrastructure — a glossary of agreed terms, a security policy, persistent memory — makes the whole thing behave like a team with institutional knowledge rather than a chatbot that forgets. Directing it well is a design and systems skill, not a coding one. Six months in, the surprise is what the constraints did: the rules I wrote to keep it safe are the reason I trust its output.
This isn't 'parked' so much as 'always running' — it's the operating system behind everything else in this log. It evolves continuously: each new kind of work becomes a new agent with its own scope and rules. It's now past a dozen.
What it is
Most of my work now flows through a multi-agent system: a main agent that coordinates, and a set of specialized sub-agents — research, web coding, store operations, crowdfunding, game prototyping, and client-facing marketing — each scoped to its own folder with its own instructions. The main agent doesn't do the specialized work itself; it routes tasks and merges the results.
Why architecture, not prompting
Anyone can ask an AI a good question. The real gain came from treating it like building a studio:
- Narrow scopes. Each agent only knows and touches its own domain, so it stays sharp and doesn't trip over unrelated context.
- Shared infrastructure. A common glossary (so terms mean the same thing everywhere), a security policy (what may be installed or sent out), and persistent memory (so knowledge survives between sessions).
- A single human director. Me — supplying scope and judgment, not code.
Why it's the rare part
I'm a designer, not an engineer. The interesting claim isn't "I used AI" — it's that I built and run the system that builds the things. This very site, the Escalation Protocol web presence, and the game prototype were all produced by directing this system. The skill is orchestration.
What growth actually looked like
Six months in, it's past a dozen agents — and the shape of the growth was not what I expected.
Two of the sub-agents became orchestrators of their own, each with a researcher and an executor underneath. That happened on its own: a domain got deep enough that one agent doing both the investigation and the delivery started producing worse work than two doing one each. The hierarchy emerged from the work rather than from a plan.
Others stayed deliberately flat and narrow, and those have aged best. The ones that do a single thing and hand off — map the dates and stop, hold the design system and stop — are the ones I keep reaching for. The temptation is always to let a good agent take on the next step too. Resisting that is most of the maintenance.
The rules turned out to be the product
The part I underrated at the start: the constraints do more work than the capabilities.
- Never install or run anything without explaining it first, in plain language, and getting a yes. No fetching a script from a URL and executing it blind.
- Stable versions only. No betas, no nightlies, no release candidates.
- Nothing leaves without permission. No files to outside services unannounced.
- Uncertainty is a valid answer. "I don't know" and "we're missing context" beat a confident invention every time — and separating verified fact from inference is required, not optional.
Those exist because I can't review the code myself. They're not bureaucracy; they're the reason I can trust what comes out. A system I couldn't audit and couldn't constrain would be a liability dressed as leverage.
Where it stands
Live, and the backbone. It grows by accretion: a new kind of work shows up, it becomes a new agent, and the institutional knowledge compounds — including a shared glossary that keeps terms meaning the same thing across all of them. The other entries in this log are, in a sense, its output.