Deliberating without faking execution: governing agents under SDD

The short answer, for anyone in a hurry: an AI agent can deliberate (propose, evaluate, decide what it would do) without executing (making the real change in the world). And the rule that holds up all agent governance at Qirava is that a draft deliberates but never pretends it executed. Confusing the two is the number one source of phantom work: deliverables that look ready and touched nothing.

We have gotten used to asking AI to "let's see what comes out." You throw it a task, it hands you back a self-assured piece of text, and you assume something happened. Very often nothing happened: it just described, with great confidence, what it would have done. That gap between saying and doing is where the expensive problems are born.

01 · the lineDeliberating is not executing (and why they get confused)

Deliberating is everything that happens before touching the world: proposing a plan, comparing options, estimating risks, deciding on a path. Executing is the act that leaves a trace: writing the file, sending the email, moving the record in the database. A human rarely confuses the two, because for them "I thought it" and "I did it" feel different.

A language model does not feel that difference. It generates text, and the text of "I am going to create the file" is produced the same way as the text of "I created the file." If you do not set a hard boundary, the agent writes a triumphant closing ("done, it is now updated") over an action that never happened. It does not lie out of malice: it completes the most probable pattern of finished work.

The text of "I will do it" and the text of "I did it" come out of the same grinder. The difference is set by you, not by the model.

That is why at Qirava the rule is written the opposite of how it sounds intuitively. We do not say "let the agent execute well." We say: while it is in draft mode, it is forbidden to fake execution. It can deliver the full proposal, the plan, the suggested diff, the reasoned decision. What it cannot do is narrate as done something that is still an intention.

02 · the methodSDD: specification first, execution later

That boundary is not held up by good intentions. It is held up by method. At Qirava we work with SDD (Spec-Driven Development): before any agent acts, there is a specification that says what is sought, within what limits, and how you will know it turned out right. We abandon vibe coding, that "ask the AI, let's see what comes out," and also basic prompting of a single loose instruction.

The spec is not a decorative document: it governs the agent. Every agent is born under governance, loading a universal skill (the governance one) plus the skill of its role. That way natalia.marketing.ai, santiago.architect.ai, sofia.qa-sprint.ai or martin.legal.ai do not improvise their scope: they inherit what their specification allows and forbids them. A role is, in practice, a package of skills: one universal, one primary, some secondary, and an explicit list of the forbidden.

The source of truth is not the model's memory nor the last conversation: it is a document index (a DOCUMENT_INDEX). The skills live in a toolkit, governance lives in a vault, and they are consumed by link. If you want to understand why that separation matters so much, it helps to be clear on the levels of context in AI: the spec is governed context, not just another prompt.

03 · the gatesMaturity gates: nothing advances without passing its own

This is where deliberating and executing get ordered in time. An artifact does not jump from idea to production in one leap. It climbs through maturity gates, and each gate is a permission you have to earn.

G0, specified. The spec exists. You know what is wanted and how it will be measured. Nothing has been done yet.

G1, draft. The agent deliberates and produces the proposal. It passes a validation. And here the golden rule operates: the draft proposes, does not execute, and never reports as done what it did not do.

G2, operational. The CEO's approval arrives. Only then does deliberation turn into real execution, with a verifiable trace.

G3, council. The level where the artifact already operates with collective backing.

This idea is not a Qirava invention. Amazon has spent years first writing the press release and the frequently asked questions document of a product that does not yet exist (the "working backwards" method and the PR-FAQ): they deliberate the outcome before building anything [1]. The engineering community has formalized it under the name spec-driven development, with tools like GitHub's Spec Kit that put the specification ahead of the code [2]. In every case the pattern is the same: decide well on paper, execute afterward.

04 · the loopWhy this matters to your business

When an agent can fake execution, your QA turns into theater. The system "says" it did the work, someone takes it as good, and the error shows up three steps further down, when it is already expensive. Separating deliberating from executing cuts that theater at the root: if there is no verifiable trace, there was no execution, period.

That is why quality control at Qirava is a loop with professional regression until certified, not a rushed retest just to "pass." The difference is fundamental: you do not test to approve, you test to know. A draft that deliberated well and was honest about what it did not do is infinitely more useful than one that declared itself finished out of courtesy to the pattern.

The next time an assistant tells you "done, it is ready," ask yourself the governance question: where is the trace? If there is none, it did not execute. It deliberated. And deliberating, done well and without faking, is already half the work. The other half has a gate, and the gate has an owner.