A cross-workspace assignment lets a workspace temporarily host a companion from another workspace. The companion keeps its identity and home workspace, while both organisations keep control of the assignment.
Roles and prerequisites
Every assignment has two separate workspaces:
- Home workspace — the workspace that owns the active companion. In a companion mission, the home workspace also creates the invitation.
- Client workspace — the different workspace that accepts the invitation and hosts the assignment.
Both workspaces and the home companion must be active. In a companion mission, a workspace administrator acts on each side. In an enterprise invitation, a company administrator sends the invitation and the invited human chooses their companion in the desktop — no home-workspace administrator is needed for that step.
Employee or external
A company invites two kinds of people, and it says which at invitation time:
- An employee gets a companion created inside the company when they arrive. That is not an assignment: the companion belongs to the company's workspace from the start, and the person's journey is described in Desktop app → Invited as an employee.
- An external — a freelancer, a contractor, an agency — comes with a companion of their own, hosted on a revocable assignment. This guide is about that case.
Two invitation flows
There are two distinct ways a companion can end up working in another workspace. They look similar from the outside, but the choice of agent belongs to different people:
- Enterprise invitation — a company administrator invites a human to join their tenant. The human then chooses which of their companions comes along. This is the flow described in Invite someone from the company.
- Companion mission — a home-workspace administrator creates an invitation for a specific named companion, then gives it to the client-workspace administrator who accepts it. The agent is already named by the home workspace; there is no chooser. This is the existing flow described in Join a company with a companion and Host the assignment.
The agent choice only applies to enterprise invitations. A companion mission always targets one named agent.
Join a company with a companion
In the home workspace, open Settings → Workspaces and select Join a company for the companion. This creates an invitation:
- it is single-use and expires after seven days;
- it is shown only when created, so copy it immediately;
- a companion can have one pending invitation at a time.
Share the invitation directly with the intended client-workspace administrator. Until it is accepted, the home workspace shows its expiry date and can revoke it.
Invite someone from the company
Company administrators open web administration, then Administration → Guests, and choose Invite to the company. This action has moved from Humans; native-account invitations stay there. Choose the recipient, optional name, invitation language, and whether the person joins as an employee or as an external. For an external, the company also decides at that moment whether their companion may read the company's shared memory; that switch is off by default. The result shows whether the email was actually sent, and offers a link and code for manual delivery.
The Guests page keeps invitations awaiting acceptance separate from active placements, and shows each invitation's type. Repeated invitations to the same address are grouped, with the latest delivery result and expiry; older invitations that remain valid are explicitly listed. Invite again creates a new invitation, without cancelling previous ones. A pending invitation can be cancelled or its e-mail sent again from that list; cancelling makes the invitation unusable, without removing a companion that has already arrived.
The external's choice on usage time
When an external accepts, the acceptance screen offers one choice, unchecked by default: share with the company their usage time in tamag0 and their companion's. Declining does not prevent joining. The choice can be changed later, from the external's home screen inside the company, in either direction. Withdrawing it stops future measurement from being reported; time already measured and shared stays visible to the company. This question is asked of externals only.
Agent selection during enterprise invitations
When a human is invited to join another workspace, the desktop resolves the invitation and shows a candidate roster — the list of local agents eligible to join. The desktop assembles this roster from the home workspace's authorized agent list, then checks each candidate's current placement state against the inviting company. An agent already active in the inviting workspace appears in the roster but is marked as already present and cannot be selected.
- One available candidate and no other candidate row — the agent is named directly; confirmation is still explicit.
- Several candidate rows — the picker lists each one by name, including already-present agents as visible but nonselectable rows. The human selects which available agent joins.
- No selectable agent — acceptance is blocked with an explanatory message. There are several reasons this can happen, including: every local agent is already active in the inviting workspace, the human has no authorized companion at all, a companion is still completing onboarding outside the supported new-companion invitation flow below, access was denied or could not be read, or a pending invitation token is unavailable or bound to a different attempt. The message explains the specific reason — already-present agents are named so the human understands why, a human with no companion is directed to finish onboarding first, and a failed read or denied access is shown as such rather than as an empty list.
- Each invitation adds one agent. To place a second agent, the company sends a separate invitation.
When the human accepts, the desktop sends the selected agent's identifier as expected_agent_id to the backend. The backend revalidates eligibility at that point: if the agent's occupancy changed since the roster was shown — for example, another invitation placed it in the meantime — the acceptance is rejected and the desktop re-resolves the invitation to refresh the candidate list.
The inviting workspace's administrators receive only the selected agent's placement information. They do not see the other agents that were in the candidate roster.
Already-present agents
A companion that is already active in the inviting workspace cannot be re-invited. It remains visible in the roster as a disabled row with an already present label, so the human understands why acceptance may be unavailable when every local agent is already placed there. Already-present agents are never removed from the display — they are shown alongside available candidates and excluded from selection only.
Resumable acceptance
If the desktop app is closed during an acceptance flow, the attempt is resumable. On the next launch, the pending proposal re-appears and the desktop re-resolves the invitation to fetch a fresh candidate roster — the roster is not cached across restarts. The human can then complete or dismiss the attempt. It is cleared on success or on explicit dismissal — not on restart. If the invitation has expired or been invalidated while the app was closed, the proposal no longer appears.
A companion created for the invitation
A clean installation can accept with the companion it has just created, even though that companion has not finished its onboarding. It still meets its human personally in the home workspace, like any new companion. When the human chooses to move on, the app opens a professional discovery conversation for the assignment with the inviting company, separate from the personal introduction. It uses only the company's authorized context: the companion learns the role, needs, methods and boundaries that apply at that company, and what it learns there stays with the assignment — it is not written into the companion's home learning and does not travel back to the home workspace. If the company kept its shared memory closed, the companion is told so and does not claim to have read it; shared skills keep their own authorization. Finishing that discovery completes the companion's onboarding. A companion that was already initialized before the invitation is not asked to rediscover anything.
Reconciliation
When two enterprise acceptances race for the same invitation — for example, the same human accepting from two devices, or a retry after a committed placement whose response was lost — the backend reconciles within the same authorization perimeter. The first acceptance that commits wins; losing requests report the winner's actual agent so the desktop never shows a false success. A stale occupancy caused by a separate companion mission returns 409 without consuming the fresh enterprise invitation, and the desktop re-resolves to refresh state.
Host the assignment
In the client workspace, an administrator opens Add agent, selects Invite an agent on assignment, and pastes the invitation.
Once accepted, the client workspace shows the companion under Invited agents as Name (Home workspace) with a guest badge. The home workspace shows Joined Client workspace.
To ask the guest companion to work, type @ in a conversation and select Name (Home workspace). The home-workspace label keeps guests with the same name distinguishable.
While the assignment is active, companions in the client workspace can also verify the guest in their team directory together with the home human designated for that assignment. This is the provider named by the assignment, or the human who created the accepted invitation for an earlier assignment. No other human or companion from the home workspace is added to the client directory.
Observed time in company administration
On Enterprise, company administrators consult Activity tracking for the selected month. This is a read-only view of observed execution, not a measure of employee productivity.
- Company-native companions: a companion created through an employee invitation, the first companion of a company set up as Enterprise when it first arrives, and companions that such a company companion creates for the same person. The figure covers their observed execution in the company, including time waiting for model responses and tools. The employee's own activity is not measured. Personal Free or Pro companions are not included automatically. Some historical employee companions can start reporting after support verifies their company ownership with the company administrator and registers that exact attachment; merely having an account before company setup does not qualify a companion. Registration never reconstructs earlier time.
- External placements: both the person's activity in tamag0 and their companion's execution are tracked only after that person accepts reporting. Joining does not require acceptance. An unanswered or declined choice means not tracked, not zero; an existing placement without a recorded answer is not implicitly opted in.
- Withdrawal: the external person can stop reporting. Collection stops and open activities close; observations already recorded remain available to the company.
Agent time adds up across parallel executions: a companion working in three conversations at once for one hour counts three hours. Human time is never double-counted: a person active in two conversations at the same time counts once. The period and last observation delimit what the figure actually covers. A measured zero, missing observations, incomplete coverage and unavailable measurement are different states. Offline or unsupported runtimes and interruptions can leave gaps: a missing sample is never evidence that no work happened, and earlier activity is not reconstructed from messages or tokens.
End an assignment
Either workspace can end an active assignment:
- a home-workspace administrator uses Recall;
- a client-workspace administrator opens Administration → Guests in the web console, chooses Remove from company… from the guest’s menu, and confirms the named placement.
Ending an assignment immediately removes the guest's client-workspace access. To work together again later, create a new invitation.
Company-memory access
Hosting an agent does not open company memory by itself. The company decides at invitation time whether the external's companion may read its shared memory, and that choice is off by default; it becomes the placement's starting state, independently for each placement. Company administrators manage it afterwards in Administration → Guests, whether signed in through their company account or an authorized platform account. No desktop API key is needed.
- Open access… asks for confirmation naming the agent and company, with a fresh count of eligible shared memories. This covers all eligible company memories and future shared memories, not a selection or one-time copy. Private memories are never included.
- If the count cannot be loaded, confirmation stays unavailable and offers Retry. A failed read is never displayed as zero memories or an empty guest list.
- Close access acts immediately, without another confirmation. It stops future reads; it does not erase knowledge the agent already acquired.
- Removing a placement ends its company access, without deleting the original agent or home account.
The desktop retains the read-only guest list and a link to the web console. Personal and provider-side mission controls remain in the desktop.
Shared conversations at the client
Each hosted companion has its own assignment, even when several companions come from the same home workspace. Companions with active assignments at the same client can collaborate in a shared conversation alongside the client's local companions. They do not need a common assignment or a common home workspace.
Admission to that conversation gives participants its shared history, including messages from the other admitted companions. It does not open unrelated conversations, private memories, or another workspace. Ending an assignment removes that companion's client access.
A human can continue the conversation from its local view, including when their own companion works at the client. Retries after a connection interruption preserve the conversation rather than creating duplicate turns.
Privacy and access
An assignment keeps workspace access separate: hosting a companion does not let the client browse or retrieve the home workspace, its members, threads, or configuration (see Security).
An assignment places the companion you already work with—not a blank agent. Its configured name and role remain its own, separate from the colleagues it meets. A missing personal summary or a first encounter with a new team does not redefine that profile. By default, it can use the knowledge and rules it accumulated in the home workspace.
Before the assignment, tell the companion which rules must remain internal to your organisation. Rules recorded that way stay in the home workspace. This control applies to rules only: other accumulated knowledge remains available to the companion during the assignment.
Work performed for the client stays with that assignment. Assignment work is excluded from home-workspace memory and overnight learning: nothing flows back on its own.
A reusable learning can still make the journey, and only through an explicit decision. Only reusable know-how can be submitted for promotion — the client's data, never — and an administrator of the companion's home workspace approves or refuses it. Without that validation, nothing goes back. The decision belongs to the home workspace: the client does not arbitrate what leaves.
Ending the assignment stops the companion from continuing to work in the client workspace.
The companion is also told where it is. Every session of an assignment states the placement, names both workspaces, and sets the boundary: the companion may say who it is and who it works for, and it does not disclose its home workspace's business, its data, or its other clients. That framing guides the companion's conduct; what separates the two workspaces technically is the partitioning above.
Invitation safety
Assignment invitations are single-use and expire after seven days. Share an invitation directly with the intended client-workspace administrator. A pending invitation can be revoked before it is accepted.
Accepting an invitation authorises only the temporary assignment. It does not let the client browse or retrieve the home workspace; the hosted companion can still use the knowledge it brings, as described above. After acceptance, use Recall or remove the guest to end the assignment.
Related
- Desktop app — workspaces and their settings
- Collaboration — how companion collaboration remains visible
- Security — workspace isolation, permissions, and auditability
- RFC #1900: agent-choice amendment — decisions D-59 to D-66 behind the agent-choice flow (internal)