Workspace settings

The Settings page manages a workspace’s configuration and lifecycle. Open the workspace and click Settings under Setup.

​

Restrict to members

By default, everyone in the organization can see and use every workspace it owns. To limit a workspace to named people, 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 and its data: sessions, triggers, installed agents, and settings. An admin who isn’t a member sees an Admin access notice.
• 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.

​

Manage the roster

While the restriction is on, the section lists the members with their Name and when they were Added. Your own row is marked (you). Search the list, or sort it by Newest, Oldest, Name A-Z, or Name Z-A.

• To add people, click Add member, search the organization’s members, and click Add.
• To remove someone, open their row’s menu, click Remove from workspace, then Remove member.

​

What the restriction doesn’t cover

The restriction controls who can reach the workspace’s data. It doesn’t control what the workspace depends on. Much of what a workspace uses belongs to an account rather than to the workspace: agents, integrations and their versions, skills, account credentials, runtime environments, and more. Anyone who can edit those can change what runs in a restricted workspace, roster or not. Two examples:

• Agents. When an installed agent has Autoupdate on, the workspace moves to each new version as soon as it’s published, whoever published it. The next session runs that version’s code with the workspace’s context and credentials. Turn off Autoupdate on the installed agent to pin its version, and upgrade it deliberately after reviewing what changed.
• Runtime environments. Environments aren’t versioned. An edit to an environment’s base image or setup script applies to the next session of every agent that uses it, in every workspace, including restricted ones and those started by existing triggers.

Treat these the way you’d treat a code dependency your project pulls in automatically: the workspace trusts whoever can change them. In an organization, that’s every member. If a restricted workspace runs sensitive work, depend only on resources from accounts whose editors you trust with that work, and keep Autoupdate off.

​

Spend budget

A spend budget caps monthly LLM spend. Budgets are opt-in. With no budget set, spend has no ceiling. Budgets are admin-only. Only an admin or owner of the account can set, change, or remove one, and non-admins can’t read them either: the section shows only Spend budgets are managed by org admins, without revealing whether a budget exists. To set a budget, click Set budget in the Spend budget section and enter a Monthly budget (USD):

• Whole dollars, from $1 to $21,000,000.
• Higher than what the workspace has already spent this cycle.
• A Suggested budget is offered as a starting point.

Once set, the section shows spend against the budget this cycle and when it resets. Click Edit to change the amount, or Remove budget to clear it. Guild acts as spend accumulates within the cycle: Each notification fires at most once per budget per cycle. The cycle is the calendar month in UTC, 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 can’t 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 don’t block calls.

​

Restrict to workspace credentials

Turn on Use only credentials scoped to this workspace to stop agents here from falling back to the owning account’s shared credentials. Agents then use only workspace, member, or agent credentials. The change saves as soon as you flip the toggle. The toggle appears on both the workspace’s Credentials and Settings pages. Connect or bind what the workspace needs before you turn it on. See Restrict a workspace to its own credentials.

​

Archive a workspace

Archiving takes a workspace out of use without deleting it. Click Archive Workspace in the Archive workspace section, then Archive to confirm. Archiving:

• hides the workspace from your workspace lists
• deactivates every trigger in the workspace, so scheduled and webhook agents stop firing

The trigger change outlives the archive: unarchiving doesn’t 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 doesn’t change. Agents, sessions, triggers, context, and settings are 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.