Capabilities

Define, run, connect, observe, and govern agents from one platform.

Deployments.ai covers the whole life of an agent: versioned definitions, model access, tools, sandboxes, channels, durable workflows, telemetry, spend, and governance. Every capability shares the same organization, project, and environment model and is reachable through one /v1 API and the deployments CLI.

Deployments.ai is pre-release; the capabilities below run in the platform's development environment today.

01 / 12

Agent-as-code

Agents are JSON manifests validated against one schema and published as immutable releases. Deployments pin a release per environment, so every run records exactly which definition it executed.

  • SHA-256 content hashes
  • Canary weights 1–99
  • Promotion without rebuilds

Versioned manifests

AgentManifestV1 (apiVersion agents.deployments.ai/v1) declares instructions, model, tools, memory, sandbox, and triggers. YAML and TypeScript definitions compile to the same schema, with no templating language.

Immutable releases

Publishing creates a numbered release whose contentHash is the SHA-256 of the canonical manifest JSON, computed server-side. Runs pin that release, and in-flight or approval-waiting runs never switch releases.

Previews with deployments dev

deployments dev agent.json runs an unpublished manifest on the hosted worker without creating a definition, release, or deployment. Previews expire after a TTL (default 24 hours) and skip durable memory writes, webhooks, and channels.

Deployments and rollback

A deployment pins one primary release, and deployment rollback --to retargets it to an earlier one. Credentials and tool policies live on the deployment config, never in the release.

Thread-sticky canaries

Route 1–99% of threads to a candidate release, with assignment kept sticky per thread. Promote or abort the canary when you have seen enough.

Cross-environment promotion

deployments release promote --target-environment copies the identical hashed manifest into another environment of the same project. Credentials, bindings, and schedules are not copied, so each environment keeps its own.

Nested sub-agents

A manifest can declare up to 16 sub-agents, nested up to 4 levels deep, bound per deployment through agentBindings.

02 / 12

Model gateway

Every model call goes through a private gateway that holds the provider keys, so agent workers never see them. Each environment decides which models its agents may use.

  • OpenAI, OpenRouter, Bedrock
  • Short-lived signed tokens
  • Per-environment model policy

Three hosted providers

Reference models by openai/, openrouter/, or bedrock/ ids, including Bedrock inference profiles. Manifests can list fallback model ids.

Environment model policies

Policies admit exact model ids or whole provider prefixes such as openrouter/*. The worker re-checks the policy on every run, and the model catalog syncs every 6 hours.

Keys stay in the gateway

Provider keys are held by the gateway, which is built on Bifrost. Agent workers and sandboxes never receive them.

Signed short-lived tokens

Each call carries a KMS-signed token that lasts 10 minutes for runs and 15 minutes for services. The gateway forwards only chat completions, embeddings, and responses requests.

Structured outputs

Releases can declare a JSON-schema response format, with schemas up to 64 KiB and outputs up to 256 KiB. OpenAI and OpenRouter use native response_format; Bedrock gets schema instructions plus local validation.

Curated defaults

Environments without a policy get a curated list of OpenAI and OpenRouter models. Bedrock models are admitted through explicit policies.

03 / 12

Tools and integrations

Agents call tools from a shared catalog, vendor-hosted MCP servers, your own MCP servers, your client app, or your HTTP endpoints. Connections are authorized and synced per environment.

  • 130+ vendor MCP servers
  • 170+ catalog providers
  • Writes require approval

Integration catalog

170+ providers in the catalog, including GitHub, Notion, Linear, Sentry, Gmail, Google Drive, Jira, Confluence, Zendesk, and ServiceNow. Tools whose apps are not yet configured stay archived and deny-by-default.

Vendor MCP servers

130+ vendor-hosted MCP servers connect over Streamable HTTP, with per-environment tool sync and hash-drift checks. Write tools require approval by default.

Custom MCP servers

Point an agent at your own HTTPS MCP server. Calls time out after 60 seconds by default.

Client-executed tools

Register an extension with execution type client and the run pauses until your app submits the tool output through the SDK. Client tools are available to API-triggered agents.

HTTP callbacks

Call your own HTTPS endpoints as tools. Callback URLs that resolve to private or reserved addresses are rejected.

Hosted functions

Upload JavaScript, TypeScript, or Python artifacts with deployments tool upload. Each call runs in a MicroVM with its declared secrets and no network access.

Connection OAuth

deployments connection authorize --provider <key> runs the OAuth flow with PKCE, refresh, and revoke. Tokens go into the credential vault, never into manifests or model context.

04 / 12

Code sandboxes

code.execute runs Bash, JavaScript, and Python inside AWS Lambda MicroVMs. Workspaces can be scoped to one run or persist across a thread.

  • Lambda MicroVMs
  • Bash, JavaScript, Python
  • 5 GiB thread workspaces

MicroVM isolation

Code runs in AWS Lambda MicroVMs, the default sandbox host. Timeouts range from 100 to 50,000 ms, with source up to 20 KiB.

Run-ephemeral workspaces

Sandbox mode run-ephemeral gives each run its own workspace, scoped to that single run.

Thread-persistent workspaces

Sandbox mode thread-persistent snapshots /workspace, up to 5 GiB, between runs in the same thread. It adds sandbox.files.read, write, and list tools.

No network for hosted code

Hosted function artifacts run with network set to none and fail closed.

Secrets at execution only

Hosted code declares secretNames, and values are injected into the MicroVM only at execution time. Secret values are checked never to appear in tool calls, messages, artifacts, or the thread stream.

Metered compute

Sandbox time, vCPU, and memory are recorded in the usage ledger alongside model tokens.

05 / 12

Web and browser tools

A self-hosted web tools service gives agents search, scraping, crawling, and parsing, and headless Chromium handles screenshots. Requests to private addresses are refused.

  • Search, scrape, crawl
  • Private egress denied
  • Approval-gated sessions

Search and scrape

Search runs through a self-hosted SearXNG instance. Scrape fetches single pages or batches of up to 100 URLs, with responses capped at 25 MiB.

Crawl, map, and parse

Crawl up to 100 pages per job, map a site's URLs, or parse content from artifacts already stored on the run.

Renderer choice

Choose renderer auto, lightpanda, or chromium per request. Lightpanda is the default, with Chromium as the fallback.

Egress controls

Only public addresses on ports 80 and 443 are reachable. Private and reserved IPs are denied to prevent SSRF.

Page screenshots

browser.screenshot.capture renders pages in headless Chromium at mobile, tablet, desktop, or wide viewports. Up to 4 screenshots per generation can be attached for the model to see.

DOM snapshots

browser.dom_snapshot.capture fetches a page over HTTPS and returns up to 2 MiB of HTML.

Approval-gated sessions

browser.session.plan and browser.session.execute run scripted sessions of 1–16 actions, and both require approval. There is no arbitrary JavaScript evaluation.

06 / 12

Memory and Native Brains

Agents keep portable memory across threads and draw on organization knowledge through Native Brains. Memory is canonical in DynamoDB, with search on AWS OpenSearch.

  • Typed memories
  • Cited Brain answers
  • Hosted Brain MCP

Memory tools

agent.memory.save and agent.memory.search let agents write and recall memories. Active recall is supplemental: if it times out, the run continues without it.

Typed memories

Memories are stored as facts, preferences, episodes, procedures, or summaries.

Retrieval strategies

Choose dense-v1 (the default), hybrid-rrf-v1, or hybrid-rerank-v1 over a search placement dedicated to each organization.

Grants and mounts

Native Brains hold organization knowledge behind explicit grants. A deployment mounts the Brains an agent may read from or propose writes to, and a mount never overrides the caller's live access.

Cited answers

Agents use brain.search, brain.get_document, and brain.ask, which answers with citations to stored document versions.

Hosted Brain MCP

/v1/mcp/brain exposes Brains as an MCP server authenticated with platform identity.

GitHub connector

GitHub is the managed Brain connector, ingesting repository content through the GitHub MCP OAuth connection.

07 / 12

Channels and agent email

Slack, Telegram, RCS, and email all land on the same thread and run model as API calls. Agents can have their own inboxes on a hosted domain or yours.

  • Slack, Telegram, RCS
  • Agent inboxes
  • Custom email domains

Slack and Telegram

Signed inbound events and outbound replies on Slack and Telegram, handled by the channel adapters.

RCS messaging

Rich messaging through AWS End User Messaging RCS, with the same signed ingress and outbound path.

One thread model

Every channel converges on the same canonical thread and run as API and email traffic, so history, tools, and approvals behave the same everywhere.

Agent inboxes

Give an agent an address on the hosted agent email domain, or on your own domain after a _agent-email TXT record proves ownership.

Inbound and outbound mail

Inbound MIME messages start agent runs, and outbound mail sends through Amazon SES. New senders move through warmup stages before full volume.

Send-only email API

/v1/email sends messages without an inbox, up to 50 recipients and 1 MiB bodies per send.

08 / 12

Workflows and approvals

Durable workflows, schedules, and heartbeats run agents without anyone at a keyboard. Approvals pause a run until a person decides.

  • Durable workflows
  • Approval deadlines
  • Versioned artifacts

Durable workflows

Workflows are built from agent, deterministic tool, approval, notification, branch, escalation, and end steps.

Schedules and heartbeats

/v1/schedules and /v1/heartbeats trigger agents on a timer, with pause, resume, and manual fire controls.

Approvals with deadlines

Tool and workflow approvals pause the run until someone responds, with deadlines enforced by EventBridge Scheduler. Client, browser, and vendor MCP write tools require approval by default.

Versioned artifacts

Runs produce versioned artifacts. Up to 8 private media artifacts (JPEG, PNG, WebP, WAV, or MPEG, 10 MiB each) can be passed to the model.

Context management

Transcripts stay complete while the model sees a packed view assembled from memory, Brain results, checkpoints, recent messages, and artifacts.

Loop limits

Each run caps model generations (1–32, default 16) and tool calls (1–64, default 29), with up to 8 parallel tool calls per generation.

09 / 12

Streaming and events

Live run output streams to clients over SSE, and every customer-visible state change becomes a semantic event. Events reach EventBridge and signed webhooks.

  • SSE streams
  • Transactional events
  • HMAC-signed webhooks

Durable Streams

A stream session returns a short-lived token and stream URL, and tokens and tool activity stream over SSE. Connections close about every 50 seconds and clients resume where they left off.

Transactional semantic events

Each state change writes a semantic event in the same DynamoDB transaction as the resource it describes, so the event and the change commit together.

EventBridge delivery

Events publish to EventBridge with source deployments-ai.platform and a 30-day archive. Delivery is at-least-once; consumers dedupe by eventId and order by aggregateVersion.

Signed webhooks

HTTPS endpoints receive HMAC-SHA256 signed payloads, with up to 100 endpoints per environment and a 15-second timeout.

Retries and auto-disable

Failed deliveries retry up to 10 times with jitter over roughly 4 to 8 hours. Endpoints disable after 20 consecutive failures.

Secret rotation

Signing secrets are shown once and rotate with an overlap window of up to 7 days, 24 hours by default.

10 / 12

Observability and evaluations

Every hosted run produces a trace covering model calls, tools, memory, sandboxes, approvals, tokens, and cost. Evaluations score runs against datasets and compare releases.

  • Metadata-only by default
  • Dataset replays
  • Advisory release comparisons

Traces and spans

W3C-shaped traces are queryable by run or thread, and child runs share the root trace. Spans are kept for 30 days and trace summaries for 90.

Metrics and tool stats

Metrics cover windows up to 31 days, with hourly grouping up to 7 days, plus top tools by call count through the API or deployments observability.

Capture modes

Capture defaults to metadata-only, which keeps prompt and tool bodies out of the analytics store. redacted-content and full-content are opt-in.

Trace exports

POST /v1/observability/exports packages traces for analysis outside the platform.

Built-in evaluators

Score runs with contains, not_contains, regex, json_schema, tool_called, no_tool, model_judge, human, or imported evaluators. Scores fall in [0,1] and pass at a configurable threshold.

Datasets and replays

Regression datasets hold up to 500 cases. Replays run in isolated execution bindings and never touch production runs.

Advisory release comparisons

Compare a baseline and candidate release on mean score, pass rate, and new failures. Verdicts are advisory and do not block deployments.

11 / 12

Usage and budgets

Each install meters itself from its own usage ledger, with no third-party billing in the loop. Budgets at organization, project, or environment scope refuse new runs once exhausted.

  • Self-metered ledger
  • Org, project, environment
  • Threshold events

Usage ledger

Model tokens are recorded with their USD cost. Sandbox time, agent email, Brain retrieval, and worker time are counted alongside them.

Costs and spend APIs

/v1/usage, /v1/costs, /v1/spend, and per-API-key usage endpoints, mirrored by the deployments usage, cost, and budget commands.

Scoped budgets

Set up to 25 budgets per organization, project, or environment over daily, monthly, quarterly, or yearly UTC periods.

Budget thresholds

Each budget takes up to 10 thresholds (50, 80, and 100 percent by default), and each emits a budget.threshold-crossed event once per period.

Run admission

An exhausted active budget refuses new runs with HTTP 429 budget_exhausted. Runs already in progress are not interrupted.

12 / 12

Security and governance

Tenancy, identity, credentials, and data lifecycle are part of the platform, not something each agent adds. Each environment is the isolation boundary for credentials, deployments, and usage.

  • Hashed API keys
  • KMS-encrypted vault
  • Signed audit exports

Tenancy isolation

Organization, project, and environment scopes are checked against live membership on every request, not stale token claims. Production credentials cannot be used by development service accounts.

Platform identity

People sign in through a platform-owned OAuth/OIDC issuer with PKCE and rotating refresh tokens. The CLI signs in with the RFC 8628 device flow.

Roles and API keys

Organization roles are owner, admin, billing, member, and viewer. Service-account API keys are scoped to one environment and stored only as SHA-256 hashes.

Credential vault

Secrets are encrypted with AES-256-GCM under KMS envelope keys bound to organization, project, environment, and purpose. Inventory APIs never return secret material.

Data retention

Threads, messages, runs, artifacts, and events default to 365 days, configurable from 1 to 3650. Audit records default to 2555 days.

Tenant export and erasure

Exports produce deterministic NDJSON. Erasure needs the owner role, an explicit confirmation, and a signed token, and purges platform stores and search indexes; backups and provider copies are not erased immediately.

Signed audit exports

Audit exports are SHA-256 hash-chained JSONL with an ECDSA P-256 manifest signed in KMS and kept under S3 Object Lock, so anyone can verify them independently.