Agents

What an agent is

An agent in the AI Orchestrator is a specialist AI worker that owns the full lifecycle of one specific technology in your stack — not a generic chatbot, not a one-shot deployment script.

Each agent:

Knows one technology deeply (Postgres, Kafka, Kubernetes, Python, Stripe-API-integration, Snowflake, etc.)
Owns deploy + monitor + scale + tune + troubleshoot for that technology — same agent answers “deploy a Postgres” today and “why is Postgres CPU spiking” three weeks later
Has provider-specific memory packs (e.g., “RDS-specific Postgres patterns”, “Cloud SQL-specific Postgres patterns”) so its advice matches your actual cloud
Refuses to talk about technologies it doesn’t specialize in — the Postgres agent won’t help you set up Kafka, and that’s by design

This is fundamentally different from “an LLM with internet access”. The agent’s expertise is encoded in:

A specialist system prompt — multi-thousand-line spec for that technology
Memory files — provider-specific Terraform patterns, IAM templates, common gotchas, recipes
Hard rules — “never do X” guardrails (e.g., the Postgres agent refuses to disable PITR for prod databases)
Cross-agent handoffs — at a deployment’s edge, agents call each other (the Python agent calls the Postgres agent for connection-pooling specs, then composes the answer for the user)

Why specialists instead of one big agent

Generic LLM agents fail at infrastructure because:

Best practices for Postgres differ from best practices for ClickHouse, which differ from RDBMS-vs-OLAP entirely
“What’s a sensible default size?” depends on the technology
Production-hardening checklists are technology-specific
Memory of past customer setups in this technology helps; memory of how Kafka was set up doesn’t help when you’re deploying Postgres

A specialist for each technology means the answers are always in context, defaults are always sensible, and the agent’s memory of past customer setups is always relevant.

Categories of agents

The full list is at Reference — Agents list. At a high level:

Languages / runtimes (8)

python, java, nodejs, go, rust, dotnet, ruby, php

Each handles deploying a service in its language — picking an appropriate cloud runtime (Cloud Run, Fargate, App Service, EKS), generating Dockerfiles, wiring secrets, setting up health checks.

Frontend & Mobile (2)

frontend, mobile

Frontend handles React / Next / Vue / Angular / etc. deployment. Mobile handles iOS / Android build pipelines.

Databases (15+)

Relational: postgres, mysql, cockroachdb, spanner Document: mongodb, cosmosdb NewSQL/Edge: turso, surrealdb NoSQL: cassandra, dynamodb, neo4j Generic: database (when you don’t know which one yet)

Each agent owns the full DB lifecycle — provisioning, schema migration patterns, backup config, read-replica setup, performance tuning, IAM-to-app wiring.

Caching & Search (5)

redis, elasticsearch, algolia, typesense, meilisearch

Analytical & Lakehouse (9)

clickhouse, snowflake, databricks, bigquery, redshift, duckdb, trino, spark, iceberg

Vector & AI Databases (6)

qdrant, pinecone, weaviate, chroma, milvus, pgvector

ML / Model Serving (8)

vllm, mlflow, kubeflow, bentoml, kserve, triton, ollama, ray-serve

LLM-App & Agentic Infra (3)

langchain, langsmith, llamaindex

Streaming & Messaging (7)

kafka, rabbitmq, nats, pulsar, redpanda, kinesis, sqs-sns

CI/CD & GitOps (11)

argocd, github-actions, gitlab-ci, harness, jenkins, circleci, tekton, flux, spinnaker, azure-pipelines, buildkite

Kubernetes & Service Mesh (9)

eks, kubernetes, helm, kustomize, karpenter, istio, linkerd, cilium, consul

Observability (8)

prometheus, datadog, newrelic, grafana, honeycomb, splunk, sentry, opentelemetry

Incident & On-Call (5)

pagerduty, opsgenie, incident-io, rootly, firehydrant

Security & Compliance (6)

vault, snyk, wiz, aqua, tfsec, opa

Identity & Auth (6)

okta, auth0, clerk, keycloak, cognito, firebase-auth

API Gateway & Integration (5)

kong, apigee, postman, tyk, apollo

CDN & Edge (5)

cloudflare, fastly, cloudfront, akamai, deno-deploy

Object Storage (4)

s3, gcs, azure-blob, minio

Other categories

Notifications, Payments, Data ETL, IaC tools, Container Registries, Testing, Workflow automation, Feature Flags, Web3.

See the full reference list for every agent with its supported clouds.

How you use an agent

Three entry points:

1. From the agents catalog

/agents → click any agent → its landing page shows what it provisions, supported clouds, common recipes, “Start a deployment” CTA.

2. Cmd+K natural language

Press ⌘K anywhere. Type what you want:

deploy a postgres for our analytics workload

Cmd+K resolves the intent to the right agent (postgres) and opens that agent’s chat preseeded with your prompt. Faster than navigating the catalog when you know what you want.

3. From a deployment session

Inside an active deployment session, type @<agent> to bring in another specialist. Useful for cross-agent handoffs:

@postgres what's a sensible connection-pool size for this Python service expecting 200 RPS?

The Postgres specialist answers in context (knows your DB instance size from the active deployment), and the answer streams into the session.

The session model

A deployment session is the stateful chat with an agent. It has:

A gate (current progress: Gate 1 / 2 / … / 6 — see Concepts — Gates)
A scope (what’s being deployed)
A deployment record (after Gate 6, the deployed resources)
A history (messages, decisions, approvals, runs)
A post-deployment phase where the same agent answers ongoing questions about the resource it deployed

You can have many active sessions across many agents. The Notifications feed alerts you when long-running things finish (e.g., a multi-minute terraform apply completes).

Cross-agent collaboration

Modern deployments touch multiple technologies. A Python web service needs a Postgres, a Redis, a load balancer, a CDN, observability.

The orchestrator’s agents handle this via handoffs at gate boundaries:

At Gate 3 (infra target) of the Python session, the Python agent asks the user for cloud + region
At Gate 4 (sizing), the Python agent asks Postgres specialist for recommended Postgres tier for the expected request volume
Postgres specialist replies with a tier recommendation + cited memory of similar customer setups
Python agent composes a multi-resource Terraform plan that includes both the Python service and a Postgres provisioned alongside

You see this as a normal chat — the cross-talk happens behind the scenes. The audit log records each agent that contributed to the session.

What agents won’t do

Each agent has explicit refusals — things it won’t touch even if asked:

The Postgres agent won’t disable PITR for production databases (hard rule per Postgres specialist’s “production hard rules” file)
The K8s agent won’t deploy a public LB to a pod without explicit network-policy review (security guardrail)
The Python agent won’t recommend hardcoding secrets in os.environ defaults (refers to the secrets specialist instead)
No agent deploys to a cloud account without an active connection (you must complete the connect flow first)

These refusals are intentional — they’re how we keep the platform trustworthy for production use. If an agent refuses something you think is legitimate, contact support — sometimes the rule is wrong.

Adding new agents

The platform currently ships ~140 specialists. New ones land regularly. The roadmap process:

Customer demand or competitor coverage gap identifies a candidate
Brainstorm → spec → plan → implementation (multi-day per agent)
New agent enters coming-soon state in the catalog while it’s being built
After hardening, it’s marked available

You can see what’s coming next at /roadmap.

Limitations to know about

Agents don’t talk to each other unprompted. Handoffs happen at gate boundaries or when you explicitly @mention them. There’s no autonomous multi-agent swarm.
Agents don’t write your application code. The Python agent deploys your service; it doesn’t write the service. The Postgres agent provisions the DB; it doesn’t write your schema.
Agents need an active cloud connection. Sessions are read-only until at least one cloud account is connected.