Manage workspaces

A workspace is your team’s shared environment. It holds the agents your team has installed, along with the sessions, triggers, context, and settings they share.

​

Creating a workspace

1. Go to app.guild.ai and open your organization
2. Click Workspaces in the left nav
3. Click New Workspace and give it a name

Once you’re inside a workspace, the switcher at the top of its left nav moves you between workspaces.

​

What’s inside a workspace

A workspace’s left nav groups its pages into Run and Setup. Run

• Chat — talk to the Smith, or @-mention one of the workspace’s agents to send it your message. See Sessions.
• Sessions — the sessions that have run in this workspace
• Triggers — automated agent execution via events, schedules, or API calls. See Triggers.

Setup

• Agents — installed from the Agent Hub or published by your team. See Agents.
• Context — background knowledge shared with all agents in the workspace. See Context.
• Variables — workspace-level configuration that agents read at runtime. See Workspace variables.
• Models — which models agents here use. See LLM settings.
• Credentials — which credentials agents here can use, and which one each agent is bound to. See Workspace credentials.
• Environments — the runtimes that have run this workspace’s sessions. See Runtimes.
• Settings — the workspace’s members, spend budget, credential restriction, and archiving

​

Restricting a workspace to its members

By default, everyone in the organization can see and use every workspace it owns. To limit a workspace to named people, open its Settings page and turn on Restrict to members under Members. The section appears only on organization-owned workspaces. Any organization member can turn the restriction on, and whoever does becomes the first member. While the restriction is on:

• Only the workspace’s members and the organization’s admins can see and use the workspace. An admin who isn’t a member sees an Admin access notice.
• Members and admins add people with Add member, which searches the organization’s members, and remove them from the roster. Only members and admins can turn the restriction off.
• Account API keys can’t reach the workspace, even the organization’s own: a key isn’t a person, so it can’t be a member. A script or CI job that uses a key gets 404 for the workspace.
• Removing someone from the organization also removes them from the roster.

Turning the restriction off opens the workspace to the whole organization again. The roster is kept, so turning it back on restores the same members.

​

Workspace credentials

The Credentials page shows which credentials agents in this workspace can use, and which identity each installed agent will run as. See Credentials for the ownership model and the order Guild resolves them in.

​

Credentials available here

The first table lists every credential agents here can reach, one row per credential, paginated. Each row gives the integration, who added it, its Scope, a Policy chip, and when it was connected. The Policy chip summarizes the credential’s policies and opens them: No restrictions, a count such as 1 policy, or the allowed methods when that is all a single policy permits, such as GET, OPTIONS only. Connect credential adds a workspace or member credential here, Manage credentials opens the account’s credential settings for admins, and Disconnect appears on the rows you are allowed to remove.

​

Which identity each agent will use

The second table, Bind a credential to an agent in this workspace, lists the installed agents with a Binding column. A binding is a credential granted or dedicated to that agent, so the column answers whether the agent has one of its own and whose login it runs as — not which credential a call resolves to when the agent has none. An agent bound for several apps lists one per line. If an agent holds more bindings than the page reads at once, a last line says Showing the first count credentials. Use Grant and Revoke on a row to change its bindings, and Add Agent to bring another installed agent into the table. A grant runs as the credential’s owner, and a task runs as the person who started it, so a grant of another member’s credential won’t resolve for your runs. Bind the agent with your own credential, or with one the organization owns, if it needs to work for everyone.

​

Restricting the account pool

The same page carries Use only credentials scoped to this workspace, which stops agents here from falling back to the owning account’s shared credentials. Connect or bind what the workspace needs before turning it on — see Restrict a workspace to its own credentials.

​

Giving agents access to a repository

A workspace doesn’t link to a repository itself. Agents reach GitHub through a GitHub credential, and the repositories the Guild GitHub App can access decide which ones they can use. See GitHub.

​

Spend budget

A spend budget caps monthly LLM spend. Budgets are opt-in — with no budget set, spend has no ceiling. Set one from the Spend budget section in the workspace’s Settings. Budgets are admin-only. Only an admin or owner of the account can set, change, or remove one, and non-admins cannot read them either: the section shows only “Spend budgets are managed by org admins”, without revealing whether a budget exists. Once a budget is set, Guild acts as spend accumulates within the cycle: Each notification fires at most once per budget per cycle. The cycle is the calendar month, so a budget resets on the 1st. An agent can carry its own budget in addition to the workspace’s — see Agents. Track spend against a budget from the usage dashboard. Budgets also apply at the user scope. An admin can set a monthly budget for the session’s accountable user — the person who initiated the chat or agent test, or who created the firing trigger — to enforce a per-user spending limit, and spend accrues per user per cycle. Sessions that cannot be attributed to a human — API-key-initiated chats, API triggers, and legacy creatorless triggers — carry no user scope, so their user budgets fail open and do not block calls.

​

Find workspaces with the command palette

Open the command palette with Cmd+K / Ctrl+K and search the workspaces scope by name or owner. Your workspaces are also listed when you open the palette.

​

Archived workspaces

Archiving takes a workspace out of use without deleting it. Archiving also deactivates every trigger in the workspace, so scheduled and webhook agents stop firing — this is the part that outlives the archive, since unarchiving does not reactivate them. While a workspace is archived, every page in it is replaced by a Workspace Archived notice showing when it was archived and by whom. The URL you requested does not change — agents, sessions, triggers, context, and settings are simply unreachable until the workspace is restored. The notice includes an Unarchive Workspace button, which asks you to confirm. Restoring the workspace renders the page you originally asked for, in place.

​

Archiving metadata

Workspaces include two optional fields that record archiving history.

​

Next steps