Skip to content

Guild.ai vs Orchestrator Zero

oz0 records agent jobs running on your infrastructure. Guild offers hosted agent infrastructure and proxy-based governance. oz0 provides a control plane you host, with outbound-only nodes, reviewed tool definitions and a verifiable audit trail.

What Guild.ai is

Guild.ai is a hosted control plane for AI agents, in open beta since April 2026. Teams build agents with its TypeScript SDK or bring Goose, OpenClaw and LangGraph agents, and Guild runs them on Google Cloud. Every model and tool call goes through a Guild proxy that holds the credentials, applies policies and budgets, and records the session.

docs.guild.ai
Runs
Managed service
Checked
27 October 2026

Side by side.

Guild.ai's ratings come from its own pages. A column's name opens its definition and how Orchestrator Zero does it. How we rated

Where it runs

Any machine you own

Yes

Docs

No: Runs in Guild's runtime

Agent code runs in Guild's own runtime; the docs describe no way to run agents on machines you choose.

docs.guild.ai guild.ai

Linux, macOS and Windows

Yes

Native; hosted-runner tested

Docs

No: Guild's cloud only

Agents run only in Guild's hosted runtime; there is no runtime for your own Linux, macOS or Windows machines.

docs.guild.ai

Self-hosted control plane

Yes

Docs

No: Hosted on Google Cloud

Guild is a hosted service on Google Cloud; no self-hosted, VPC or on-premises option is documented.

trust.guild.ai guild.ai

No inbound ports

Yes

Docs

No: API forwards to the runtime

Guild's API forwards each request to the runtime that runs the agent; no machine of yours runs agents.

docs.guild.ai

Fleet operations

Yes

Docs

No: Guild runs the compute

The runtime loads, runs and manages every agent; the docs have no machines to join, label, route to or block.

docs.guild.ai

Durability

Durable runs

Conditional

Depends on agent type

Docs

Conditional: TypeScript state machines

TypeScript agents using the state compiler can persist and resume at await boundaries after a runtime restart. Equivalent recovery is not documented for every supported agent runtime.

docs.guild.ai docs.guild.ai

Governance

Tool policy outside the model

Conditional

Harness coverage varies

Docs

Conditional: Allow and deny, no approve

YAML credential policies allow or deny each outbound call at Guild's proxy, by operation, domain, method, agent and workspace; new credentials start allow-all, and no rule sends a call to a person.

docs.guild.ai

Approvals in chat

Conditional

Tested against stand-ins only

Docs

Conditional: Agent asks; no call gate

An agent can ask the user a question with ui_prompt and wait for the answer; no rule makes a tool call wait for a person's approval, and no approvals reach a chat app.

docs.guild.ai

Tool snapshots

Yes

Docs

Conditional: Versioned, no change check

Integrations are versioned packages that agents name by semver range; no check or hold on a changed MCP tool definition is described.

docs.guild.ai docs.guild.ai

Tenants built in

Yes

Docs

Yes: Organizations, workspaces

Organizations hold workspaces. A workspace can be restricted to named members and organization admins, although shared agent, integration and runtime dependencies retain their own access rules.

docs.guild.ai

Cost

Budgets that stop a run

Yes

Set strict reservation

Docs

Yes: Monthly USD, blocks at 100%

Admins set monthly spend budgets per workspace, agent or user; Guild warns at 80% and blocks further LLM calls at 100%.

docs.guild.ai

Security

Provider keys off the workers

Yes

Docs

Yes: Credential proxy holds them

Service and model provider credentials are held server-side and added by Guild's proxy, so they never enter the agent's code, container or runtime.

docs.guild.ai

Sandbox with an egress allowlist

Conditional

Linux/macOS; Windows tier 0

Docs

Yes: Proxy only, domains by policy

An agent's container reaches only the Guild API, so outbound calls go through Guild's proxy, where credential policies can limit HTTP calls to hostname patterns.

docs.guild.ai docs.guild.ai

Audit and compliance

Tamper-evident audit trail

Yes

Keep trusted chain heads

Docs

Conditional: No documented check

Admins can read audit records of administrative actions and policy decisions, and entries cannot be edited or deleted through the product. A hash chain, signature or independent verification method is not documented.

docs.guild.ai

Erasure by key

Yes

Restore with erasure ledger

Docs

Not documented

Searched the docs for deleting a person's data, per-person keys and erasure: nothing found; the privacy policy says to contact Guild.

Retention with legal hold

Conditional

Capture needs source data

Docs

Not documented

Searched the docs for retention settings and legal hold: nothing found. Audit log entries cannot be modified or deleted.

Openness

Model provider choice

Yes

Docs

Conditional: Many vendors, no local

Managed Guild tokens, or your own keys for Anthropic, OpenAI, Google AI and Meta, with Bedrock, OpenRouter, Fireworks and Vertex AI when enabled; no local model is documented.

docs.guild.ai

MCP and A2A

Yes

Docs

Conditional: MCP, no A2A

Agents use MCP integrations, and the CLI serves Guild operations as MCP tools; A2A is not in the docs.

docs.guild.ai docs.guild.ai

Where Guild.ai is stronger.

  • Nothing to run yourself

    Sign up in the browser with Google, GitHub or an email link and start from chat; Guild runs the control plane and the agents.

    docs.guild.ai
  • An assistant that sets it up

    Smith, a built-in agent, builds and publishes agents, sets up integrations and triggers, and shows each policy change for approval before it writes.

    docs.guild.ai
  • Company-wide AI spend

    Spend Explorer imports spend from Anthropic, OpenAI and Cursor admin keys, so usage outside Guild shows next to Guild's own.

    docs.guild.ai
  • Version states for agents

    Each agent version moves from Saved to Validated, once it builds and matches its typed schemas, to Published, with semver bumps.

    docs.guild.ai
  • Integrations from OpenAPI, and a public API

    Custom integrations import their operations from an OpenAPI spec, and the platform has a public API with an OpenAPI spec and a WebSocket event stream.

    docs.guild.ai
  • SOC 2 reports listed

    Guild's trust centre now lists both SOC 2 Type 1 and Type 2 reports. Access to the reports themselves requires approval.

    trust.guild.ai

Full in Guild.ai, partial in oz0: Sandbox with an egress allowlist.

Differences to examine.

Compare the scope, conditions and editions in the source notes.

Using both

A Guild custom integration can point at an MCP server, and every Orchestrator Zero agent is an MCP tool, so a Guild agent could hand a step to one, if the edge is reachable from Guild's cloud.

Based on documentation; this pairing has not been tested.