The Qirava factory: roles, skills and maturity gates (G0 to G3)

How do you organize a factory of governed agents? With three pieces: each agent enters through a role, that role loads a package of skills, and work only moves forward when it clears a maturity gate. Beyond that there is no magic and no improvisation. There is a production line with stations, tools and quality controls, just like any serious factory.

For a while we did what almost everyone does: ask the AI "let's see what comes out". That has a name, it is called vibe coding, and it works until you need to reproduce the result, audit it, or set several agents to work together without stepping on each other. That is where it collapses. The Qirava factory was born to replace that improvisation with a method: specification first, execution later.

01 · the blueprintThe spec first, the agent after

The method is called SDD, Spec-Driven Development. The rule is simple and admits no shortcuts: before an agent touches anything, there is a spec that states what must be done, by what criteria it counts as done, and which limits are never crossed. The spec is not documentation written afterward. It is the blueprint written beforehand, and it is what governs the agent.

This is not a quirk of ours. Amazon has spent more than twenty years working backwards: before building a product, they write the press release and the FAQ as if it already existed, and only if that document is convincing do they execute [1]. The AI engineering community has arrived at the same place by another route: tools like GitHub Spec Kit formalize that the specification, not the improvised prompt, is the source from which the code comes [2].

An improvised prompt produces a surprise. A spec produces a result you can reproduce.

02 · the stationsEach role loads its own package of skills

In a factory nobody does everything. There are stations. In the Qirava factory, each agent enters through a role, and that role defines what it knows how to do and what it cannot touch. It does so by loading a package of skills with four layers: a universal skill that everyone shares (the common governance, qirava-llm-governance), a primary skill belonging to the role, secondary supporting skills, and a list of forbidden skills that the role cannot invoke even if it wants to.

That last layer is the one almost nobody puts in place, and the one that protects the most. It is not enough to tell an agent what it can do; you have to tell it what is off limits. The marketing agent does not deploy code. The QA agent does not approve its own release. The limit is part of the design, not a later correction.

You do not define an agent by what it can do. You define it by what you forbid it.

There is one detail that holds all of this up: the true documentary source is a DOCUMENT_INDEX, a single index. The skills live in a toolkit, the governance lives in a vault, and the agents consume them by symlink instead of copying. That way, when a rule changes, it changes in a single place and every agent inherits it. There are not ten versions of the governance floating around.

03 · the controlsMaturity gates: nothing moves forward without clearing its own

Having roles and skills is not enough. The quality control is missing, and this is where the factory truly becomes a factory. Everything an agent produces passes through four maturity gates, and it does not reach the next one without meeting the previous one:

G0, specified. The spec exists. Without a blueprint nothing starts. G1, draft. The agent produced a proposal and passed basic validation. G2, operational. The CEO approved: only here can the work touch reality. G3, board. What already operates and deserves to be raised to a board decision. Each jump is a gate with an owner, and the most important one, G2, is approved by a person.

Here is the principle that avoids the most common disaster with agents: drafts deliberate, but they do not simulate execution. To deliberate is to propose, evaluate and decide. To execute is to make the real change. An agent at G1 can argue itself hoarse about why something should be deployed, but it deploys nothing. That line, between thinking out loud and acting, is what separates a governed factory from a swarm of bots doing things nobody authorized.

04 · closing the loopQA that certifies, not QA that rubber-stamps under pressure

The last control is missing, the one many teams paper over: quality. In the Qirava factory, QA is a loop with professional regression that runs until it certifies. The difference with common practice is brutal. You do not re-test just enough to make it pass; you test in earnest, and if something fails it goes back into the loop. To certify is not "I stopped finding errors because I barely looked". It is "this withstands the full regression".

That discipline exists beyond us: the agile work cycle itself separates the building from the validation precisely so that whoever tests is not the one in a hurry to ship [3]. In a factory of agents, where it is tempting to let a model "approve itself", that separation is the only real defense.

Put the four pieces together and you have the factory: a spec that governs (G0), agents that are born under governance with their package of skills, gates that nobody skips (G1 to G3), and a QA that certifies for real. Each agent deliberates within its role, proposes within its spec, and only executes when a person has opened the gate. It is not bureaucracy: it is what makes the work of ten agents reliable instead of being ten surprises.

The next time you see someone ask the AI "let's see what comes out", remember that this is not a factory. It is a one-person workshop with a bit of luck. A factory has blueprints, stations and controls. And in the Qirava one, no agent crosses a gate that is not its own.