Real work, across your business and engineering.
These are examples of what teams build and run on Xema: four worked through step by step, and shorter patterns grouped by where the work happens. They show the shape of the work, not a product you install or a promised outcome: each one is built on Xema, and you shape yours.
A new joiner, every time
Onboard Maria, starting Monday
- done: AgentCreates her identityone record: her role, her manager, her start date
- done: XemaGrants access system by systemfive accounts now, only what her role needs; laptop ordered, payroll set up
- done: PersonHer manager approves finance accessthe one sensitive system waits for a person
- done: XemaRecords every grantwho approved, what, and when
Joiners and leavers.
The right access, first hour to last.
When someone joins, an agent sets up every account they need — and only the access their role calls for. A manager approves the sensitive ones, and on the last day everything is revoked. Every grant is approved and audited.
Read the use case- 01Create the identity
- 02Grant each system by role
- 03Approve sensitive access · a person decides
- 04Record every grant
- 05Revoke on the last day
Access is ready on day one, sized to the role, and everything is closed on the last day.
- An agent that sets up and closes out access
- Manager approval for the sensitive systems
- A record of what was given, who approved it and when
The month-end close.
Reconciled, flagged, signed off.
Agents reconcile the bank, the suppliers and the ledger, chase the receipts that are missing, and flag anything above your threshold for the controller. Nothing is posted without sign-off, and your finance team starts from a finished first pass instead of a blank spreadsheet.
Read the use case- 01Reconcile bank, suppliers, ledger
- 02Chase missing receipts
- 03Flag anomalies · a person decides
- 04Post approved entries only
- 05Close and file
Your finance team starts from a finished first pass, and nothing is posted without sign-off.
- Agents that do the matching and the chasing
- Controller and finance director sign-off
- A close pack with its full audit trail
Software delivery with agents.
Agents do the work. The workflow keeps the gates.
A ticket is planned, coded in a sandbox and reviewed against your team’s secure-coding skill. The change report is validated, the tech lead approves, and the release notes are written on a cheap lane. Each gate is a step you configure, not a convention people must remember.
Read the use case- 01Plan from the ticket
- 02Code in a sandbox
- 03Review against the secure-coding skill
- 04Validate the change report
- 05Tech lead approves · a person decides
- 06Write release notes
Agents do the work, and the workflow keeps the gates.
- A workflow that owns the order of the steps
- An isolated sandbox for every agent session
- A tech lead approval before anything is released
Operations desk.
Fast answers, within the user’s reach.
An agent reads live public data, such as prices and the weather forecast, and recommends a maintenance window. It asks to book a field crew; the booking is high-risk, so a supervisor approves it. With a grant, the agent tells the team in Teams or Slack. Without one, the post is refused, and the refusal is in the audit log.
Read the use case- 01Read live public data
- 02Recommend a maintenance window
- 03Ask to book a field crew
- 04Supervisor approves the booking · a person decides
- 05Post to Teams or Slack
- 06Refuse what no grant allows
Fast answers, and the agent cannot act beyond what its user may do.
- An agent that reads the data and drafts the plan
- A supervisor approval on the high-risk booking
- Every refusal in the audit log
More work teams build on Xema.
Shorter patterns, from connecting the systems you already run to building new applications on the platform.
Many systems and agents.
One process, one set of decisions.
Agents from different vendors, one business process.
- 01Claim arrives
- 02Document agent reads it
- 03CRM assistant finds the policy holder
- 04Your agent proposes the payout
- 05Claims manager approves above €25,000 · a person decides
Agents from different vendors work as one business process with one approval path.
- Shared capabilities, so permissions and approvals apply to every agent
- One audit trail across the process
A claim arrives. A vendor’s document agent reads it, your CRM’s assistant finds the policy holder, and your own agent proposes the payout. Each one reaches the work through the same capabilities, so permissions, approvals and audit are shared: a payout above €25,000 waits for a claims manager, whichever agent proposed it.
One intelligence layer over the software you already run.
Your ERP, CRM and internal applications stay the systems of record. Xema knows who and what each customer, order and supplier is, and who may do what to it; the data itself is read from the system that owns it. Agents ask one place, and every answer respects the access of the person they act for.
Modernise one piece at a time.
Start with external tools and vendor agents, MCP servers included, behind governed capabilities. Later, replace one of them with your own app, your own agent or a private model. The capability and its policies stay as they are, so the rules that already work keep working.
Requests, reviews, and the accounts nobody uses.
A software request, turned into an approved purchase.
When someone asks for a new tool, an agent checks the licences you already own, the prior decisions on similar requests, and the price quotes — then writes a one-page purchase brief and holds it for the budget owner and security sign-off. What comes out is an approved request ready to order.
One access review, every system, in parallel.
A single standard, tailored per team — finance systems reviewed by the controller, customer data by the support lead, infrastructure by IT. The agent runs the review across every system at once, rolls the findings into one prioritized digest, and raises a task for anything critical. You get finished, ranked findings, not a pile of exports.
Dormant accounts, found every day.
Each day the agent compares your accounts with your people records, finds the ones nobody uses or that belong to someone who has left, posts a digest where your team works, and raises a task for anything sensitive. Every finding links back to the run that produced it.
Cases resolved, not just deflected.
Cases worked to a resolution, not a reply.
- 01Read the case
- 02Confirm the duplicate charge in billing
- 03Team lead approves refunds above your limit · a person decides
- 04Issue the refund and close the case
The case is worked to a resolution, and the customer gets the confirmation.
- An agent that reads the case and checks billing
- An approval for refunds above your limit
A customer writes that they were charged twice. The agent reads the case from your ticketing system, confirms the duplicate charge in billing and asks to refund it. Refunds above your limit wait for a team lead; once approved, the refund is issued in billing, the case is closed and the customer gets the confirmation.
Every escalation, summarized before standup.
Each week the agent reads every escalated case, summarizes it against your product knowledge, and surfaces the patterns and regressions worth acting on. Engineering gets a finished brief — with a link back to every underlying case — instead of trawling tickets by hand.
Deal context, on the reps' side of the table.
Proposals and account briefs, drafted from the deal.
Starting from a live opportunity, the agent reads your sales system, prior call notes, product documentation and competitive intel, and drafts the proposal and the account brief your rep refines and sends. The advantage is context: every document reflects this customer and this deal, not a template.
Inbound RFPs, answered from approved answers only.
Starting from the buyer’s document, the agent breaks out every question and drafts each answer from your approved answer bank. Rows it cannot answer from that bank are queued for an expert before assembly. The advantage is control: nothing goes out that was not approved, and the risky rows are already flagged.
Counsel runs the playbook.
The agent does the line-by-line.
Contracts redlined against your playbook.
- 01Counsel sets the playbook
- 02Check every clause against your standards
- 03Flag deviations with a risk rating and precedent
- 04Record who approved what · a person decides
A redlined draft and a complete record of who approved what.
- An agent that does the line-by-line
- Risk ratings and precedent on each deviation
- Approvals recorded
Counsel sets the playbook; the agent does the line-by-line. Every clause is checked against your standards, deviations flagged with a risk rating and precedent, and alternate paths explored when a deal needs them. You get a redlined draft and a complete record of who approved what.
Regulatory changes, mapped to your contracts.
Each week the agent scans the regulatory sources for the jurisdictions you care about and reads them against your live products and contract templates. Counsel gets a finished brief with explicit "this affects template X" callouts — the analysis already done.
Daily checks, and a close that finishes.
Ledger anomalies, found the day they appear.
Every day the agent scans the ledger and journal entries, groups the anomalies it finds, and routes each to the right reviewer, with a trail back to the exact records. This is recurring monitoring: problems surface the day they happen. The month-end close is the long-running counterpart, carrying a whole period through reconciliation and sign-off.
Internal agents, scoped to the right knowledge.
Policy answers sized to who is asking.
The same question gets an answer from the content that person may see: a manager sees the approval guidelines, a contractor sees the contractor handbook, and salary bands stay with HR. Access follows each person’s role and team, and every answer cites the page it came from.
Handbook answers, and a handbook that stays current.
An internal "ask the handbook" grounded only in the policy pages your people team maintains. When an answer rests on a page that is out of date or contradicts another, the agent files a ticket for the page owner, so the handbook improves as people use it.
One project, from question to conclusion.
A formulation study, from hypothesis to conclusion.
Four researchers test whether a cheaper binder can replace the current one. Agents gather the outside literature, your lab notes and prior experiments; each finding is kept with its evidence, and the write-up is revised as the team challenges it. Every revision is kept, so what the team knew at each review is on record. The project ends with a conclusion the research lead signs off.
Build on Xema.
A new business application, without rebuilding the basics.
- 01Your team defines the scheduling rules
- 02Your team builds the dispatcher screens
- 03Run on the shared platform
A new business application without rebuilding the basics.
- Identity, permissions, approvals and audit
- Agents and the connections to the ERP and calendar
A field-service team needs an app to schedule engineer visits. Identity, permissions, approvals, audit, agents and the connections to the ERP and calendar are already there. The team builds the scheduling rules and the screens its dispatchers use.
An authorised coding agent builds and extends the app.
A coding agent builds an application on the platform from your team’s brief, and extends it when the team asks for changes. It works within the permissions it was given, so what it builds runs under the same rules as everything else.
A partner packages industry expertise.
A consultancy that knows insurance claims packages its processes, screens, skills and tools as one installable package. Each customer organisation installs it on its own Xema, connected to its own systems and governed by its own permissions.
From one solution to many, without silos.
The second solution reuses the capabilities the first one defined, such as the customer lookup, the refund and its approval rule, instead of building its own copy. Each new solution adds only what is new.
Got a department that doesn’t fit any of these?
Bring it to us and we'll scope a pilot together — the first process, the systems it has to touch, and the approvals it has to respect.
Common starting points
- day-one access for every joiner
- agents from several vendors in one process
- support cases worked to a resolution
- contracts redlined to your playbook
- the month-end close, signed off
- software delivery with agents, gated
- an operations desk that answers fast
- a new application on the platform