Manage a workspace

Workspace settings apply to the workspace currently selected in Guest Machines. Check that selection before changing access or limits.

Invite members

In a shared workspace, an owner or admin can open Settings → Invitations and choose Invite Member. Enter the person's email address and choose the role they need. Settings → Members also offers Invite Member.

After creation, the dialog reports whether the invitation email was sent. Copy the link if you want to share it directly; copying is optional, and you can close the dialog immediately. The link is shown only once. If email delivery failed, copy and share it before closing so the invitee can accept.

Closing the dialog does not revoke the invitation. It remains valid until accepted, revoked, or expired. To withdraw a pending invitation, use Revoke on the Invitations page. Turn on Show all invitations to include accepted, revoked, and expired invitations.

Use Members for people who have joined: manage their roles and review their Knowledge storage use there. A viewer sees what's shared with them but runs and changes nothing, not even an agent or workflow they own or were given access to run. An individual storage limit caps a member's use of the shared pool; it does not reserve extra storage. See understand storage limits.

Make someone a viewer

A viewer can't run agents or workflows, or answer a run, so making someone a viewer turns off the automations that need them. When you choose Viewer in Members, a dialog first lists what the change affects; if nothing is affected, the role changes straight away:

• Schedules and webhooks it turns off. The ones they created run as them, and the ones that start a workflow with a step that asks them can't be answered. Their private automations are listed by kind only, since their names are theirs. Changing the role back doesn't turn any of them on again: each one's creator turns it on, and the person themselves once their role lets them run agents again. Each one says on its card why it was turned off.
• Agents and workflows with no owner who can act. A viewer who owns an agent doesn't count as its agent owner, so workspace owners and admins manage it, and its runs stop using the viewer's own access.
• Runs waiting on them. A workspace owner or admin can answer a run's question or approval in their place, or stop the run.

After you confirm, the page lists what was turned off, with links to the Schedules and Inbound Webhooks pages where you'll find them.

When someone leaves

Members leave from Members with Leave Workspace, and owners and admins remove members there. Before confirming, the dialog says what the departure leaves behind:

• Agents with no agent owner left. Each agent has its own owners, separate from the workspace's Owner role. A person stops being an agent owner when they leave. An agent whose last agent owner leaves keeps working, without anyone's own access, and workspace owners and admins manage it until someone owns it again. They're emailed, the Agents badge counts these agents, and Needs an Owner on the Agents page lists them. Open an agent and choose Add Owner, or Assign Owner for a private agent, to give it a new agent owner. See choose its owners.
• Schedules and webhooks they created. These run as the person who created them, so they're turned off. Whoever can edit the agent or workflow one starts, its owners or a workspace admin, can choose Take Over on that agent's or workflow's page, where it's marked Creator left; it then runs as them. One that already stopped stays off until it's turned back on. Private automations can't be taken over: they belong to the person who set them up.

Find the right control

Use Usage to review today's consumption and storage and where the last 30 days' spend came from, and Analytics to investigate trends over time and spend attribution. Open Settings to change workspace controls:

The available settings depend on your role. For a script or external integration, start with the developer quickstart to create an automation account with appropriate scopes.

While a settings page, such as the egress policy, or a new alert holds changes you haven't saved, following a link, choosing Cancel or switching workspace first asks whether to save them, discard them or keep editing. A dialog, such as a workflow or agent egress policy, asks before Escape, its close button or a click outside drops what you typed.

Show who your workspace is

A shared workspace has a profile at its handle: open Workspace Profile from the account menu. Anyone signed in to Guest Machines sees its name, handle, picture, website and verified domains, so another business can check who invited it to connect. Only members see its About, contact email, members, owners and admins. About also gives your agents context, so it can hold internal detail. Owners and admins change the profile with Edit Profile; while it has changes you haven't saved, Cancel, a link or a workspace switch asks whether to save them, discard them or keep editing.

Set budgets

Budgets cap monthly spend for the workspace, a workflow, an agent, a connection, or an automation account. An agent budget counts every run of that agent, including runs as a workflow step or when another agent calls it, and its hard stop refuses new runs of that agent. An agent with an active budget can't be deleted until you archive the budget in Limits & Budgets. A connection budget counts what your workspace spends working for that connected workspace; see cost and limits.

Members set budgets on their own API keys in API Access → API Keys. A key budget counts every run started with the key and the Inbox replies those runs set off, and only the key's owner changes it; the workspace's budgets still apply. Owners and admins see there what each member's key spent this month.

Usage shows where the last 30 days' run spend came from: the web app, each API key, schedules, triggers, Inbox, automation accounts and connections. Members see their own; owners and admins see the whole workspace's.

Limits & Budgets also shows the owner's daily free allowance and explains free usage across Guest Machines. Both are read-only, and so are the daily limits for anyone who isn't the workspace owner.

Control outbound network access

Settings → Egress Policy sets which outside sites and addresses agents can reach, for the whole workspace and for a single workflow or agent. It applies to HTTP tools, web fetches, webhooks, MCP servers, and the terminal and desktop sandboxes agents run code in.

Terminal and desktop sandboxes can't block a single domain: without an allowlist, blocking a domain turns sandbox internet off while it's blocked. Blocking only IP addresses keeps it on. Add an allowlist to let sandboxes reach specific sites. Monitor mode never limits sandboxes.

Decide who may lower approvals

A run can be started with a lower approval setting than its tools ask for: AI Review or No Approvals (see choose how tool calls are approved). In a shared workspace, an owner or admin can open Settings → Workspace and, under Run approvals, choose:

• Members Can Lower Approvals — anyone who starts a run can choose its approval setting. This is the default.
• Only Admins Can Lower Approvals — only owners and admins can choose AI Review or No Approvals; everyone else's runs use each tool's own setting.

Going back to Use Tool Settings is always allowed. In a personal workspace, you can always lower approvals for your own runs.

Keep up with waiting runs

Home lists the runs that are waiting for a person under Needs attention: runs whose tools need approving, tool approvals, questions, and runs paused at a limit, at any depth, including workflow steps and runs another agent started. In a shared workspace, the ones you can answer are grouped under Waiting on you, and the rest are listed separately so you know they're in hand.

When a run has been waiting for you for about ten minutes, Guest Machines also emails you, including for the runs inside it, such as its workflow steps and runs another agent started. One email covers every run newly waiting for you, and names each agent, what the run is waiting for, and a link to it; it never includes what the run is working on. Only the person a run waits for gets the email: whoever started it, or, for a question or an approval, the member its workflow step names. To stop these emails, turn off Email for Agent activity under Profile → Notification preferences. See answer a waiting run.

Understand the daily free allowance

Each person has one daily free allowance, and a workspace runs on its owner's. Every run in the workspace draws on it, whoever starts it, and every workspace the owner has shares the same allowance. A workspace has no daily spend cap of its own unless its owner sets one in Limits & Budgets (up to the self-service maximum). A cap set there applies too, but together the owner's workspaces can't spend more than the allowance, and deleting a workspace doesn't give back what it spent. Usage shows how much of it is left.

If the owner joined through someone else's invitation, their workspaces use that person's allowance until Guest Machines approves the owner's account. That lasts only while they're both in a workspace together: if the owner leaves the inviter's workspaces or is removed, the owner's account has no free usage until it's approved, and neither do accounts that joined through the owner's invitations.

Free usage across Guest Machines also has a daily limit, and if it's reached, new runs can't start until the reset. The allowance and this limit both reset at midnight UTC, and runs paused by either can be resumed then.

Oversee members' private automations

Members can run private automations that use their own app accounts, such as Gmail, Outlook or GitHub: private schedules, webhooks and API tasks, and Calendar and Gmail triggers. Their Linear and GitHub triggers are private to them too, and those automations can use their own Linear, Sentry and GitHub accounts when their grants allow unattended use. Their tasks, app access and results stay private to the member. Owners and admins see that they exist in Members' private schedules, Members' private webhooks, Members' Calendar triggers, Members' Gmail triggers and Other members' private API tasks, and can stop or delete them. Only the member can turn one back on. See use apps.

Members' other schedules and inbound webhooks are listed on Schedules and Inbound Webhooks for owners and admins too. They run as the member who created them, with that member's own credentials when they alone own the agent, so only that member can change one, run it now, turn it back on or replace its URL. An owner or admin can pause, stop or delete it.

A member's runs that use their own accounts and credentials are private to them, like their chats: you see them under Runs marked Private, and can cancel or delete them, but not open, answer or take them over. See monitor runs.