Team operations
AFK's team layer is organized around organisations, shared session visibility, assignments, handoffs, mentions, and shared operational settings. These features let teams supervise agent work without moving execution out of the daemon.
Organisations and context
AFK can run in personal context or organisation context. When you switch to an org in the browser, user-scoped resources such as sessions, preferences, daemons, automations, plugins, skills, agents, rules, MCP config, hooks, and billing are read and written for that org.
- Org-owned sessions store
owner_user_idas the org andspawned_byas the real member who launched the work. - Daemons registered to an org are available to members according to the org access checks enforced by the Hub.
- Org preferences provide shared LLM connections, API keys, webhooks, plugins, and other team configuration.
Roles
Organisation members can be admin, manager, ormember. Admin-only configuration surfaces such as LLM connections, API keys, and webhooks are hidden for non-admin users and blocked server-side.
| Role | Typical access |
|---|---|
admin | Manage org settings, members, shared credentials, webhooks, and billing surfaces. |
manager | See Org-visible sessions across the organisation and manage members without editing admin-only configuration. Restricted sessions require an explicit relationship. |
member | Use the org workspace and read Org-visible sessions. Restricted sessions require ownership, assignment, or explicit sharing. |
Invites and inbox
The Inbox button in the sidebar opens a personal notification panel. It is intentionally personal: it does not switch with org context, so a user can accept invites and handoffs no matter which workspace is active. Opening the panel marks unread items as read; acting on an item dismisses it.
| Inbox item | What it means | Actions |
|---|---|---|
| Org invite | An admin or manager invited you to join an organisation with a role. | Accept joins the org and removes the item. Decline rejects the invite and removes the item. |
| Session handoff | A session was assigned to you, often with a note from the previous owner. | Open jumps to the session. Reject clears the assignment and dismisses the item. |
| Unassigned | You were removed from a session assignment. | Dismiss acknowledges the notification. |
Org admins and managers invite members from Account → Members. Invitees receive an org invite item with the org name, role, inviter, and accept/decline actions.
Dashboard visibility
The dashboard is the team's operations surface for live and historical agent work. New sessions created in an organisation default to Org visible, so active members can discover and read them. Restricted sessions appear only to the owner/spawner, assignee, explicitly shared participants, and org owners or admins. Managers do not receive a Restricted-session read override; they need one of those explicit session relationships.
Personal sessions remain private. Older org sessions that predate these visibility choices show Legacy access and keep their previous access rules until an authorised session manager chooses Org visible or Restricted.
Shared sessions
Organisation sessions can be shared with additional teammates. Personal sessions remain private and do not expose team-sharing controls. Sharing is intended for collaborative agent operations: letting another person observe work, answer when appropriate, or take context from a durable transcript without copying it into a separate chat tool.
| Visibility | Who can read the session |
|---|---|
| Org visible | Every active member of the organisation. |
| Restricted | The owner/spawner, assignee, explicitly shared participants, and org owners or admins. Managers need an explicit relationship to the session. |
| Legacy access | Older sessions keep the access rules that applied before visibility choices were introduced. |
Visibility controls who can discover and read a session; it does not by itself grant permission to send messages, approve tool calls, assign or share the session, change settings, or manage its lifecycle. AFK checks those actions separately from read access.
| Participant role | What the participant can do |
|---|---|
viewer | Open the shared session, read transcript/history/context, and reconnect later, but not send prompts, approve tools, edit pending messages, or change session settings. |
contributor | Do everything a viewer can do, plus respond to or steer an unassigned shared session. If the session is assigned, the assignment lock still applies. |
The owner/spawner and org owners/admins can manage participants. Read access does not bypass the response lock on an assigned session; only the owner/spawner or current assignee can respond.
Session side controls such as rename, clear history, compact, model or mode changes, context-window changes, schedule cancellation, reload, and stop/close are permission guarded for the owner/spawner. Contributors are for collaborative steering, not administrative mutation of the session.
Participant add, role-change, and remove events are written into the session history so collaborators can understand how access changed over time. When an unassigned shared session is waiting for user input or an approval, contributor participants receive waiting-work inbox items along with the owner/spawner; viewers do not. Assigned sessions route waiting work to the assignee.
Assignments and handoff
Sessions can be assigned or unassigned across org members from session list actions and team workflows. Assignment metadata includes the assignee and optional notes, appears in session lists, and creates inbox notifications for handoffs. Use assignments when a running agent needs another teammate's attention or when ownership of follow-up work should move to someone else.
- Assign the session to a member and include a note when context matters.
- The assignee receives a personal Inbox handoff item.
- Opening the item selects the session and dismisses the notification.
- Rejecting the handoff clears the assignment so the team can re-route it.
Session mentions
The chat composer supports mentioning live sessions and child agents. Use a bare mention such as @reviewer or a braced mention such as @{Frontend Review} to route a message to another session. AFK resolves clear targets, asks for clarification when ambiguous, fans out multi-target dispatches, and records dispatch events in history.
Mentions use the same send_message delivery path as agent P2P messaging. Cross-account relay is rejected; same-account and same-org delivery is routed through the owning daemon via the Hub when needed.
Current and future governance
Built today: org roles, Org-visible, Restricted, and Legacy session visibility, shared dashboards, shared-session participants, member filters, assignments, inbox invites and handoff notifications, permission modes, plan review, hooks, webhooks, and durable session memory. Future governance work is policy-driven: richer audit views, SSO/SCIM, high-risk workflow review, escalation for stale waiting work, and policy simulation.