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-wide sessions and manage members without editing admin-only configuration. |
member | Use the org workspace and see sessions they spawned or that are assigned to them. |
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. In org context, admins and managers can inspect the org fleet and filter by member. Members see their own sessions, sessions routed to them by assignment, and org sessions explicitly shared with them.
Dashboard cards use the persisted session metadata stream rather than opening a chat socket for every session, so larger teams can supervise many sessions without creating extra live chat connections.
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.
| 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 managers/admins can manage participants. Managers/admins can help coordinate sharing, but they do not bypass the response lock on an assigned session unless they are also the owner/spawner or current assignee.
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, shared dashboards, explicit 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: restricted session visibility, richer audit views, SSO/SCIM, high-risk workflow review, escalation for stale waiting work, and policy simulation.