Centaur: Best AI Agent Platforms for DevOps Teams in 2026

What Is Centaur?

Centaur is an AI agent platform built by Paradigm (paradigmxyz) for teams that want shared, Slack-driven agents instead of scattered local setups. Centaur is one of the best AI Agent Platforms tools for platform engineers, DevOps teams, and internal tooling teams because it routes work from Slack or API into a Kubernetes sandbox, persists transcripts in Postgres, and exposes at least four core agent endpoints: /agent/spawn, /agent/message, /agent/execute, and /agent/threads/{thread_key}/events.

The design target is clear: keep the agent close to real infrastructure, but keep the blast radius small. That means a real workspace, real commands, and controlled outbound access rather than a toy chat loop.

Quick Overview

Who Should Use Centaur?

• Platform teams building a shared agent layer that multiple engineers can call from Slack without each person running a separate local setup.
• DevOps and SRE teams that need an agent to inspect CI failures, query internal tooling, and run repeatable ops workflows inside a real repo workspace.
• Security-conscious orgs that need sandboxing, outbound control, and credential boundaries instead of handing raw API keys to every agent process.
• Internal tooling teams that want to standardize prompts, tools, workflows, and personas across the org without forking a dozen ad hoc scripts.

Not ideal for:

• Teams that want a managed SaaS with zero Kubernetes ownership.
• Solo developers who only need a local coding assistant and not a shared execution plane.
• Organizations that do not want to wire Slack, secrets, and cluster access together.

Key Features of Centaur

• Slack-native agent conversations — Mention the bot in Slack and the thread becomes the unit of work. Centaur posts progress and final results back to the same thread, which keeps the audit trail in the place people already work.
• Real execution environment — Each conversation runs in an isolated Kubernetes sandbox with a shell, workspace, git, Python, Node.js, Bun, and standard developer tooling. That matters when the agent needs to run tests, inspect files, or modify a repo instead of just generating text.
• Bring your own harness — Centaur can host CLI-based agents such as Amp, Claude Code, Codex, or a deployment-specific harness. This makes it a control plane, not a single-model product, which is a better fit when your org wants to swap agent runtimes without rewriting the platform.
• Shared tools as Python plugins — You define a tool once and expose it to every conversation. The tool contract is simple: public client methods become HTTP endpoints, so a search() method can become POST /tools/my_tool/search without custom glue for each agent.
• Durable workflows — Workflows can sleep, resume, wait for events, start child agents, and survive service restarts. That is the difference between a chat demo and an operational agent that can run a digest, wait for a signal, and continue later.
• Credential boundaries — Agents can access approved services without ever seeing raw API keys in their process environment. Centaur swaps placeholders for real values only on outbound requests through iron-proxy, which reduces the number of places secrets can leak.
• Replayable state — Messages, executions, events, and delivery state are persisted so clients can reconnect without losing the result. This is useful when Slack delivery fails, a browser tab closes, or the agent needs to be resumed by another worker.
• Organization overlays — You can layer in your own tools, workflows, personas, skills, and prompts without forking the base platform. That is a practical way to keep one upstream while still tuning behavior for different teams.

Centaur vs Alternatives

Pick Centaur when you need one shared agent surface for a team and you care about state, auditability, and controlled tool access. Pick OpenSwarm when the main problem is agent-to-agent coordination rather than Slack delivery and sandbox governance.

Choose Claude Code Canvas if the main workflow is a human sitting inside an agent workspace and steering code changes directly. Choose Claude Context Mode when the problem is prompt hygiene or context composition rather than running real jobs in Kubernetes.

How Centaur Works

Centaur uses a control-plane-plus-sandbox model. The control plane lives in services/api and handles auth, durable state, tool registration, and workflow execution, while services/slackbot receives Slack events and delivers responses back to threads. The sandbox runtime in services/sandbox provides the agent container image and the harness adapter, so the actual work happens in an isolated environment rather than inside the web process.

The platform stores transcripts and execution events in Postgres, then assigns or reuses a sandbox when a thread needs to run. Tools live under tools/, workflows live under workflows/, and outbound access is mediated by iron-proxy, which keeps secrets out of the agent process and injects them only for approved hosts and headers.

A simple API-driven turn looks like this:

POST /agent/spawn
POST /agent/message
POST /agent/execute
GET /agent/threads/{thread_key}/events

Those calls are enough to assign a sandbox, persist the user turn, start execution, and stream back events. In practice, that means a Slack mention or a direct API request can trigger the same durable job model, which is exactly what you want when building a Centaur tutorial for team use instead of a one-off demo.

Pros and Cons of Centaur

Pros:

• True sandboxed execution with a shell, workspace, git, and common runtimes, so the agent can do real work instead of only drafting output.
• Slack-first workflow keeps the human interface where engineers already coordinate work.
• Durable state makes agent runs restartable and reconnectable, which is important for long jobs and flaky delivery paths.
• Tool registry and workflow registry create a clean plugin model for internal services and recurring jobs.
• Secret boundaries reduce the risk of exposing raw credentials to the agent runtime.
• Harness-agnostic design makes it easier to swap CLI agents without rebuilding the platform.

Cons:

• Requires Kubernetes and the operational overhead that comes with a real cluster.
• Slack and secrets setup are non-trivial, especially for first-time local bootstraps.
• The platform is opinionated around team workflows, so it is heavier than a single-process local assistant.
• Licensing and hosted-service options are not obvious from the page text, so teams need to inspect the repo before standardizing on it.
• Outbound access is intentionally controlled, which is good for safety but adds integration work for every approved service.

Getting Started with Centaur

The fastest path is to clone the repo, install the local task runner, set the required secrets, then boot the stack. Centaur expects a Kubernetes-based local environment and a Slack app, so the first run is more like standing up infrastructure than installing a CLI.

git clone https://github.com/paradigmxyz/centaur
cd centaur
brew install just

export OP_SERVICE_ACCOUNT_TOKEN=...
export OP_VAULT=...
export SLACK_BOT_TOKEN=...
export SLACK_SIGNING_SECRET=...
export SLACKBOT_API_KEY=...

just bootstrap-secrets
just up

After just up, the Slackbot and API services can accept turns, and you can test a full agent round trip from Slack or via the documented API flow. The only initial configuration that really matters is wiring Slack credentials and the 1Password-backed secret source, because Centaur depends on both for runtime access and outbound secret injection.

Verdict

Centaur is the strongest option for teams that want a shared, auditable agent platform when they are willing to run Kubernetes and own the integration layer. Its biggest strength is durable Slack-native execution with sandboxing and secret boundaries; its main caveat is operational complexity. If your team needs that control plane, Centaur is worth adopting.