CI-deployed agents

Instead of letting the platform build an agent's image, you can build it in your own CI pipeline and deploy the finished image to a workspace with the initializ CLI. The platform never sees your repository or the image internals — your pipeline builds, the platform deploys.

See the CLI deploy reference for pipeline setup and the deploy command.

How a CI deploy works

Each deploy upserts by workspace + agent name: the first deploy creates the agent record, and every later deploy for the same name in the same workspace updates it and rolls the running deployment to the new image. This makes the deploy step idempotent — safe to re-run on every push to your release branch.

A few behaviors worth knowing:

• Same-tag redeploys still roll the workload, so re-pushing a mutable tag (like latest) picks up the new image.
• An image digest can be supplied to pin the exact image content regardless of tag.
• The deploy carries metadata from your repository — declared skills, model, egress, channels — for display and policy purposes. The actual runtime behavior is whatever is baked into your image.
• CI deploys appear in the console with the same build status and progress logs as platform-built agents, and the agent shows up on the Agents list like any other.

What "managed by CI" means

A CI-deployed agent's configuration is owned by its repository, so the console locks everything that would be baked into the image:

• Locked in the console: skills (including the skill builder and skill edits), model provider, channels, policies, guardrails, and platform-triggered rebuilds. Attempts are rejected — change these in the repo and deploy again from CI.
• Still open in the console: environment values and secret rotation. Rotating a credential patches the agent's secret and restarts it — no new CI run needed.

Everything else about operating the agent is unchanged: health and failure diagnostics, the Activity, Logs, and Usage tabs, Diagnose, chatting from the Overview tab, and participation in workflows.