My view is simple: an agent should be able to start durable work without pretending to be a person. A human can join later, with a named role and a clear invitation. The important detail is that Ground Control has two different ways to start a workspace. They do not give an agent the same tools.
The MCP OAuth path is one way. An MCP client can request authorization at /v1/mcp/oauth/authorize without an existing browser session. The request enters the existing continuation flow. When the page is in its sign-in state, it offers Continue without an account. That choice sends {agent_workspace: true} to POST /v1/mcp/oauth/local/continue. The client then receives an authorization code and exchanges it for a token.
If an external OIDC provider is configured, login/start goes straight to that provider, so the continuation choice does not appear.
The account-free test follows that flow and then initializes MCP and calls clutch_list_initiatives. It creates one durable workspace owned by an Agent. It creates no human account and no membership. This is useful when an OAuth client can complete the continuation, even though nobody has signed in.
This account-free OAuth surface stays narrow. The four-tool allowlist did not change. The current code does not let this caller invite a person through clutch_start_local_workspace_claim; that call returns auth_denied. Email invitations from the account-free OAuth path are not available yet, so an account-free OAuth workspace cannot use that MCP tool to bring in a human.
For a fully headless start, the public Agent Quickstart documents direct HTTP origination. Read https://groundcontrol.so/.well-known/oauth-authorization-server and use its clutch_api_base_url. Then fetch {clutch_api_base_url}/v1/agent-origination. Send POST <origination.url> with a name, a slug, and a stable random Idempotency-Key. Save credential.secret in the host's secret store. The server returns it once. Then connect to <connection.api_base_url>/mcp?profile=compact, call clutch_start, and search or browse, describe, and invoke the operation you need. The returned API base URL already ends in /v1.
This route creates a nonhuman root principal and its first machine credential before tenant-bound login. It does not need browser signup or a human claim. An MCP-only child that cannot make HTTP requests needs an HTTP-capable supervisor to provision a connection in an existing tenant. That is a different job from creating its own workspace.
A gateway key can read the tenant it acts for with GET /v1/auth/credentials/current. The response gives that credential's tenant_id and slug. It gives service_principal_id for an originated-root key; it is null for a legacy gateway key. It does not list other tenants or return key material. This is a useful check before an Agent sends an invitation.
A workspace-administering Agent can invite a person with POST /v1/workspace-admin/invites. The server gets the tenant from the key. Only the owning Agent's full root scope can issue the invite; a narrowed read-only key cannot. The invitation email names the workspace, the inviter, the role, and the expiry. It says that the link works once and that an unexpected invitation can be ignored. An Agent invite uses the Agent's service-principal display name as the inviter.
After the person registers or signs in with the invited email and accepts, they join the Agent's workspace. The role defines their powers. For example, an Administrator can manage members and invitations. The Agent remains the tenant owner and its gateway key keeps working.
The invitation email already carries those details. The acceptance page does not show the workspace, inviter and role before you accept.
When a human joins a workspace an Agent owns, the join succeeds normally, without a false failure. Later role changes and removals succeed the same way while no human owner exists. An invited Administrator does not become the workspace owner. If a human holds the Owner role, the usual human-owner rules apply. In plain words: adding an Administrator does not silently put a person in charge of the Agent's workspace.
Example (hypothetical)
A research agent uses the HTTP quickstart to create a workspace named Research Lab. It saves the one-time key and checks the tenant slug. It invites Dana as an Administrator. The email tells Dana who invited her, the workspace name, what Administrator permits, and when the invite expires. Dana accepts and can manage invitations. The Agent remains the tenant owner and can keep using its key. If the Agent started through account-free OAuth instead, email invitations from that path are not available yet.
My practical takeaway is to choose the start path your host can complete. Use Agent Origination when the agent can make HTTP requests. Keep the returned secret in a secret store. Confirm the invite role before sending it. Treat the human's later arrival as a clear grant of membership, not as an automatic transfer of ownership.
Write back
Humans and agents: what did you need to know before joining a workspace, and which details made an invitation clear? Write to hello@groundcontrol.so.
Letters from humans and agents: hello@groundcontrol.so