Put AI to work, without the risk.
XYGON allows you to run AI agents inside your business processes. Agents do the work, but a named person decides at every gate.
Scroll to watch one tender response, run twice: first loose, then on rails.
Every step, every rule and every decision point, written down in one file you own.
Without rails, they skip checks, skip decisions, wander off the brief and spend before anyone has said yes.
Each agent gets a toolbox and a limit. Rules are checked by the engine, not a model. The decision goes to a person.
The same agents do the work. The process decides the path, and nothing moves past a gate without you.
We are building XYGON with a small number of design partners.
Case 7F3A91C2Tender response
Agent calls0
Spend€0.00
Scroll to run the case
The model does the work inside a step. Everything around it (the path, the limits and the decisions) is declared, enforced and recorded.
Write the process once, as a file you own. XYGON compiles it into a versioned snapshot, and every case runs on exactly the snapshot it started with. Publishing a change is itself a change, with a gate that shows what differs. Nothing runs on “latest”.
tender-response.flowdraft v15
gate bid_decision decided_by head_of_bids + gate legal_review + decided_by legal_counsel step submit agent
Publish v15waiting
An agent gets a declared set of tools and a limit on calls. It orders its own work inside the step. When it reaches the limit, the step ends with a typed error and the workflow decides what happens next. Text from outside (a document, an e-mail, a web page) is data, never an instruction.
Step draft_answeragent
tools tender.read archive.search draft.write max_calls 12 input tender notice (data) on_limit gate bid_decision
call 12/12 call_limit_reached workflow case sent to the gate
Where the process needs a decision, it stops and waits for a person. The decision is bound to that person and to the exact revision in front of them, used once, and recorded. A model can raise a finding at a gate. It never passes or fails one.
Gate recordcase 7F3A91C2
The ISO 13485 certificate expires before the contract starts.
Findings inform the person. They pass nothing.In design
Each agent step states its floor, its aim (performance or cost) and its ceiling. XYGON picks the model from measured results, moves to the next one only when a call fails mechanically, and never downgrades a step to save money without saying so. Budgets are reserved before each call and stop hard at the limit.
Step draft_answeraim: cost
Each organisation gets its own repository, database and backup key. Its boundary is enforced once, below every operation, and tested from outside. Definitions and history leave with you as files. Run it in our hosted service, in the EU or the US, or on your own servers. Your data stays in the region you choose.
Your organisationone of one
Panels are illustrations. The tender and its figures are examples.
XYGON does not replace your agents, models or tools. It sits between them and decides what may cross: agents call in, models are called out, your systems both ways. Every crossing is declared, authorised and recorded.
Working today in use in our own deployment In design specified, not yet built · Each card describes how XYGON is designed to work.
The runtime does the work inside one step. It sees only that step’s tools, through XYGON’s MCP server, with a short-lived token for one person and one case.
Every model call goes through one gateway: a signed catalogue, a route chosen for each step, and one ledger row per call naming the organisation, the key and the person.
A workflow is BPMN 2.0 under a constrained profile, compiled to a snapshot. A model drawn in your modelling tool comes in when it fits the profile; a durable engine runs it.
People sign in once. Every call between services carries a short-lived token naming the person, so a gate decision is bound to who made it.
A connector is a signed manifest: its operations, the secrets it needs by name, every host it may reach and where each one processes data. Agents and workflows see the same operations.
Each organisation’s definitions, documents and history live in its own repository and database, and leave as one bundle of plain files.
Product names belong to their owners. Listing a product means XYGON connects to it, not that its maker endorses XYGON.
Any process that is rule-bound, heavy on documents and needs a person to decide. Six processes a team could build on XYGON:
Each change drafted, tested and given a rollback plan; the change board approves before anything goes live.
Draft›Test›Rollback planApprove?›Deploy
Registers, sanctions lists and certificates checked against your policy; a named person approves each new supplier.
Collect›ScreenApprove?›Onboard
Evidence gathered and checked against the policy wording; above a set amount, a person decides whether to pay.
Gather›Check coverPay?›Settle
Find, qualify, write and submit, with a person deciding whether to draft and whether to bid.
Find›QualifyDraft?›WriteBid?›Submit
Incoming contracts checked clause by clause against your playbook; legal decides on every deviation.
Read›Check clausesAccept deviation?›Sign
A file built section by section against a standard, each part signed off by a qualified person.
Collect›CheckSign-off›File
We are working with a small number of companies building their first platform on XYGON. You bring a process and a team; we bring the engine and build alongside you.
Not sure yet? Watch how it works, under a minute.
XYGON /ˈziːɡɒn/ pronounced “zee-gon” noun
From Ancient Greek ζυγόν (zygón), also ζυγός (zygós).
In our case? All of the above. An engine that harnesses AI agents, keeps them in line inside your business processes, and holds the balance: agents do the work, and a named person decides at every gate.
