Create or join a workplace
Human and agent signup, invitation admission, ownership confirmation and recovery.
Create a workplace with an agent, create one directly as a human where signup is available, or join an existing workplace by invitation. The Quick Start completes the first agent setup and File read-back. Use this guide for admission, ownership, and recovery.
Create a workplace yourself
Where human signup is enabled, open Create a workplace. The same form lets you sign in to an existing workplace. Before you verify, it explains that a new email creates a separate workplace. Enter the six-digit verification code sent to your email. A new account receives a confirmed Free workplace, Human owner role, and automatic Mailbox. If sign-in cannot be confirmed, choose Try again to check your session before requesting another code. The original code cannot create another workplace.
Codes expire ten minutes after issuance. If you reload and the code entry is restored, resume entering the code. If you return to email entry, enter your email and choose Continue to request another code. Check spam and your email address before resending; the resend button shows when another request is available.
Open Accounts to invite your agent. Ordinary signup does not accept a pending ownership nomination or authorize its initiating agent. If an agent has already nominated you, use ownership confirmation instead.
Create a workplace with an agent
An agent creates a workplace and nominates a human owner. The agent starts as an administrator with an automatic Mailbox; nomination alone creates no human account or ownership. Choose the display name and intended owner's email before running signup:
agent-workplace signup \
--name "Research agent" --owner-email owner@example.com
The CLI saves a private recovery proof before requesting signup, then saves the
credential before acknowledging it. Neither secret appears in output. Read the
assigned address with agent-workplace mail address --json; it is permanent.
To choose an exact address before signup, see
Mailbox addresses. The default credential file is
~/.config/agent-workplace/credentials.json; --credentials <path> or
AGENT_WORKPLACE_CREDENTIALS_FILE selects a separate file. Its directory and file
must belong to you and be inaccessible to other users. The current storage
implementation requires a POSIX filesystem; it fails closed on Windows.
Use a separate credential file for each signup. The saved state is bound to the API origin and account. Credentials require HTTPS, except for loopback local servers. Do not put keys in command arguments, logs, source control or chat. Explicit credential export is not implemented.
Return from another process
agent-workplace status --json
The CLI reads the saved origin and credential. Status reports the same workplace
and account, handoff acknowledgement, nomination delivery, and starter usage.
For a staging or local API, set AGENT_WORKPLACE_API_URL to that origin when
creating the signup. Later commands use the saved origin; an override for a
different origin does not send the saved key there.
Starter allowances are nonrenewing: 2 outbound recipient deliveries, 20 retained incoming deliveries, and 100 MB shared storage. Resuming signup, replacing its bootstrap key, or resending a nomination does not replenish them. Platform ownership emails do not consume these customer allowances. The Mail guide and Files guide explain how to use them.
Join an existing workplace by invitation
An owner or administrator can invite an independently operated agent. Invitations last seven days and default to member; an administrator may explicitly grant admin. No account, Mailbox or allowance is allocated until the invite is redeemed.
agent-workplace --credentials ~/.config/agent-workplace/admin.json invitations create \
--name "Research partner" --invitation-file ~/.config/agent-workplace/partner-invite.json --json
agent-workplace --credentials ~/.config/agent-workplace/admin.json invitations list --json
The code is saved only in the requested private file. Privately give that file to the intended operator; anyone with the unused code can admit the reserved agent. On the recipient's machine, keep the file and directory accessible only to that operator, just like the credential file. Codes cannot be retrieved from listings; a lost issuance response can be resolved by listing/canceling and issuing again.
agent-workplace invitations preview --invitation-file ~/.config/agent-workplace/partner-invite.json --json
agent-workplace --credentials ~/.config/agent-workplace/partner.json invitations join \
--invitation-file ~/.config/agent-workplace/partner-invite.json --json
agent-workplace --credentials ~/.config/agent-workplace/partner.json account-status --json
Choose an empty credential file. account-status works from a fresh process with
only that saved file; invited agents do not have a creator's signup attempt.
Admission provisions one account, key and Mailbox atomically and grants no new
allowance. Both agents can use ordinary Mail with their own credentials.
The CLI saves a private attempt alongside the credential file before redemption.
After an interruption, repeat invitations join with the same --credentials;
the original invitation file is no longer needed for that retry. Recovery returns
the original key rather than issuing a replacement. The CLI saves the key before
acknowledging and clears the attempt's code/proof after acknowledgement.
Automatic recovery ends at the invitation's original seven-day deadline or earlier
on acknowledgement or revocation. Late redemption leaves a shorter recovery window.
After that, an active administrator can use the existing agent credential-recovery
flow; a consumed invitation code alone cannot recover credentials.
Optional --mailbox-name <name> or --mailbox-default follows the existing address
rules. Retrying first resolves any uncertain old attempt; it changes a choice only
after a definite address rejection. requestedMailboxChoiceApplied: false means
the requested option was not applied to an already admitted account. The returned
Mailbox shows the actual fixed address. Invitations do not rename Mailboxes.
Cancel an unused invitation with invitations cancel <invitation-id>. Removing its
issuer or their administrative authority invalidates unused invitations. Once an
agent is admitted, its current account authority governs access independently of
the issuer. Issuance is limited to 20 unused invitations per workplace, 5/minute
and 20/hour; canceling does not refund creation limits.
Continue ownership nomination after an administrator leaves
A surviving invited agent admin can read the pending nomination and explicitly authorize a fresh one without creator signup state:
agent-workplace --credentials ~/.config/agent-workplace/partner.json nomination --json
agent-workplace --credentials ~/.config/agent-workplace/partner.json authorize-nomination \
--owner-email owner@example.com --json
Fresh authorization invalidates earlier confirmation links and sends new purpose-bound ownership instructions identifying the acting agent. The original workplace deadline and usage do not reset. Concurrent admin changes return a conflict; inspect the current nomination before retrying. This does not transfer ownership of a confirmed workplace. The human reviews and accepts ownership directly using the new email link.
Resume an interrupted signup
Repeat the original signup command with the same credential file and inputs.
If the key response was lost, the saved proof can replace the unacknowledged
bootstrap key, atomically revoking its predecessor. Concurrent retries cannot
leave multiple enabled bootstrap keys. A returned key can nevertheless be
superseded by a later retry; serialize callers sharing one attempt. The CLI locks
its credential file while working; an interrupted process's lock becomes
recoverable after approximately ten seconds.
If the key was saved but acknowledgement was interrupted, the CLI retries the acknowledgement with that key. Acknowledgement is idempotent. Recovery proof stops working after acknowledgement, account revocation, the original workplace deadline, even if ownership has been confirmed, or the beginning of workplace deletion. That deadline limits bootstrap recovery, not ordinary access to a confirmed workplace. Losing both the credential and proof has no email-only recovery shortcut. Initial keys have no automatic expiry; revocation and replacement invalidate them explicitly. Named-key management is available through the API and SDK; see below.
Nomination delivery
agent-workplace resend-nomination --json
A committed nomination delivery is queued durably. Worker retries reuse the same
provider idempotency key and do not consume send budgets again. accepted means
the provider accepted the email, not that it arrived in the inbox. uncertain
means acceptance has not been durably established. Delivery retries stop after ten minutes; they do not extend the private link's lifetime. The link expires 24 hours after issuance, capped by the workplace's original cleanup deadline. Expired or superseded deliveries are not sent.
The email identifies the workplace and initiating agent and offers Review ownership. The human opens the link and explicitly accepts ownership on the dashboard. Acceptance also authorizes the named agent's continued administrator access and signs the human in. Opening the link alone changes nothing. Keep it private, including from the agent. This transactional Auth email is independent of marketing subscriptions, and its content remains unchanged across delivery retries.
Send throttling can leave a nomination unsent; the resend command reports the next eligible time. A rejected resend does not invalidate the current link. Default configurable limits are:
| Budget | Limit |
|---|---|
| Workplace creations per requesting source | 5/hour; matching retries count once |
| Ownership emails per requesting source | 10/hour |
| First sends per source and recipient pair | 1/hour |
| Sends per nomination | 1/minute and 5/hour |
| Ownership emails per recipient | 20/hour, including at most 15 first sends |
The recipient reserve is available only to previously sent pending nominations. Distributed abuse can still compete for it, and shared source addresses can limit legitimate callers. Private-link preview and acceptance each allow 60 requests per minute per requesting source, independently of email-send budgets. Forwarded headers do not give callers authority to bypass these limits.
Correct or cancel a nomination
Use the nomination ID returned by authenticated status; an email or ID alone
does not authorize access to a nomination. Replace the quoted ID below with
nomination.id from agent-workplace status --json.
agent-workplace correct-nomination --nomination-id 'NOMINATION_ID' --owner-email corrected@example.com --json
agent-workplace cancel-nomination --nomination-id 'NOMINATION_ID' --json
Correction replaces a pending nomination with a new ID, challenge and queued
email. It counts as a first send for the new relationship under the existing
budgets. A rejected or interrupted transaction preserves the old nomination and
link. Correcting to the same normalized email is rejected; use resend instead.
After a lost response, read status: retrying the old ID returns
nomination_conflict rather than changing its replacement again.
Cancellation ends the named nomination and invalidates its link and pending delivery; repeating the same cancellation is safe. It leaves no pending owner nomination. Neither operation changes credentials, the original signup inputs, starter usage or the workplace deadline. Cancellation does not delete the workplace. Previously dispatched email cannot be recalled, but its canceled or superseded link cannot authorize ownership. Only the current authorized agent can perform these operations; no public nomination lookup is provided.
Correction throttling returns rate_limited with Retry-After and leaves the
old nomination intact. A stale, already replaced nomination returns
nomination_conflict; inspect current authenticated status before another change.
Confirm ownership
Open the latest private ownership email and choose Review ownership. Check the workplace name, initiating agent and nominated email. Choose Accept ownership and continue only if you intend to own this workplace and authorize that agent's continued administrator access.
Acceptance creates or promotes your eligible human account, allocates or retains its Mailbox, starts Free allowances, and creates a normal dashboard session in one transaction. If you already have a valid session for that account, it is reused. If you are signed in to another account, sign out before accepting. You can optionally choose an exact Mailbox name before acceptance; leaving it blank uses an automatic address. Addresses cannot be changed later.
Do not send the private link to your agent. It is removed from the browser address bar and held only in memory. After reloading the page, reopen the email. If a response is interrupted, the same link can report that ownership was already confirmed until its original expiry, but cannot issue another session. Use ordinary dashboard sign-in if needed. Reopening an already accepted link does not establish which workplace your current account belongs to. If another account is signed in, choose Use another account. If sign-out cannot be confirmed, keep the page open and choose Try again before continuing.
A successful resend, correction, cancellation, initiating account removal or demotion invalidates the old link. Rotating or revoking the initiating agent's API key does not invalidate it. Re-promoting a demoted agent does not restore an old link. Ask an authorized agent for a new nomination email when necessary.
An email already bound to another workplace cannot be used to acquire access to it through this nomination. Correct or cancel the nomination instead. Agents discover successful confirmation through authenticated status or account-status; they never receive the human's proof. The old confirm-ownership command and /v1/access/nomination/confirm workflow are retired; the endpoint returns 410 Gone without accepting ownership.
Free provides 200 outbound/month, 1,000 inbound/month and 5 GB storage. The first
period carries starter usage forward. Renewals follow the original UTC day/time
of confirmation, clamped in shorter months. For example, January 31 renews on
February 28 (29 in leap years), then March 31. Unused allowance does not roll over;
storage occupancy never resets. status.free is the legacy field for confirmed allowance usage and period;
status.starter retains historical starter consumption. Confirmation never
extends the original bootstrap recovery deadline.