Introducing the Vulcan System: the software factory that builds software
How a small team operates every layer of a production voice-AI platform: fleets of coding agents in up to 85 parallel worktrees, one shared authority loop, and a guard stack that permission-blocks dangerous actions.

Most companies bolt AI onto their existing process. We did the opposite: we rebuilt the process around AI, then gave it a name. The Vulcan System is the software factory behind everything IntuneLabs ships — a set of tools that exist to build other tools, so a small team can operate every layer of a production platform at once.
Named for the god of the forge, the metaphor is load-bearing rather than decorative. Work is mined out of the codebase, forged into a change, struck into shape on the anvil of a shared tech base, and passed through a gate before it reaches anyone. Machine speed, human judgment, nothing in between.
One loop, repeated at machine speed
The heart of the system is a single authority loop that every change travels through. It starts with research: agents mine the codebase, the knowledge corpus, and prior decisions to understand a problem before a line changes. The work is then planned — scope, approach, and checks written down as a reviewable proposal — before implementation begins. Agents build in parallel, each in its own isolated copy of the repository. Every change runs the full local gauntlet of tests, lint, and static analysis, and only advances when those checks are already green. Then a human reads it the way a staff engineer reads a pull request, because that is exactly what it is.
The defining property of the loop is that authority only ever increases toward the human at the end of it. Agents have wide latitude to explore, plan, and build, and none whatsoever to ship. The only exit from the loop is a person saying yes. Speed does not outrun discipline, because discipline is the last step.
Two things keep a fleet of agents from drifting apart on what is actually true. The first is a shared, machine-generated view of the repository's facts, regenerated rather than hand-maintained, so every agent reasons from the same ground truth instead of a stale copy in its head. The second is a strict order of authority: when two sources of instruction disagree, the conflict resolves the same way every time rather than by whichever agent spoke last. Determinism, not negotiation, is what lets many workstreams run at once without quietly contradicting each other.
Two agents, one operating contract
The fleet is not one uniform swarm; it is two frontier coding agents run in parallel under a single written contract. Both move through the same task phases — research, plan, implement, verify, review, then complete — and answer to the same layered order of authority, so two different agents reason about a change the same way and hand off cleanly instead of talking past each other. When more than one is live, the primary copy of the repository goes read-only and every workstream moves into its own isolated worktree; that one rule is what turns dozens of simultaneous changes from a collision risk into ordinary parallelism. The contract the agents follow is itself version-controlled and reviewed like any other code, so the rules evolve under the same discipline as the product they produce.
Fail-closed by construction
Speed without safety is just a faster way to break production, so the factory is fail-closed by design rather than by policy. A pre-push gauntlet scans every outgoing commit for secrets and checks the deploy wiring before anything leaves the machine. Hooks hard-block agents from touching authentication surfaces or invoking a deploy. A guarded deploy wrapper refuses to ship if any live function would silently vanish — a direct response to a real incident where an unguarded deploy deleted production functions.
The backend carries the same assumption down to the level of a single function. Rather than trust that something upstream already checked the caller, every function authenticates its own caller in its own body, as if it were the only line of defense — and a dedicated suite proves exactly that, calling the real functions with no credentials at all and requiring every one of them to refuse, both in continuous integration and again as a gate before any deploy. An endpoint that forgets to check its caller does not reach production; the test that assumes the worst catches it first.
The subtle part is what happens when the system is unsure. Unknown means no: an unverified state fails closed instead of assuming the best. A non-interactive run cannot answer its own confirmation prompt, so an agent cannot wave itself past a guard. Cleanup jobs run dry-run-first and do not force-remove anything. Each of these guards exists because a specific failure mode was observed, named, and closed by construction.
Bounded autonomy
That is the whole architecture in one line: autonomy up to the pull-request boundary, and nothing past it. Agents run at full speed across up to 85 concurrent, isolated worktrees — dozens of workstreams that cannot collide with each other or reach production, by mechanism rather than trust. But there is no flag an agent can flip to skip the gate, and no credential it holds that would let it deploy. Humans get an audited override path; agents get none.
This asymmetry is deliberate. It means we can let the fleet be genuinely fast, because the cost of a bad idea is a rejected proposal, not a production incident. Work that once took quarters now ships in weeks, and a new vertical can go from idea to a running product in days — without the usual trade of speed against safety.
The same pattern, beyond code
The factory does not stop at software. The company's entire knowledge layer — strategy, research, patents, meeting notes — is git-versioned markdown, maintained by the same agents that ship the product, under the same contracts and the same guardrails. Code and corporate memory live under one version-control system, one review discipline, one fail-closed philosophy.
That is what lets one small team run a real-time voice engine, an operator console, consumer web and mobile apps, a B2B care backend, and this very site — all in a single monorepo, all in production motion. The Vulcan System is how the range gets covered. Read more on the Vulcan overview.
This note describes the implementation as it stood when it was written. Figures are counted from the repository; they are not published benchmarks or a performance guarantee.


