The platform

The control plane for production agents: define, publish, deploy, trigger, run.

Tenancy

A hierarchy built for products with many customers

Every resource lives in a clear hierarchy. Billing and membership sit on the organization, a project groups a product, and an environment is the boundary for credentials, deployments, usage, and production isolation.

  1. 01

    Organization

    Billing, membership, roles, and audit.

  2. 02

    Project

    One product or line of agents.

  3. 03

    Environment

    Credentials, deployments, usage, and isolation. Production credentials can't be used by development service accounts.

  4. 04

    Deployment

    Pins a release with environment-specific credentials and tool policies.

  5. 05

    Release

    An immutable, content-hashed agent manifest.

  6. 06

    Thread & run

    Every conversation and execution, pinned to the release it started on.

Agents as code

One manifest describes the whole agent

Instructions, model and fallbacks, memory, tools, sandbox, and triggers live in a versioned JSON manifest. YAML, TypeScript, and the console all compile to the same schema — no templating language, and credentials never live in the release.

  • Triggers: API, chat, email, schedules, heartbeats, webhooks, and workflows
  • Sandbox modes: none, run-ephemeral, or thread-persistent
  • Loop limits per run: up to 32 model generations and 64 tool calls
  • Up to 16 sub-agents, nested four levels deep
agent.json
{
  "apiVersion": "agents.deployments.ai/v1",
  "kind": "Agent",
  "metadata": {
    "key": "example.assistant",
    "name": "Example Assistant",
    "version": "1.0.0"
  },
  "spec": {
    "instructions": "Use the declared capabilities to complete the request.",
    "model": {
      "id": "openrouter/default",
      "fallbackIds": ["openrouter/fallback"]
    },
    "memory": { "mode": "workspace" },
    "capabilities": {
      "tools": [{
        "authorization": "workspace",
        "name": "records.read",
        "required": true,
        "requiredScopes": ["records:read"]
      }]
    },
    "runtime": { "modelTools": ["records.read"] },
    "sandbox": { "mode": "none" },
    "triggers": ["api", "schedule", "workflow"]
  }
}

Releases & deployments

Version agents like software, and roll out like it too

Immutable releases

Publishing a draft creates a numbered release. Its content hash is the SHA-256 of the canonical manifest, computed server-side.

Canary rollouts

Send 1–99% of new threads to a candidate release. Assignment is thread-sticky, so a conversation never switches mid-flight.

Retarget and roll back

Point a deployment at a different release in one call. Runs that are in flight, paused, or waiting on approval keep their release.

Cross-environment promotion

Promote the identical hashed manifest from development to production without a rebuild. Credentials and bindings stay with each environment.

Preview runs

Run an unpublished manifest on the hosted worker for up to seven days, isolated from durable memory, webhooks, and channels.

Release comparisons

Replay regression datasets against a baseline and a candidate release and compare scores before you promote.

Runtime

Every entry point lands on the same thread and run

An API call, a Slack message, an inbound email, a schedule, or a webhook all become a run on a thread — with the same tool loop, approvals, memory, streaming, and traces.

  • Up to 8 parallel tool calls per model generation
  • Context packing keeps full transcripts while the model sees a focused view
  • Runs pause for approvals or client-executed tools, then resume
  • Live tokens stream over Durable Streams; messages are canonical

Triggers

  • API
  • Chat
  • Email
  • Schedule
  • Heartbeat
  • Webhook
  • Workflow
  • Slack
  • Telegram
  • RCS

thread → run

Same tool loop, approvals, memory, streaming, and traces for every entry point.

Developer surface

One public contract: API, SDK, and CLI

Public API

360+ operations across tenancy, agents, runtime, memory, Brains, email, tools, evaluations, usage, and governance.

CLI for everything

Every public operation has a CLI command, plus local previews, OpenAPI export, and tool uploads.

SDK

A TypeScript SDK on the same contract, including client-executed tool outputs and agent email.

Platform identity

OAuth and OIDC with PKCE, rotating refresh tokens, device authorization for the CLI, and environment-scoped API keys.

A single composed OpenAPI contract is the product boundary. The CLI covers every public operation, and humans sign in through a platform identity issuer with device flow for the terminal.

terminal
# Run an unpublished agent on the hosted worker
$ deployments dev agent.json --message "Summarize ticket 812"

# Promote the identical release to production
$ deployments release promote --target-environment "$PROD_ENVIRONMENT_ID"

# Connect a vendor MCP app
$ deployments connection authorize --provider <key>

# Inspect what an agent did
$ deployments trace list

Infrastructure

OpenTofu-provisioned, on AWS building blocks your team knows

One reusable OpenTofu stack deploys the platform into a dedicated AWS account per environment. A single deploy tool ships the OpenTofu stack, container images, and functions into the account described by a target file — ours, or yours.

  • Isolation between environments is an AWS account boundary, not a name prefix
  • Canonical state in DynamoDB and KMS-encrypted S3; ClickHouse is a rebuildable read model
  • Container images tagged by commit and pinned by digest
  • No Postgres in the target architecture
  • Lambda
  • ECS on Fargate
  • DynamoDB
  • S3 & S3 Tables
  • KMS
  • EventBridge
  • Kinesis
  • SQS
  • API Gateway
  • OpenSearch
  • SES
  • CloudFront
  • Route 53
  • CloudWatch