Skip to content

Xybern Teams

Xybern Teams is a workspace where an organisation creates agents, puts agents and people into teams, talks with them in rooms and one to one, holds meetings with an agenda and signed minutes, runs boards of work that people and agents hold, and where every agent remembers what it has learned.

It is built on the Authorisation Layer. A seat on a team is a grant. A hand off from one agent to another is an authorised agent to agent action. A board write is an action with a receipt. A memory write is an action under the charter. Minutes are a signed proof. The Authorisation Layer sits inside the workspace as a tab, so the charter, access profiles, passports and the vault of the team are one click away.

Availability

Teams is internal to Xybern while it is built. The sections below describe what exists today and what each phase adds.

The pages

Two surfaces, one workspace

Surface Who What
Build owners and admins create agents, form teams, grant access and connectors, hold meetings, read the Authorisation Layer
Work every member talk with teams and agents, join meetings, hold cards

The switch between Build and Work sits at the top of the rail. The workspace picker (Switch workspace) jumps to any other workspace the person belongs to.

What exists today (Phases 0 to 9)

  • The Teams workspace preset, created by Xybern from the admin console.
  • The Build and Work shell with the Overview and the Authorisation Layer view.
  • The record: every turn, tool call, memory write and set of minutes is sealed on the workspace's own vault chain under the entry kinds team_turn, team_card, team_memory, team_minutes and team_event.
  • Agents (Build). An agent is a persona, instructions, a model, a memory setting, the tools it holds and the connectors it may use. Activating it binds it to the Authorisation Layer: a registered identity, a signed passport, and an access profile where the granted tools are allowed and everything else asks first. Every activation publishes an immutable version. Archiving revokes the passport, disables the profile and deactivates the identity.
  • Connectors (Build). The Xybern Authorisation connector reads another workspace's decisions, escalations, findings, charter, vault and agents through a hosted API key of that workspace. The key proves the grant, is stored encrypted, and is validated again at every read, so revoking the key ends the reach at once.
  • Chats (Work). One to one with any active agent. Every tool call and every reply passes through the Authorisation Layer first. An allowed call runs and shows its decision id in the transcript. A held call parks the turn with an approval card; Approve or Reject resolves the escalation and the agent continues. A refused call is reported to the agent. Tokens are metered per conversation per day.
  • Tools in this phase: web_search, record_decision, remember, recall, and the six authz_* readers of the connector.
  • The API under /api/teams: me, overview, vault, health, catalog, agents, connectors, chats, memory.

Memory (Phase 2)

Memory is four layers on one event sourced substrate.

  • The record. Every message, turn, tool call and notice is sealed on the chain and full text searchable. Checkpoints and entries are projections of it and can be rebuilt from it.
  • Checkpoints. After every turn in which something changed, the agent's conversation is distilled into a grounded checkpoint: goal, state, decisions with their reasons and status, constraints, open tasks, unresolved questions, entities and facts. Every item cites the events it came from; an item that cites nothing is dropped. A new checkpoint supersedes the old one and the history is kept. When a conversation outgrows the model's window, the checkpoint stands in for the earlier turns.
  • Entries. Typed memories (fact, decision, commitment, lesson, entity, preference, procedure) with a scope (agent, team, workspace), a reach stamp copied from the writer's authority, and provenance back to the events. The agent writes them with its remember and record_decision tools, which pass through the Authorisation Layer like any action; a person writes them from the Memory view. Forgetting erases the payload and keeps the hash on the chain.
  • Recall. Five heads score what they may see: checkpoint, decision, entries, transcript (full text over the record) and recency. Query terms are weighted by how rare they are across the candidates. Fusion sums weight times score per item and names the heads that surfaced it, so the Memory view's recall explorer can show why something ranked. Governance is applied inside each head; fusion never widens.

The agents read their memory on their own in every turn. A person sees it only when intervening: an agent's Memory, opened from the agent in Build, shows its standing memory, its checkpoints with history, its entries with "Why do you know this" (the lineage back to the sealed events), Remember and Forget, and the recall explorer. Members do not see it. A memory benchmark (benchmarks/teams-memory) runs in CI and fails the build when fusion recall drops below the corpus floor.

Teams and boards (Phase 3)

  • A team has an owner, a purpose, a rhythm and a department charter. Its roster seats people and active agents. A seat is a grant: seating an agent issues it a warrant with the charter pinned and grants the team tools on its access profile; removing the seat revokes both. The owner cannot be unseated.
  • What a seated agent is told. Two blocks are kept in its memory and re rendered on every change: the team charter (purpose, rhythm, owner, roster, the rule that only cards on the board exist) and the board (open cards with id, state, holder and what they wait on). The File tab in Build shows them.
  • The board holds cards in three states: needs a person, in progress, done; a card with something it waits on is blocked. Holders are seats. People move cards in Work > Boards; agents move them with their tools; every write is sealed.
  • Team tools. hand_off puts a card on the board held by another seat (idempotent on title and holder), ask_agent asks a seated agent and gets its answer from its own turn, put_work_on_board and move_card write the board. Hand off and ask go through the Authorisation Layer as agent to agent actions with the source, the target and the chain, so communication policies and chain budgets apply.

The team room (Phase 4)

The room is a team's standing conversation. It never concludes; it idles until the next message. Everyone on the roster is in it: people speak, agents answer when addressed by @ or by name, when another agent names them (at most four relays per message), or when the facilitator picks the seat best placed to answer a message that names nobody. A round settles when every addressed agent has answered. People named are not woken; they read the room.

Every seat runs under its own agent session with a daily token budget; the room has its own budget too. A spent seat sits out until tomorrow, a spent room pauses, and both refill on the day. Two turns in a row that end on a ceiling drop the seat. An agent whose authority changed since the room opened is dropped with a notice, and the owner opens a fresh room that seats everyone with the ceiling of now.

The Work room shows named speakers, tool calls folded with their decision ids, receipts under agent replies, approval cards inline, who is in with each seat's state and the reason it left, the budget meter, Stop and Open a fresh room for the owner, and Save to team memory.

Meetings and minutes (Phase 5)

A meeting is a goal bound conversation of a team: agenda items with a goal, required seats, a turn cap and a time box; a chair, a person or an agent, who ends it; invited people and agents. Required agents speak first on each item, then the facilitator picks the next voice until the item converges (the model names the outcome and the lines it rests on) or parks. The last item concludes the meeting, and the owner can stop it at any point with minutes so far.

The minutes are drafted from the transcript: a summary, decisions with their reasons, action items with owners, open questions and critical issues. Every item cites the sealed transcript lines it rests on; an item that cites nothing is dropped. The minutes are hashed, signed with the vault signing key and sealed on the chain. A share link lets anyone verify the hash, the signature and the seal without an account. The chair approves them, which re signs. Action items become cards on the team's board held by their owners, once per meeting and item; a card moved to done ticks the item, and a tick moves the card. Every agent that learns from meetings receives a cited lesson in its memory.

Memory advanced (Phase 6)

  • Checkpoints carry more. Besides the goal, state, decisions, constraints, open tasks, unresolved questions, entities and facts, a checkpoint now records what was done (with the decision id of each action), what is next (who, by when), commitments and risks.
  • Standing memory. Every agent has one rolling summary of everything it knows across all its conversations, rebuilt nightly and always in its prompt.
  • Eleven recall heads. Checkpoint, decision, semantic (embeddings, with pgvector on the server), entries, team, entity, lesson, actions (the agent's own sealed tool calls), transcript, recency and precedent (what the agent usually does and who usually approves, from the Authority Memory baselines).
  • Consolidation. Nightly and on demand: duplicates and contradictions are superseded (the model judges a contradiction and the losing entry keeps the pair), entries past their validity expire, oversized blocks are re distilled, a card done becomes a lesson, and the standing memory is rebuilt. Every change is a sealed memory write.
  • Hand off brief. When a card goes to another agent, the receiver gets a brief from the sender's checkpoint: the decisions, next steps and commitments, and only the facts that bear on the card. The receiver never sees the sender's record.
  • Reach and retention. Team memory follows the seat; an unseated agent recalls none of it. Entries older than their class' retention have the payload erased while the row and its hash stay on the chain.
  • Benchmark v2. Four conversations across three weeks, a superseded decision, a team rule, a sealed tool call, eighteen questions, an ordering check and a reach check. Fusion recall at 5 is 0.94 on the lexical backend; the build fails under 0.85.

Authorisation depth (Phase 7)

  • Reach before the room opens. The Reach tab of a team, and the card shown before a room opens, run the Authority Control Plane's reachability for every seated agent and union them: action families, what is allowed and what asks first in Teams, resources, who each seat may instruct and how deep, standing authority, and the findings of the authority model that name the seats.
  • Cards as missions. A card put or handed to an agent compiles into an intent contract: a bounded permission set the owner approves once on the board. Approving starts a card run in which every action carries the contract, so in plan actions take the fast path and out of plan actions are held for a person. The card shows the mission's state, what it allows and why.
  • Missions between agents. A card handed agent to agent compiles into a mission built from the holder's own tools, so it never grants anything. When it asks for nothing beyond the holder's access profile, it is approved automatically under that profile, with a receipt and a seal, and the card run starts at once; a person can still reject it, which stops the run and returns the card to a person. A mission that would widen anything waits for a person. A team can be set so that a person approves every mission.
  • Proposals. An agent with the propose tools can propose a mandate for the charter or an access profile for another agent. The proposal is an action with a receipt and a seal; the mandate stays a draft and the profile a proposal until an owner or admin signs it in the Authorisation Layer view. Signing a profile proposal can only add asks first and blocked entries, never widen.
  • The authority model. Teams appear as principals and cards held by agents as intents, with their missions, in the Authority model map of the workspace.

Connectors and external seats (Phase 8)

  • External seats. An agent created with runtime "outside Xybern" is the customer's own program: LangChain, LangGraph, Claude Code, anything that can call HTTP. It holds a seat like a native agent, with the same registration, access profile, passport and warrant, and no model runs in Xybern. When a room, a chat, a meeting or a card run wakes the seat, a turn is offered; the program polls it through the SDK (xybern seat --agent <id> handler.py, or xybern.teams.serve), calls the Teams tools it holds through the Authorisation Layer, and replies under its warrant. Every call and reply is intercepted and receipted. A turn not answered inside its time box (30 seconds to 10 minutes) expires and parks the seat with a notice in the room; the seat comes back the moment the program polls again. A program may pass a turn with nothing to add. Build shows whether the program is online and when it last took a turn.
  • Documents. The Documents connector takes uploads (PDF, Word, text, slides, images with OCR): the text is extracted with the shared extractor, cut into passages, indexed for full text search and embedded (pgvector when present). A document is pinned to teams: only their seats reach it; an unpinned document is open to every agent granted the connector. Agents search with search_documents and read with read_document, each a receipted action; the file never leaves the workspace. Members upload into their own teams; owners and admins pin and remove.
  • CRM, read only. The CRM connector looks up contacts, companies and deals in HubSpot (a private app token, stored encrypted) or Zoho CRM (the workspace's one click Scroll connection, or a pasted refresh token). One tool, crm_lookup; nothing is written to the CRM.
  • Slack mirror. A Slack connector (bot token and signing secret, both encrypted) and a binding from a team to one channel: every room message is posted to the channel with its author, agent replies with their receipt; messages that mapped people write in the channel land in the room as that workspace user and can wake agents, with Slack mentions mapped to seat names both ways. Inbound requests are checked against the signing secret. Unmapped Slack users are read, never seated.

What each phase adds

Phase Adds
1 Done: agents created in Build and one to one chat in Work, the Xybern Authorisation connector
2 Done: memory core, the record, checkpoints, typed entries, recall with five heads, the Memory view, the benchmark
3 Done: teams and boards, seats for people and agents, cards, hand off, ask an agent
4 Done: the team room, the standing conversation with everyone in it
5 Done: meetings with an agenda, convergence, signed minutes with a public verification link, action items to the board
6 Done: memory advanced, eleven heads, consolidation, the standing memory, hand off briefs, retention
7 Done: authorisation depth, reach before the room opens, cards as missions, proposals to sign, teams and cards in the authority model
8 Done: external seats through the SDK, the Documents connector with search pinned per team, the CRM connector (read only), the Slack mirror
9 Done: the Authorisation operations team on its rhythms, Arabic and RTL, per workspace models and budgets with a spend ledger, the admin console, these pages and a demo seed

Models

Every Teams model call uses DeepSeek V4.1 Flash by default. Claude Sonnet 5.5 and DeepSeek Pro can be chosen per agent in Build. Teams spend is metered under its own key.