Archestra
A unified control plane for enterprise model access, MCP tools, agent execution, security, and observability.
The material shows user-scoped OBO identity, RBAC, per-environment egress and cost controls, secrets management, sandboxing, and tool-call guardrails. Workflows use empty top-level permissions, narrowly scoped job permissions, commit-pinned actions, input allowlists, and short-lived credentials. Deductions reflect the quickstart's Docker-socket mount, mostly asserted confirmation behavior, a destructive-command fixture that catches only a narrow rm -rf pattern, and incomplete data-flow and rollback documentation. Repository and contributor attribution are visible, but publisher identity remains unverified by the stated registry.
The README, license router, and workflows are broadly consistent about the platform, deployment model, and security posture. The benchmark workflow provides concrete diagnostics for overlap, missing images, incompatible cluster versions, scheduling failures, and fast failures, fully supporting the failure-messages score. Deductions reflect reliance on containers, Kubernetes, cloud identity, model providers, and connectors without demonstrated degradation or offline strategies, while product-wide consistency is supported mainly by descriptive material.
The source explicitly addresses non-technical users, developers, platform teams, and enterprise operators across chat, gateways, registries, orchestration, RAG, schedules, email, webhooks, and A2A scenarios. Trigger types and benchmark input constraints are precise. Deductions reflect boundaries expressed mainly as feature lists with few unsupported-case statements, plus environment assumptions such as Docker-socket access and benchmark-specific GKE, GAR, and GCS configuration despite broader Docker, Helm, and Kubernetes options.
The README has clear organization and routes readers to quickstart, deployment, security, contribution, and release material. The license router thoroughly defines AGPL and enterprise scope through SPDX headers, regions, paths, and a default rule, justifying full license marks. Deductions reflect brief local installation detail, use of a latest image tag, limited examples and no visible FAQ, little consolidated limitations documentation, and only partially established maintenance responsibility given the unverified publisher.
Combining LLM, MCP, and A2A gateways with an agent runtime, identity controls, guardrails, observability, registry, and orchestration provides strong integration value. The described outputs serve chat users, developer clients, and platform operations, supporting high usability and marginal-value scores. Cost-benefit is reduced because pricing, funding, deployment-count, and latency statements are not sufficiently substantiated within the supplied files, and operational cost and complexity are not quantified.
Several engineering and security claims trace to concrete workflow behavior, including scoped permissions, commit pinning, input validation, fail-closed checks, cleanup, and secret injection. The licensing claim is independently supported by the license-router file. Deductions reflect that most platform features, Fortune-50 deployments, funding, and p95 performance appear only as README claims without supplied cross-source support, and marketing statements are not consistently separated from demonstrated facts or inference.
- The quickstart mounts the host Docker socket into the container; assess its host-level privilege implications and prefer an isolated or narrower-privilege deployment before adoption.
- Do not accept the funding, Fortune-50 deployment, 31 ms p95, sandbox, or guardrail claims solely from the README; the supplied material does not provide enough internal corroboration.
- The dual license uses first-match SPDX, snippet, and path rules; verify the effective license file by file before modification or redistribution.
- The sample PreToolUse hook blocks only one obvious rm -rf / form and should not be treated as comprehensive destructive-command protection.
- The latest container tag weakens deployment reproducibility; production deployments should pin an immutable version or image digest.
What does this agent do, and when should you use it?
Archestra is a self-hostable enterprise AI platform combining chat interfaces, LLM and MCP gateways, an A2A gateway, a private MCP registry, an orchestrator, and an agent runtime. Non-technical users can access internal assistants through its chat experience, Slack, Microsoft Teams, or email, while developers can connect Claude Code, Codex, and Cursor with one managed token. Its LLM gateway supports providers including Anthropic, OpenAI, Azure, Bedrock, and DeepSeek, with virtual API keys, spending limits, and dynamic model routing. Agents can start from schedules, email, webhooks, or A2A triggers, delegate to sub-agents, reuse skills, execute code in sandboxes, and work with a Kubernetes-native filesystem. The deployment boundary remains under the adopter's control through Docker, Helm, or Kubernetes paths, while operational output includes OpenTelemetry traces, Prometheus metrics, logs, and per-team cost data.
Users, agents, Claude Code, Codex, and Cursor connect to a common Archestra endpoint. The LLM gateway routes their requests to configured model providers while enforcing virtual API keys, cost limits, and dynamic model selection. The MCP gateway invokes tools with OAuth and On-Behalf-Of identity, the private MCP registry distributes internal tools, and the MCP orchestrator works with a Kubernetes operator to deploy them and promote them between environments. The Agent runtime handles scheduled, email, webhook, and A2A triggers, then runs reusable skills, delegated sub-agents, and sandboxed code; knowledge connectors can feed a RAG knowledge base. Deterministic tool-call policies, Dual-LLM verification, and Lethal Trifecta protections guard execution, while OpenTelemetry traces, Prometheus metrics, logs, and team-level cost records expose the results operationally.
- An enterprise platform team needs to provide internal AI assistants to several departments while controlling access with SSO, RBAC, role mapping, and team synchronization.
- A development organization wants Claude Code, Codex, and Cursor to share one governed endpoint and token instead of distributing provider credentials to every developer.
- A security team needs MCP tools to execute with each user's identity and wants deterministic tool policies, Dual-LLM verification, and Lethal Trifecta protections.
- An infrastructure team wants to deploy internal MCP services through Docker, Helm, or Kubernetes and manage them through a private registry and environment-promotion workflow.
- An operations team needs agents triggered by schedules, email, webhooks, or A2A requests, with traces, metrics, logs, and cost tracking for oversight.
- A knowledge team wants to connect existing systems to a RAG knowledge base that can be used by internal assistants and agents.
What are this agent's strengths and limitations?
- It combines an LLM gateway, MCP gateway, A2A gateway, private registry, Kubernetes orchestrator, and agent runtime instead of requiring separate control-plane products.
- Its documented identity and security surface includes OIDC, SAML, Okta, Entra, RBAC, team synchronization, On-Behalf-Of tool calls, sandboxing, and multiple guardrail mechanisms.
- It explicitly supports multiple providers, including Anthropic, OpenAI, Azure, Bedrock, and DeepSeek, alongside routing, virtual keys, and cost controls.
- It serves both business users and developers through built-in chat, Slack, Microsoft Teams, email, Claude Code, Codex, and Cursor entry points.
- OpenTelemetry traces, Prometheus metrics, logs, and per-team cost accounting are built in, with Docker, Helm, Kubernetes, and Terraform-related deployment paths.
- The quickstart mounts /var/run/docker.sock, which broadens the container's access to host-side Docker capabilities and requires a security review.
- Using the full platform introduces several integration and operational layers, including model providers, MCP, identity systems, connectors, and potentially Kubernetes.
- The supplied material names production deployment options but only provides a complete Docker quickstart, not copyable Helm, Kubernetes, or Terraform configuration.
- The pricing model is Open Core: teams under 30 users are described as free, while enterprise licensing also exists, so larger adopters must verify cost and feature boundaries.
- Repository metadata reports the license as NOASSERTION, while the README badge says AGPL 3.0 / Enterprise; adopters should verify the governing license file and applicable terms.
How do you install or deploy this agent?
A host capable of running Docker is required. Run:
docker pull archestra/platform:latestdocker run \
-p 127.0.0.1:9000:9000 -p 127.0.0.1:3000:3000 \
-e ARCHESTRA_QUICKSTART=true \
-e ARCHESTRA_BETA=true \
-v /var/run/docker.sock:/var/run/docker.sock \
-v archestra-postgres-data:/var/lib/postgresql/data \
-v archestra-app-data:/app/data \
archestra/platformOpen http://localhost:3000 afterward. This quickstart mounts the Docker socket and creates persistent volumes for PostgreSQL and application data. Helm, Kubernetes, and Terraform-related production paths are named, but the supplied material does not contain copyable installation commands for them.
How do you use this agent?
After starting the container, open http://localhost:3000; this is the first working invocation documented in the supplied material. Configure a model provider, then use the platform proxy and its shared token with Claude Code, Codex, or Cursor. The exact token-creation command, credential variable names, and provider setup sequence are not included in the material. Tools can be connected through the MCP gateway or published through the private MCP registry, while automated agents can be configured around schedule, email, or webhook triggers. A production rollout should also configure SSO/RBAC, secrets, environment-specific egress rules, and spending limits, although complete configuration examples are not supplied.