← Use cases/Example · Engineering

Software delivery with agents.
Agents do the work. The workflow keeps the gates.

An example of what a software team builds and runs on Xema, not a fixed product: your gates, your skills, your runtime. A ticket is planned, coded in a sandbox and reviewed against the team’s secure-coding skill. The change report is validated, the tech lead approves, and only then are the release notes written. The agents do the thinking; the workflow owns the order.

coded in a sandboxreviewed against your skilla person approves the release
  1. 01Plan from the ticket
  2. 02Code in a sandbox
  3. 03Review against the secure-coding skill
  4. 04Validate the change report
  5. 05Tech lead approves · a person decides
  6. 06Write release notes
Business outcome

Agents do the work, and the workflow keeps the gates.

What Xema provides
  • A workflow that owns the order of the steps
  • An isolated sandbox for every agent session
  • A tech lead approval before anything is released
01 Outcome

Changes that arrive
already reviewed.

A software team has a backlog of tickets. Agents can take a ticket a long way on their own, but nobody wants code released because an agent said it was fine. Here the review, the validation and the sign-off are steps of the process. They run every time, in the same order, and nobody has to remember them.

02 When it runs

The moment a ticket is ready.

When the team marks a ticket ready, the workflow starts. Each step hands its result to the next, and the run stops at the gate where a person has to decide.

ticket ready→plan, code, review→tech lead approvesno gate skipped
03 What it does

Plans. Codes.
Proves it.

i
Plans the change
An agent reads the ticket and writes a plan the rest of the run follows.
the plan
ii
Writes the code in a sandbox
The work happens in an isolated session with its own workspace, on the runtime you choose: Claude Code, Codex, Copilot, OpenCode or your own SDK. A full transcript is kept, and the session can be stopped at any time.
sandboxed
iii
Reviews it against your skill
A second agent checks the change against the team’s secure-coding skill. If it finds problems, the code goes back for another pass.
review loop
iv
Validates the change report
The report is checked against the spec before anyone is asked to look at it.
validated
v
Waits for the tech lead
The release waits for a person. The request says what changed and what was checked, and nothing moves until the answer comes.
a person decides
vi
Writes the release notes
Once approved, the notes are drafted on a light, low-cost lane, because that work does not need the strongest model.
cheap lane
04 What you get back

A record of every step.
Not a hunch.

For every change you can see the plan, the transcript of the session, the review findings, the validated report and who approved the release. Each decision and tool call is in the audit log.

The agents do the work; people keep the decisions that matter. The workflow, the skill and the gates are versioned like the code they protect.

05 Extending

Where teams take it next.

  • A
    Add a gate: a second reviewer, a spec check or a security sign-off is one more step in the workflow.
  • B
    Choose the lane for each step: a strong model for planning and review, a cheap one for notes. Swap a model once and every agent follows.
  • C
    Compare models on your own tickets: run the same task across lanes on a schedule, and score the results with your own tests.
  • D
    Gate on evals: a changed agent or a new model is promoted only when its evals pass, and a retired model hands over to a named successor.
  • E
    Run it as a team: a lead splits the feature, ephemeral workers code in parallel and an integrator lands the batch. Agent teams shows how a harness strategy sets it up.
  • F
    See the wider platform: the engineering teams page answers the eight questions teams ask about runtimes, tools, models and sandboxes.
Previous: Month-end closeNext: Operations desk →
Software delivery with agents — Xema