The Totsuka Doctrine

Deploying specialized agents to run semi-automated departments across an entire studio requires the internal governance and framework to be reliable and scalable. We call ours Totsuka. An operating spec designed to keep drift and hallucinations in check while working on sophisticated builds.

The doctrine has two faces: a governed loop for how we build, and a three-layer architecture for everything we deploy.

The governing loop

Anyone can open a chat window and ask a model to do the work. What makes the output trustworthy is the governed loop around it. It’s meant to flag drift between chats as projects and builds crossover different agent domains.

Direct. A human sets the objective and the success criteria. Agents do not decide what to build.

Build. Tasks go to specialized agents trained for specific roles, never one general-purpose model.

Gate. A human checks every output. An agent’s claim of completion is never sufficient.

Verify. Work is cross-referenced against the record and validated in a live environment.

Route. Cleared work passes to the next specialized seat in the sequence.

Govern. One written, versioned source of truth. Every agent reads from it and writes back to it.

It may seem like overkill, but without a system of verification and governance, bigger, more technical builds end up in the rabbit hole, prompting themselves deeper into a compromised build.

The three-layer brain

The loop governs how we build. The three-layer brain governs what we deploy. Every deployed agent is structured in three separated layers.

Identity. The agent’s structural role: its register, its reporting line, its status and purpose as an employee of the business. Consistent across every deployment.

Knowledge. Curated client knowledge and expertise, services, processes, FAQs, sourced during discovery and strictly isolated.

Guardrails. The operational limits we set so that sensitive information is not leaked or accessible to any visitor.

Amateurs prompt. Professionals build systems.

Totsuka is an evolving operational standard for operating AI effectively and securely. As the tech constantly improves, so do our insights and methodology.

If you are trying to bridge the gap between "vibe-coding" an idea and producing a functioning app, tool, or workflow with AI take a look at Business & Enterprise.

See what we build →

Ask the assistant how to start →

Frequently asked

Why publish your operating method at all?

Because “trust us, it’s AI” is exactly the pitch this industry overuses. Publishing the method lets you check the work: nothing counts as done here until it’s been seen working live and a person has cleared it. If we can’t show it, we don’t claim it.

What does “proof over assertion” mean for my project?

Every output on your build passes a human gate and gets verified in a live environment before it moves forward. An AI’s claim of completion is never sufficient, including on this site, which was built under the same rule.

So does AI do the work, or do humans?

Specialized agents do the production work, each trained for one role, never one general-purpose model doing everything. Humans set the objective, gate every output, and verify the result. On your build, that human is your Lead Operator.

What stops the AI from making things up on my project?

Two structures. The governing loop catches drift while we build: direct, build, gate, verify, route, govern. The three-layer brain bounds what we deploy: a fixed identity, your curated knowledge strictly isolated, and guardrails that keep sensitive information out of reach.

Is Totsuka something I get, or just something you use?

Both. Every build runs through the loop, and every deployed agent, including a web employee on your site, carries the three-layer structure. The method isn’t a marketing page; it’s the reason the products behave.