Sign in
Community

Community

Welcome to the
Guild

Where builders think together. Not in isolation. Not in silos. But as a Guild—like the ones that came before.

The original guilds weren't just groups. They were systems of craft. People sharing techniques, refining tools, raising the standard of the work itself. Guild brings that model into software.

Guild community collage

Guilds used to be local. Now they're everywhere.

Across cities, across disciplines, across domains—connected by shared standards, not proximity. We host Guild Forge all over the world, IRL and virtually. And just like the guilds of yore, we have our shields, our anvils, our swag, and your Guild ID.

Find a Forge near you.
The Guild meets in cities around the world. IRL and virtually.

San Francisco

San Francisco

COMING SOON
New York

New York

COMING SOON
London

London

COMING SOON
Toronto

Toronto

COMING SOON
Sydney

Sydney

COMING SOON
Berlin

Berlin

COMING SOON

Start Building in Minutes
Deploy your first agent, scope permissions, connect your stack. Real code, real governance.

Deploy a Starter Agent
Get running in under 5 minutes

terminalShell
# Install the Guild CLI
$ npm install -g @guild/cli

# Initialize your workspace
$ guild init my-workspace

# Deploy a code review agent
$ guild deploy agent/code-review \
    --scope github:my-org \
    --budget $50/day

# Agent deployed. Monitoring active.
✓ code-review-agent is live
View quickstart guide

Define Governance Rules
Permissions, budgets, policies as code

guild.config.yamlYAML
# guild.config.yamlgovernance:  budget:    daily_limit: $100    alert_threshold: 80%
  permissions:    - role: developer      actions: [deploy, test]      scope: workspace
    - role: admin      actions: [deploy, test, govern]      scope: organization
  audit:    retention: 90d    export: s3://guild-logs
Explore governance docs

From the Discord community

xhale22b_35008

Is task.env.create() / task.env.exec() available in the current SDK? We need to run a Node.js shell command from inside an agent's run() function. We're hitting the Babel state machine limitation with native https module calls.

Visit Discord
Jedweb3

Amazing workshop and use cases. looking forward to the recordings.

Visit Discord
xhale22b_35008

Is task.env.create() / task.env.exec() available in the current SDK? We need to run a Node.js shell command from inside an agent's run() function. We're hitting the Babel state machine limitation with native https module calls.

Visit Discord
Jedweb3

Amazing workshop and use cases. looking forward to the recordings.

Visit Discord
G.ID 8278
BUILDING IN41.8832° N 87.6324° W
G.ID 4512
BUILDING IN37.7749° N 122.4194° W
G.ID 9103
BUILDING IN51.5074° N 0.1278° W
G.ID 2847
BUILDING IN40.7128° N 74.0060° W
G.ID 6391
BUILDING IN48.8566° N 2.3522° E
G.ID 7024
BUILDING IN35.6762° N 139.6503° E
G.ID 1856
BUILDING IN52.5200° N 13.4050° E
G.ID 5439
BUILDING IN43.6532° N 79.3832° W
Guild ID Badge

Claim your Guild ID
Every member gets their shield.

APPRENTICE
APPRENTICE
BUILDER
BUILDER
ARTISAN
ARTISAN
MASTER
MASTER

Early Access

First look at new features, agents, and integrations before they ship.

Direct Access

Private channel with the engineering team. Your feedback shapes the product.

Questions?
Start here.

An agent control plane is the infrastructure layer that governs AI agents in production. Guild's is built on four primitives: workspaces that contain agents and their policies, organization-level credentials injected at runtime, sessions that log every run, and triggers that automate execution. Without one, every agent holds its own keys, runs without an audit trail, and spends without attribution. A control plane replaces that sprawl with one place to see, control, and account for every agent.

Guild scopes access structurally rather than by role labels. Credentials are connected once at the organization level and injected at execution time, so agents never hold raw keys. Workspace-level policies decide which teams and agents can use which integrations: a support workspace cannot reach engineering's GitHub credentials. Model policies follow a hierarchy from account to workspace to agent, and disconnecting a credential instantly revokes access for every agent that used it.

Yes. Workspaces hold multiple agents, triggers automate when each one runs (webhooks, schedules, or API calls), and agents can spawn sub-tasks, which are captured in the parent session. That last part is the difference from ungoverned multi-agent setups: when work passes between agents, the whole chain lands in one trace, so you can see which agent did what, in what order, with what result.

Guild enforces hard limits, not advisory ones. A daily token limit caps LLM consumption: once the limit is exceeded, further LLM requests are rejected for the rest of the day. Model policies control which models an API key can call, applied hierarchically from account to workspace to agent. And because every session records the model and token count of each LLM call, spend is attributable per agent before it ever becomes an invoice surprise.

Every agent run produces a session: a read-only log of each LLM call, tool invocation, sub-task spawn, error, and lifecycle transition, with timestamps and payloads. Logs cannot be edited after the fact. That gives security and compliance teams what audits of automated systems actually require: a complete record attributing every action to a specific agent, reviewable long after the run.

The fastest path is installing a pre-built agent from the Agent Hub, where teams publish validated agents like ticket triage and PR review, ready to run in your workspace. Building your own is three CLI steps: scaffold with guild agent init, test locally with guild agent test --ephemeral, then publish with guild agent save --publish. Either path gets a first governed agent running the same day you start, typically within minutes.

One control plane.
Manage the complete agent lifecycle.

Get a working agent in minutes.
No credit card required.