Skip to main content

Provisioning through conversation

Most platforms let you ask about your infrastructure and then hand you a form to change it. Here, an agent can do the work, because provisioning verbs are tools like any other and are governed like any other.

What can be asked for​

AskWhat happens
A database in a workspaceCreated, or a quota request raised
A bucketCreated, or a quota request raised
A topicCreated, or a quota request raised
A clean room, and parties addedCreated with its governance in place
A workspace clone, archive or restoreExecuted through the lifecycle path
A failover or failbackExecuted through the disaster-recovery path
Readiness for any of the aboveRead, with no side effects

The read verbs deliberately carry lower friction than the write verbs. Asking whether a failover would succeed should not require the ceremony that performing one does.

The path a request travels​

Figure AP1: provisioning by conversation. The agent proposes; the executor gates. Every provisioning verb is declared consequential, which is what routes it through the value gate and makes it pausable for a human. The planner is deliberately steered toward reading first and proposing the smallest plan that does the job.

Every provisioning verb is consequential​

That declaration is not a label. It is what forces the verb through the value gate, and a consequential tool cannot even be registered without supplying the means to identify who its action affects. A provisioning verb that could not say who it touches would not reach a running cell.

The approval pause is fail-closed​

For a consequential step, the executor consults the gate and only a positive verdict proceeds automatically. An unwired gate, a failing extractor, or any other verdict pauses the run in an awaiting-approval state, persisted, until a human approves. Then it resumes from that step rather than restarting.

The framing to keep: the agent proposes, the executor gates. A plan is a proposal regardless of how confident the model sounds.

Over quota raises a request, it does not take​

When a provisioning call exceeds the workspace's quota, the platform raises a provisioning request rather than silently over-allocating or failing flatly. The ask becomes a tracked decision for someone to make.

Governance is not weaker because a model asked​

Whether the caller is a person clicking a button or an agent acting on a sentence, the same gates apply: the acting principal's permissions, the value gate, the approval pause, the quota check, and the audit record. The conversational surface is an entry point, not a bypass.

Worth being precise about one implementation detail, because it is the kind of thing that goes wrong quietly: the in-process path that lets chat reach these tools does not traverse the remote dispatch chokepoint, so it enforces permissions itself, fail-closed, resolving the required permission per tool. A path that assumed the chokepoint would cover it would be exactly the gap worth worrying about.

What cannot be asked for​

Raw compute capacity. Cells and hosts are not agent-provisionable. Fleet placement stays with the administrative surfaces, and a run that needs stronger isolation can only request it from the fleet, failing closed when the fleet cannot provide it.

The line is drawn where it is because provisioning a database inside a governed workspace is bounded work, and provisioning the substrate the governance itself runs on is not.