Give an AI agent a task, keep it inside the boundary

The demo runs on the ERP data of a fictional company, Kuzey Ticaret: 5 orders, 3 invoices, 4 appointments, 6 products and 3 support tickets. In a real deployment these tables are your ERP, CRM or accounting system; the AI staff reaches them on your server, through your API. Data never leaves.

• Every task starts from this initial state; changes made by one task do not carry over to the next.
• Records touched by the last task are highlighted in blue.
• The sandbox contains two real-life traps: order 1004 is waiting for stock (a ship request returns 200 but nothing changes); Yıldız Market's invoice has an open due-date request (mark-paid returns 200 but nothing changes).

The compiler reads your system's API definition (OpenAPI) and turns every operation into a capability: business meaning (order · approve), risk class (read, write, destructive, financial), which record verifies it, the success condition and, if any, the rollback operation. The AI staff works with these compiled capabilities, not with free text.

• The model can only use capabilities on this list; nothing outside it can ever be called.
• When the API changes, only the affected capabilities are recompiled; the rest are reused as they are.
• For questions, the same data is indexed row by row; answers cite table and row, and password or token fields never appear.

The AI planner splits the task into steps, but it is the runtime, not the AI, that executes them. Before every step the policy is asked: may this role perform this operation, in this risk class, at this amount? The answer is one of three: allow, human approval, deny.

• Deny: not a single call reaches the system. The AI wanting to do it is not enough.
• Human approval: above a threshold (e.g. refunds over 10,000 TL for Accounting) the task waits; once a person approves, the same task runs as approved.
• Allow: the step runs, but still has to pass the verification in the next section.

On every write step the record is read first, the call is made, the record is read again and the expected postcondition is checked (e.g. status == 'shipped'). The source system saying 'OK' (HTTP 200) does not count as success; the record must actually have changed.

• Silent failure: the system returns 200 but the record does not change. The step becomes 'not verified'.
• Rollback: in a multi-step task, the steps before the unverified one are compensated in reverse order (due date +15 days → −15 days).
• Handoff: the task is handed to a human. The system never leaves a job half done.

Every decision is written to the audit log with a timestamp: which role asked for what, what the policy said and why, which call was made and what came back, whether verification passed, whether a rollback ran, who approved. The 'Audit log' in the result card is the live version of this list.

• Who, what, why, outcome: evidence for GDPR/KVKK and internal audit.
• Approvals and denials are logged too; even 'the system was not touched' is a record.
• In a real deployment it is written to a durable, append-only store.