Gates — the deployment flow

Every deployment in the AI Orchestrator follows the same six-gate flow. Every agent — Postgres, Kubernetes, Python, Datadog, all of them — uses this structure. Once you’ve completed a deployment with one agent, you know how to use all of them.

The gate system isn’t just UX scaffolding — it’s the unit of human review, approval, and audit. Each gate is a checkpoint with explicit input/output.

The six gates

Gate 1 ──→ Gate 2 ──→ Gate 3 ──→ Gate 4 ──→ Gate 5 ──→ Gate 6
Intent     Scope      Infra      Sizing     Review     Deploy
                      target     +cost

Gate 1 — Intent

The agent asks: what are you trying to accomplish, in one sentence?

Examples of good intent:

Main app database for a Python API serving ~500 RPS
Analytics warehouse for product event data, queried by 5 analysts
Caching layer for session tokens, ~50K active sessions, sub-ms latency

The intent shapes every downstream decision. “Main app database” gets a different default (HA, PITR enabled, prod-grade) than “dev sandbox for prototyping a feature” (single instance, no HA, cost-optimized).

This is the only freeform gate. Subsequent gates are constrained-choice or guided.

Gate 2 — Scope

The agent restates the intent as a concrete provisioning scope:

“Provisioning a primary Postgres 16 instance with HA failover, daily backups, point-in-time recovery, encrypted at rest. Read replica config available but not provisioned by default. Sound right?”

You can:

Accept (yes)
Refine (no replicas, add a read replica in europe-west1)
Show alternatives (what would change for a dev sandbox?)

The scope is the canonical description of what’s being deployed. It’s persisted on the deployment record and shown in audit logs.

Gate 3 — Infra target (cloud + region)

The agent asks where to deploy:

“Which cloud + region? You have connected:

- GCP your-project-abc123 (default region: us-central1) - AWS 123456789012/us-east-1

Or specify another region.”

This gate is the multi-cloud abstraction layer. Whether you pick GCP or AWS or Azure, the rest of the flow looks the same — but the specific resources generated differ per cloud.

Each agent supports the clouds it makes sense for:

Postgres: GCP Cloud SQL, AWS RDS, Azure Database for PostgreSQL, or self-managed on K8s
Kafka: AWS MSK, Confluent Cloud, or self-managed on K8s
Lambda-style serverless: AWS Lambda, GCP Cloud Functions, Azure Functions

See Concepts — Multi-cloud for why every agent supports multiple clouds equally.

Gate 4 — Sizing + cost estimation

The agent proposes resource sizing based on the intent + scope:

“For ‘main app database, 500 RPS’ I’d default to:

- db-custom-2-7680 (2 vCPU, 7.5 GB RAM) - 100 GB SSD with autoscale to 500 GB - HA enabled (active-passive across zones)

Estimated cost: $185/month on GCP.

Adjust? (smaller / bigger / show alternatives)”

The cost estimate pulls from current cloud pricing APIs (GCP Pricing API, AWS Pricing API). It’s an estimate, not a quote — actual bills depend on traffic + data transfer + storage growth.

This gate is where sizing decisions get made before commit. Catching a wrong tier at Gate 4 is much cheaper than discovering it in production.

Gate 5 — Review (plan summary)

The agent generates a Terraform plan (or equivalent IaC) and shows a human-readable summary:

“Plan summary: - 1 google_sql_database_instance (primary) - 1 google_compute_network (VPC for private IP) - 1 google_compute_subnetwork - 1 google_service_networking_connection (VPC peering) - 1 google_sql_database (main schema) - 1 google_sql_user (hivedeploy user) - 2 IAM policy bindings (your app SA → cloudsql.client)

Show full Terraform plan? (yes / no)”

If your org has approvals required for prod turned on (see Approvals), this is where the deployment pauses for an admin to approve before Gate 6 runs.

You can:

Approve (apply)
Refine (use db-custom-4-15360 instead) — kicks back to Gate 4
Cancel (abort) — deployment ends, no resources created

Gate 6 — Deploy

The agent runs the IaC against your cloud, using your federated credentials. Progress streams into the chat:

Initializing Terraform...
Refreshing state...
Plan: 7 to add, 0 to change, 0 to destroy.

Applying...
google_compute_network.postgres_vpc: Creating... ✓ 12s
google_compute_subnetwork.postgres_private: Creating... ✓ 4s
google_sql_database_instance.postgres_main: Creating... ✓ 4m 22s
google_sql_database.main: Creating... ✓ 2s
google_sql_user.hivedeploy: Creating... ✓ 3s
google_service_networking_connection.peering: Creating... ✓ 8s
google_project_iam_member.app_sa_binding: Creating... ✓ 1s

Apply complete. 7 resources created.

The agent then surfaces connection details, dashboard links, and adds the resource to your Deployments list for future management.

Why these specific six gates

The split is based on the cost of changing your mind at each step:

Gate	Reverse cost	Why this gate exists
1 — Intent	$0 (just words)	Wrong intent = wrong everything downstream. Catch early.
2 — Scope	$0 (still words)	Decouples “what are you doing” from “how big is it”.
3 — Infra target	$0 (still pre-plan)	Cloud choice locks in pricing + feature set. Decide here.
4 — Sizing	$0 (still pre-plan)	Wrong tier = budget blow-up. Decide before commit.
5 — Review	$0 (still pre-apply)	Last chance to catch surprises. Approval gate.
6 — Deploy	$$ (actual cloud resources)	Reversal = `terraform destroy` + clean-up.

Each gate intentionally lets you go back to the previous gate without losing context. Going from Gate 5 → Gate 4 because the cost estimate looked off is a normal part of the flow.

Per-org approval policies

Org admins can configure which gates require approval in /settings → Approvals:

No approvals (default for solo accounts) — you fly through all six gates yourself
Approve at Gate 5 (typical for prod) — admin reviews the plan before apply runs
Approve at Gate 3 (paranoid) — admin reviews even the cloud + region choice
Tag-based — only deployments labeled env=prod need approval

See Approvals guide for the full setup.

Post-deployment phase

After Gate 6, the deployment isn’t “done” — it’s live. The same specialist agent continues to own it:

Asks “are you alerted on this DB’s CPU?” if monitoring isn’t wired
Surfaces drift if the resource gets edited outside the orchestrator
Answers troubleshooting questions in the same chat session
Walks you through scaling / failover / restore when needed

The session never “closes” — it’s a long-lived conversation with the specialist that owns this resource. Resources you provisioned 6 months ago can still be addressed via their original session.

Gates per agent type

While every agent uses six gates, the specific questions at each gate are agent-specific:

Postgres Gate 4 asks vCPU / RAM / storage
Kafka Gate 4 asks broker count / partition count / retention
Datadog Gate 4 asks which infrastructure to monitor (more config than sizing)
Python service Gate 4 asks runtime version / concurrency / cold-start tolerance

The structure is universal; the content per gate is specialist-domain.