Your AI already knows how to do the work. Deliverd makes sure it's allowed to.

Most companies we talk to are not short of AI that can do the work. They have an agent that triages claims, one that prices renewals, one that drafts the client report. Each knows how to find the right record and call the right API.

What none of them knows is whether it is allowed to. Is this refund inside the handler's authority, or does Finance sign it off? Can this report go to the client today, or does a partner read it first? Nothing in the model answers that, and nothing should. It is a question about your organisation, not about the task.

That is the whole of what Deliverd adds. Your AI already knows how to do the work. Deliverd makes sure it is allowed to.

A real workflow, start to finish

Take an insurer's claims agent. It reads an incoming claim, sees that Northwind Ltd were charged twice for invoice INV-2291, and works out that £1,240 should go back to their card. Up to that point nothing changes: this is the agent you already have, doing what it already does.

Then, before it calls the payments API, it makes one call to Deliverd:

const decision = await deliverd.gate({
  action: "finance.refund",
  externalId: `refund:${claim.id}`,
  input: { customer_id: claim.customerId, amount: 1240, currency: "GBP" },
});

if (!decision.allowed) return;
await payments.refund(decision.input);

Three things happen inside that call, and the agent waits for the answer.

1. Check policy

The refund is checked against rules your administrators wrote, against the business action finance.refund rather than against whichever function happens to implement it. Under £500 might be inside the handler's own authority, so the answer comes back in milliseconds and nobody is interrupted. Over £1,000 might need two people from Finance. An action no rule mentions is not waved through: it goes to a person, because nobody has decided about it yet.

The agent cannot write or change those rules. Policy is what decides whether an agent needs a person, so an agent that could edit it would be deciding that for itself.

2. Get approval

If a rule says a person decides, the right person is asked: a named approver, a group, or two people in sequence. They get it where they already are: a direct message in Slack or Microsoft Teams with Approve and Decline, an email that opens a page on their phone, or the request in the Deliverd app. They see what the agent wants to do and why, can approve it, decline it, or change the amount before approving. Their answer comes back to the agent.

That last part matters, which is why the code above refunds decision.input and not its own object. If Finance approves £1,200 instead of £1,240, the agent spends exactly what was approved.

3. Record evidence

Every decision is written down, including the ones policy settled without anybody watching: who asked, which rule applied, who decided under what authority, and what they were shown. When the agent reports back what it did, the record says how much of that Deliverd could check, not just that it happened. Months later, an auditor can download the whole thing as a PDF, JSON or CSV evidence pack without anybody reconstructing it from logs.

Then your system does the work

The last step is the one people expect us to take over, and we deliberately do not. The refund is made by your payments API, the report is sent by your mail system, the deployment runs in your pipeline. Deliverd answers "may it?"; your existing systems still do the "it".

That has two consequences worth spelling out.

• Nothing to rip out. You keep your agents, your frameworks and your APIs. Deliverd is one call before the action, over MCP, the REST API, the TypeScript or Python SDK, or the CLI.
• An honest boundary. Because your system carries out the act, Deliverd sees the agent's report of it, not the act itself, and says so on every receipt. An agent that skips the call is not stopped by us. That is why the call belongs in the agent's harness, where the framework asks before every consequential tool, rather than in a prompt the model may or may not follow.

Why it is built this way

You could put the permission check inside the agent. Plenty of teams start there: an if amount > 500 in the tool, a line in the system prompt saying "ask before refunding". It works until the threshold changes, or a second agent needs the same rule, or an auditor asks who approved last Tuesday's refund and the answer is in a chat log.

Taking the question out of the agent fixes all three. The rule lives in one place and changes without a deployment. Every agent that does finance.refund is held to it, however its tool is named. And the answer to "who approved this?" is a record, not an archaeology project.

Try it on one action

You do not need to put your whole estate behind it on day one. Pick the one action you would least like an agent to get wrong: a refund, a customer email, a production deploy. Register it, write two rules, and add the call. Everything else your agent does carries on exactly as before.

Your AI already knows how to do the work. Let it. Just make sure it is allowed to.

Deliverd is human-in-the-loop infrastructure for AI agents. The gate is documented in full in the developer docs.