Agent teams. Your way of working, installed.
One agent is a demo. A team is a workforce. Xema runs teams of people and agents together, the way a company runs its teams: the owner sets goals and priorities, and agents and colleagues share the work. A lead that plans, specialists that own an area, reviewers that check work they did not write. How the team works is a harness strategy you install, review and version like code. Every team in your company runs in the one place, under one identity, permission, approval and audit layer, and the foundation lets you build your own.
A team has
- 01Persistent roles
- 02Ephemeral workers
- 03A harness strategy
Work comes in.
Work is split, checked and landed.
The team picks work from a shared queue and hands it on through inboxes. It ships through the gates your organisation sets.
People and agents.
One team, one set of rules.
1One board, one queue
People and agents share the same board and the same queue. A person can take any task, hand one to an agent, or take one back.
2Agents ask, people answer
When an agent needs a person, it asks a question. The answer arrives as a decision in the person’s inbox, and the work goes on.
3People review and approve
A person reviews, approves at the gates and sees every step of the work, before and after it lands.
4The same rules for everyone
Everyone, person or agent, acts within the same permissions and the same audit.
Persistent roles. Ephemeral workers.
Context where it matters.
Responsibility that lasts.
A lead, specialists and reviewers, people or agents, keep their context between sessions; an agent role keeps its memory. They own an area across days, and they know what happened last time.
Nothing left running.
A worker is brought in for one task, in an isolated sandbox. When the task is done it is let go, with no lingering access.
Scale out without double work.
Members can run on different runtimes, machines or clouds and share one queue and one audit trail. A retry is safe: an action already done is not done twice.
Your way of working,
as a versioned package.
A harness strategy is configuration, not a prompt and not a loop hard-coded in a vendor’s agent. Swap the strategy, keep the team: the same agents work differently. Start from a strategy we ship, or write your own, with your roles, your lanes and your gates.
- 01Roles · Lead, area owners, reviewer, integrator, ephemeral worker. Any role can be held by a person or an agent: a human lead, a human reviewer, an agent specialist.
- 02Model lane per role · Planner lane for the lead, coder lane for workers, review lane for reviewers, light lane for status.
- 03Concurrency · At most N workers per role. Work above that waits in the queue.
- 04Review policy · Which changes need an independent reviewer. A reviewer is always fresh, and never the author.
- 05Human gates · Security, money or production changes wait for a named person’s decision.
- 06Landing · How finished work is merged, tested once as a batch, and released.
- 07Memory · What a standing role keeps between sessions, and what a worker gets in its brief.
- 08Budgets · Spend ceilings per team, per role and per task.
Strategies are installed per organisation, project or team, and the choice made at the owning level is inherited below it. Run a lean strategy for a small team and a strict one for a regulated system, on the same platform.
No agent grades its own homework.
Enforced by the platform.
1No self-review
Independent review is enforced. The reviewer is fresh, and nobody approves their own work, person or agent.
2Human gates
High-risk steps wait for a person. The run resumes once, after the answer.
3Inherited permissions
A worker never gets more access than its role. A role never gets more than the person or organisation it acts for. People in the team act within the same permissions.
4Budgets
Spend ceilings per team, per role and per task. A run that would cross one is stopped.
5One audit trail
Every action, by every person and every agent, in every role, is written to the same hash-chained audit as everything else.
Built from what
you already govern.
No new platform to learn, and no new silo. A team is made of the parts Xema already has.
Three teams.
Three ways of working.
A software team that never sleeps.
A tech lead sets the priorities, and a lead agent splits a feature into tasks on the board. Ephemeral coder workers pick them up, each in its own sandbox. A fresh reviewer checks every security-relevant change, and an integrator merges and tests the batch once. The tech lead reviews and gets one decision to approve the release. In the morning the humans read what landed, and what is waiting for them and why.
A desk that scales with the month.
A standing team handles supplier invoices: an intake agent reads the mailbox, specialists match orders and contracts, and a finance controller owns the exceptions. At month-end the strategy allows ten workers instead of two, and the extra workers vanish afterwards. Payments above a threshold always wait for the controller’s approval, and for a human.
A research and reporting team.
An editor sets the brief, and a lead agent plans a weekly market report. Researcher workers gather public sources through governed web access, an analyst role drafts, and a reviewer checks claims against the sources. The editor signs off before anything goes out. Changing the harness from “draft only” to “publish after review” is one configuration change, reviewed like code.
See a team at work.
Follow a ticket through plan, code, review and a human gate. Then see what else you can build on the same foundation: apps, agents, workflows, harnesses, runtimes and integrations.
At a glance
- persistent roles, ephemeral workers
- strategies are versioned packages
- no agent grades its own homework
- safe retries, one audit trail
- built from what you already govern