# Deliverd — full reference for language models > Deliverd is human-in-the-loop infrastructure for AI agents. When an agent needs a person — for approval, a decision, some information or a review — it makes one call. Deliverd can check an agent's action against policy, or ask a person, before the agent acts: it reaches the right person, under your rules about who may decide, and returns the answer to the agent. It works with any agent or tool over MCP, the REST API, the TypeScript and Python SDKs and the CLI, and keeps evidence of who decided what. Canonical site: https://deliverd.dev Short index: https://deliverd.dev/llms.txt Support: support@deliverd.dev Operated from Ireland. ## Asking a person: how an agent involves one When an agent needs a person it asks, a human answers on a page that works on a phone, and the result comes back so the agent can continue. One call is a complete flow; a named flow threads several together into one record. Full page: https://deliverd.dev/product/approvals ### Collect An agent that is missing something asks the people who have it. Typed questions — text, numbers, dates, single and multiple choice, yes or no — with required fields, a due date and reminders for whoever has not replied. Answers come back to the agent as one object. The person sees: A page that reads like replying to a colleague rather than filling in a form, with a draft saved as they go. An agent calls: request_information, get_collection ### Review Work goes in front of named readers before it goes anywhere else. Each reviewer approves it or asks for changes, with a note, and the agent reads the verdicts back. Distinct from a comment thread: a review records who was asked, what they were told to check, and what they decided. The person sees: The work, the brief, and two buttons — on a phone, and without a Deliverd account if they are a guest. An agent calls: request_review, get_review ### Approve Before a consequential action, the agent asks named people to authorise it: what it wants to do, why, what it costs, how risky it is, and what to read first. The approver can approve it, approve it with changes to the details the agent opened for correction, reject it with a reason, or ask the agent a question and see the answer arrive on the page. A request nobody answers escalates to more people and then expires, and someone can cover your approvals while you are away. The person sees: Approve, approve with changes, reject with a reason, or ask a question — on the page, from an email link, in Slack or Teams, or from a push notification on a phone. An agent calls: request_approval, get_approval, answer_approval_question ### Publish The finished thing lands on a secure versioned URL, behind the reader's own sign-in, looking like your firm. One primitive among the others, and none of the others needs it. The person sees: A link that opens for the people it was addressed to, and nobody else. An agent calls: publish_report, update_report ### Evidence One pack assembling every step of a piece of work: who was asked, what they said, what was decided and when, as a single timeline. JSON and CSV over the API, PDF from the download control. Each export is itself audited, with a digest, so the trail records which copy was handed over. The person sees: A download an auditor can read a year later without a Deliverd account. An agent calls: get_evidence ### Flows The thread tying one job's requests together — its approvals, reviews, requests for information and publishes — under a name and your own reference. The timeline is derived from what actually happened rather than from a plan drawn in advance. No visual builder, and nothing to maintain. The person sees: One page showing everything in that job and the order it happened in. An agent calls: create_flow, get_flow ### Agent policy Per agent, which of these it may ask for at all. Then standing rules by agent, action and risk: send it to two people rather than one, route it to a named set, or refuse it outright. A rule can only make a request harder — there is no rule that approves one. The person sees: Four switches on the agent's page and a rule builder in the admin console. An agent calls: nothing — an agent cannot reach its own policy ### The gate: asking before acting The agent says what it is about to do. Your policy answers. The requests above all end at a person. This one starts earlier: the agent declares the action and the arguments before performing it, and the answer comes from rules the organisation wrote — not from a branch in the agent's code. Most calls are settled by a rule and never reach anybody. An agent calls check_gate, get_gate over MCP, or POST https://deliverd.dev/api/v1/gates and GET https://deliverd.dev/api/v1/gates/{id} over REST. Three answers: - status "allowed", allowed true — A rule permitted it, and none of your ethics rules asked for a person. The agent carries on. Nobody was interrupted, and the decision is still written down. - status "denied", allowed false — A rule refused it — a policy rule, or one of your ethics rules. The agent stops, and reads which rule and why. A refusal is an answer, not an error — it arrives as a 200 rather than down the failure path. - status "pending", allowed false — No rule settled it, or an ethics rule asked for a person to weigh it. It became an ordinary approval: a named person decides on the page they already use, and the call can wait for them. An action nobody has written a rule about goes to a person: Not because it is suspect — because nobody has decided about it yet, and those are different things. Most permission systems default the other way and quietly allow whatever no rule mentions. This is new enough that nothing breaks by asking, and an unwritten rule is the one most likely to be the rule you meant to write. Act on the input that comes back, not the object you sent. It is what the action's schema validated and what the approver saw — and if they corrected a figure before agreeing, the corrected one is the one they agreed to. Who writes the rules: The rules belong to an administrator, and the product is built so they cannot quietly become anybody else's. An agent can ask. It cannot name the actions it is judged on, and it cannot write the policy that judges them. - Actions are registered before anything can ask about them: An administrator declares the actions agents may raise — finance.refund, and the fields it takes with their types. A request naming an action nobody registered is refused before a single rule is read, and so is input the schema does not describe. That is what makes a rule writable at all: amount is a number because the organisation said so, not because an agent sent one. - An agent cannot write the rules it is judged by: Registering an action and writing policy both refuse an agent identity outright. Authoring reads the person's role as well as the key's scopes — an owner or an administrator, checked freshly every time, because a key outlives a role change and allow is the sentence that removes the human. - A rule set is a version, and a live one cannot be edited: Changing active policy writes the next version rather than rewriting the one earlier decisions were made under. Evidence stores the version id, so what the policy said in March is a lookup rather than a reconstruction from history. - You can run it before it decides anything: Simulation puts a request you describe through the real evaluation and names the rule that would answer it, with the reason an administrator wrote. It records nothing and never reaches your figures — a tester that moved the number the product reports would be worth less than no tester at all. And it produces a number: Every evaluation is written down, the allows included, so the share of actions that never needed a person is a count rather than an estimate: the ones a rule allowed, over all of them. It is on the Policies screen over the last seven, thirty or ninety days — a person saying yes is not counted, because an organisation that sends everything to a human would otherwise score the same as one that sends nothing. What this does not do yet: The agent declares what it intends to do and then performs the action itself. Deliverd checks what the agent reports doing against what was agreed — the artifact's hash, the destination, the uses left — and refuses a report that differs, but it does not see an act it does not carry out, so a receipt that is never sent, or is false, is not caught. Closing that means a signed decision token binding the approved input, re-checked at the point of execution. Nothing does that today. The two rules the whole layer holds to: - An agent never decides: Agents ask. People approve, review and answer. An agent may not approve its own request, may not be an approver of anything, and may not grant itself scope. That is refused in the service rather than hidden in the interface — and an agent cannot read or change its own permissions at all, because nothing about them is reachable from the API it calls. - Every step is a row somebody can read: Each request, question, answer, verdict and decision is written to an audit trail with the agent or the person as the actor. The table rejects updates and deletions at the database level, and each organisation's entries are hash-chained, so an entry changed or removed afterwards shows when the chain is checked. That is the honest claim: tamper-evident history, not cryptographic immutability. Someone with direct access to the database could still rewrite the chain, which is why every evidence pack carries the chain's head and is signed. **Can an agent approve its own request?** No. The requester is removed from the approvers, an agent may not be an approver of anything, and the refusal lives in the service rather than the interface. A standing rule can raise the bar further — two people rather than one — but no rule can lower it, and there is no rule that approves a request automatically. **Does every action an agent takes need somebody to approve it?** No, and the whole point is that most do not. An agent can declare an action before performing it and the organisation's policy answers: a rule permits it, a rule refuses it, or nobody has written a rule and a named person decides. Rules are written against thresholds, agents and environments, so the routine case is settled without anybody being interrupted — unless one of your ethics rules asks for a person, in which case a permitted action goes to someone to weigh, and an ethics refusal refuses it. The decision is recorded either way, including the ones nobody saw, and it is advisory: the agent still performs the action itself. **Who writes those rules, and can an agent write its own?** An owner or an administrator of your organisation, against actions the organisation has registered. An agent cannot: writing a rule is how authority is granted, so an agent principal is refused at the service rather than hidden in the interface, and so is anybody whose role is not owner or administrator — checked freshly on every call, because a key outlives a role change. Rules are versioned, a version cannot be edited once it is active, and there is a simulator that answers what a request would have got without recording a decision. **What stops an agent from simply not asking?** Nothing, for an action Deliverd does not carry out itself, and it is better to say so. A decision is advisory today: the agent reports what it intends to do, policy answers, and the agent then performs the action itself. Its receipt afterwards is checked against what was agreed — a different hash, another destination or a spent use is refused — but Deliverd does not see the act, so a receipt that is never sent is not caught. Publishing is the exception, because there Deliverd is the one acting: policy is applied on the server to every publish and share. An agent misreporting to the policy engine is an agent misreporting to its own runtime, which is the trust boundary every SDK already has. Closing it takes a signed decision token binding the approved input, re-checked where the action executes. What you get today is that the question is askable, answered by somebody other than the agent, and written down. **Do the people deciding need a Deliverd account?** Usually not. Approvers are normally members of your organisation, signed in through your own identity provider. Reviewers and the people answering a request for information can be external: they get a link that emails them a one-time code, and the page opens once the code is verified. An administrator can also let a guest approve — somebody outside the organisation you already share with, deciding from their email — but only for low- and medium-risk requests, and never one an ethics rule flagged. **What happens if nobody responds?** It escalates, then it expires. A standing rule can bring more people in once a request has gone unanswered for as long as you set, and anybody already asked can bring somebody in from the page; escalation only ever widens the circle, so nobody is taken off and no decision gets easier. Whoever is still waiting gets a nudge, and an approval with an expiry closes itself rather than sitting pending forever. **How does the agent find out what was decided?** Whichever suits how it runs. It can name a callbackUrl when it asks, and that address receives a signed POST when a person answers — so a serverless function can sleep instead of holding a process open. The TypeScript and Python SDKs do the waiting for you, and the TypeScript one has adapters for the Claude Agent SDK, the AI SDK, the OpenAI Agents SDK and LangGraph. Or it polls — get_approval, get_review, get_collection over MCP, or the matching REST endpoints — or your organisation receives a signed webhook when the decision lands, as a Slack or Teams card if you point the endpoint at one. **Can the approver correct a figure rather than reject the whole request?** Yes, where the agent allows it. The agent marks which details are open for correction — an amount, a date — and the limits on each: a range, a list of choices, a length. The approver changes the value and approves with changes, the page records what it was and what it became, and the agent receives the corrected values to act on. A request that needs more than one approval can only be approved as proposed. **What happens when the approver is on holiday?** They name a colleague to cover their approvals, for up to 90 days. While it runs, new requests that name them also reach the colleague, and anything already waiting is passed on. They stay on every request and can still decide, and cover widens who may answer without raising how many must. **Can someone outside the firm approve — a client signing off their own accounts?** Yes, if an administrator switches guest approvers on. The guest is somebody you already share with, and decides from the link in their email with no account. The limits are deliberate: only low- and medium-risk requests, never one an ethics rule flagged, no restricted fields, and no questions or bringing anybody in. A request that breaks a limit is refused when it is made, with the reason. **What do we hand an auditor a year later?** An evidence pack: every step of the work, who was asked, what they said, what was decided and when, as one timeline in JSON, CSV or PDF. It carries a digest so an altered copy can be told apart, and the export itself is audited. **Is there a workflow builder to maintain?** No, and deliberately. A flow is a name and a reference that requests attach themselves to as the agent makes them; the timeline is derived from what actually happened rather than from a diagram drawn in advance. There is nothing to keep in step with the code. **Can an agent ask someone to review the work before it goes out?** Yes. It calls request_review naming who should read it and what to check. Each reviewer approves it or asks for changes, with a note, and the agent reads the verdicts back and acts on them. Reviewers can be people outside your organisation, verified by a one-time code. **Can an agent ask people for information it is missing?** Yes. request_information sends named people typed questions — text, numbers, dates, choices, yes or no — with required fields, a due date and reminders for anyone who has not replied. They answer on a page that saves a draft as they go, and the answers come back to the agent as one object. **Can we make approvers stop and think about sensitive requests?** Yes, on every plan. An administrator writes ethics rules for requests that touch someone's job, money, health or privacy, matched on a registered action and its input, an agent, or keywords. A rule can flag the request, so whoever decides sees the concern first and has to say why it is right to go ahead; ask more people to agree; or refuse it. Ethics rules only add oversight: none of them can approve anything. They read approvals requested through the API or MCP and actions at the gate, and the six starter rules arrive switched off. **Does Deliverd use a model to judge requests?** Only if you switch it on. The optional ethics model screen, on Business Starter and above, has a model read each request an agent makes and add up to three concerns beside those your rules raise. It only adds concerns — it never escalates, refuses or approves, and a person still decides. It sends the request's title, description, action and input to Anthropic, leaving out fields marked restricted, and is capped each month: 500 on Business Starter, 1,000 on Business, 10,000 on Enterprise. Your own ethics rules are not a model; they match actions, input and keywords. ## Before a consequential action: gates Declare an action with check_gate before you perform it, and branch on the answer: allowed, refused, or waiting for a named person. After acting, report what ran with record_execution. On governed work, check_governance_gate also refuses while controls are outstanding. See https://deliverd.dev/product/gates. What a gate does, and what it does not: - Approval coordination: Any action Deliverd does not carry out itself — a payment, a deployment, a message. The agent asks before it acts, a rule or a person answers, and the agent acts on the answer. The decision is advisory to the agent's runtime: Deliverd records the question and the answer, and does not see the act. Where the code that performs the act is yours, it can check the signed decision token against the input before acting, and turn away one nobody agreed to. - Enforcement: Only where Deliverd itself performs the act. Publishing: publishing policy is applied on the server to every publish and every share, and an agent cannot make a report public. And a staged report release, POST /api/v1/gates/{id}/release, where Deliverd makes the approved version live itself. - Execution evidence: Every receipt an agent reports after acting. Each receipt says how much was checked: verified when Deliverd did it, hash_matched when the reported artifact's hash matched the approved one, and reported when it is the agent's word. A receipt whose hash, destination or uses differ from the permission is refused. Mediated execution for arbitrary actions, and stronger attestation of what an agent did, are on the roadmap and not built. ## Keeping long work on its objective: tasks Objectives are included in Team, Business Starter, Business and Enterprise. A task keeps the goal of a piece of work apart from the conversation doing it. Start one with create_task at the beginning of anything substantial; call get_task_context when you resume, after a restart or in a different tool, instead of asking the person to re-explain. Branch a separate problem with create_side_task and bring its result back with apply_side_task. When people need to read the outcome, write the report from get_task_context and publish it with the task's taskId; it then shows on the task and comes back in its context. Only a person changes the objective. See https://deliverd.dev/product/tasks. ## Publish an HTML file right now If a person asked you to publish an HTML document to Deliverd, use the first of these that applies to you. 1. You have the Deliverd MCP tools (publish_report is in your tool list): call publish_report with the HTML. That is all. 2. You can make an HTTP request — a shell, code execution, or a fetch tool that can POST. No account or key is needed: curl -X POST https://deliverd.dev/api/v1/drafts -H "Content-Type: text/html" --data-binary @report.html or POST JSON { "html": "...", "title": "..." } to the same address. The response carries a claimUrl. Give it to the person and stop: they sign in, or create a free account, and publish it with one click, private to them until they share it. Nothing is visible to anyone before then. The link works once and lasts 24 hours; documents up to 2 MB. Do not retry or poll. 3. You can only read web pages: tell the person the one step that connects you, then publish with option 1. In ChatGPT: Turn on developer mode (Settings → Apps → Advanced settings → Developer mode. Custom connectors need a paid ChatGPT plan.); then Add a custom connector with this address: https://deliverd.dev/api/mcp (The connector registers itself and sends you to a screen where you choose the organisation and approve access.). Any other assistant: https://deliverd.dev/connect. Or they can upload the file themselves at https://deliverd.dev/publish once signed in. ## Publishing: how an agent's work reaches people Publishing is how an agent's work reaches people: a report, a dashboard or a prototype on a secure address, opened with the reader's own sign-in, versioned, commented on, and printed to a PDF when somebody needs a file. One of the primitives, and the only one that needs a report to exist. Full page: https://deliverd.dev/product/publishing - One address, every version: The report lands on an address you can send — on your own domain, on the paid plans. Publishing again puts a new version behind the same URL and keeps every earlier one, scanned and restorable, so the link you shared in March still opens today's numbers. - Behind the reader's own sign-in: Send it to a named person, a workspace, a directory group, an email domain or a verified guest. Readers authenticate with the identity their organisation already uses, or by a one-time code; the audience is checked on every request, so a forwarded link forwards nothing. - Nothing overwritten by accident: Pass the version you read and a publish that has been overtaken is refused, telling the agent which version is current. Roll back to any version, or pin one so every reader sees it until you unpin. - A PDF when they need a file: Some readers file things. Add ?format=pdf to a report's link, or use the download control, and the current version is rendered to a PDF for that reader — the same access check, the same watermark, nothing to export by hand. - A portal at your address: The root of your reports host lists every report the signed-in reader is allowed to open — the one link a client keeps, instead of one link per pack. - Comments that reach the agent: A reader selects a sentence and comments on it. The thread stays attached to that passage across versions, and the agent reads the threads, fixes what they point at, republishes and marks them resolved — or asks for all of them as one revision brief. - Numbers that refresh without republishing: A report can read datasets you update through the API, so a dashboard shows this morning's figures without a new version. The report itself is still stored, signed bytes behind the same access check. - Recurring, from the same address: Put a report on a schedule and the agent is told when it is due. It publishes the new version, the same people open the same link, and nothing has to be shared again. - Held for approval before it leaves: A publishing rule can hold a version for a person's approval: it is stored and scanned, the reader sees nothing until someone with the authority says so, and the decision is on the record. Off by default; switch it on for agent publishes, for anything addressed outside the firm, or both. - A watermark per reader: Switch it on in the sharing policy and each reader sees the report with their own identity across it — so a screenshot says who took it. - Inside your SharePoint: Allow a SharePoint site by origin and any report can be framed on a page there. It is still served and access-checked here: the page shows the report to the people who may open it and a sign-in link to everyone else. - Secrets caught before they go live: Every bundle is scanned before it goes live for API keys, tokens and private-key material — a hit blocks the publish rather than warning about it — and riskier script patterns are recorded against the version. - Sent to a list, one link each: Send a report to up to fifty addresses with a covering note. Each gets their own link, tied to their own guest record, so the audit trail and the analytics still say who opened what. - Start from a report you already have: Offer any report as a template and anyone who can already open it can start from a copy they own. Four sector starters ship with every organisation. ## Ethics: what an organisation's rules add An organisation can write ethics rules about the requests it wants a person to weigh before an agent goes ahead. They read every approval request and every gate check made through the API or the MCP server. Each rule has one of 3 effects (`flag`, `escalate`, `refuse`): it puts a concern in front of whoever decides, asks more people to agree, or refuses the request. Ethics only ever adds oversight. No rule, and nothing the model screen says, can let through something that would otherwise have been stopped, so rewording a request to avoid a rule gains nothing. At the gate, ethics applies after the policy answer: a flag means a rule cannot settle the action alone, so an action policy allowed goes to a person instead, and a refusing rule turns the answer into denied (allowed false) with the rule's concern as the reason. On a request for approval, matching rules arrive in the `concerns` field (always present, empty when nothing matched), and a refusing rule stops the request being created: 403 `refused_by_rule`, with the concern in the message. Treat both as answers. Stop, and tell the person you work for which rule refused and why. The model screen is opt-in: an administrator on Business Starter, Business and Enterprise can switch it on. It sends the request's title, description, action and input (minus any field the action marks restricted) to Anthropic, whose model may add up to 3 concerns. It only adds concerns. It never refuses, escalates or removes anything, and when it cannot run the organisation's own rules decide alone. For developers: https://deliverd.dev/docs/developers/ethics. For administrators writing the rules: https://deliverd.dev/docs/guide/admin/ethics. ## What it is, in the site's own words **What is Deliverd?** Deliverd is human-in-the-loop infrastructure for AI agents. When an agent needs a person — for approval, a decision, some information or a review — it makes one call. Deliverd can check an agent's action against policy, or ask a person, before the agent acts: it reaches the right person, under your rules about who may decide, and returns the answer to the agent. It works with any agent or tool over MCP, the REST API, the TypeScript and Python SDKs and the CLI, and keeps evidence of who decided what. **Does Deliverd run the agent, or generate the work?** No. Your agent does the work, in whatever tool it runs in. Deliverd is the layer it uses to involve a person — to ask for approval, a review, an answer or a decision — and, when the work is something people need to read, the secure place it is published. **Can an AI agent ask a person for approval before it acts?** Yes. An agent calls request_approval over MCP, or POST /api/v1/approvals, naming what it wants to do and who should decide. The approver can approve, approve with changes, reject with a reason, or ask the agent a question — on a page that works on a phone, from an email link, in Slack or Teams, or from a push notification — and someone can cover their approvals while they are away. The agent reads the decision back and acts only on a yes. Every step is audited. **Can we prove afterwards how a piece of work was decided?** Yes. Approvals, reviews, questions and publishes can be tied to a project, and the whole project exports as an evidence pack: every step, who was asked, what they said and when, as one timeline in JSON, CSV or PDF. The audit table rejects updates and deletions at the database level and is hash-chained per organisation, so the history is tamper-evident, and the pack is signed with a published key, so anyone can check a copy offline. **Which AI tools work with Deliverd?** Claude, ChatGPT, Microsoft 365 Copilot, Copilot Studio, Foundry, Cursor, Codex, VS Code, Windsurf, Gemini, internal agents — anything that can use MCP, our REST API or the CLI. Jev, TypeSafe’s decision model, works with Deliverd the other way round: your agent calls it to settle the routine case, and calls us for what it cannot. **Is there a free trial?** Free has no time limit. A paid plan starts with a 14-day trial the first time an organisation subscribes, and nothing is charged until it ends. **Is our content used to train AI models?** No. Deliverd does not use your content to train models, and your reports are not sent to a model provider. There is one opt-in exception, and it is not about training: an organisation on Business Starter and above that switches on the ethics model screen sends the title, description, action and input of each request an agent makes to Anthropic, so a model can suggest concerns for the approver. It is off unless an administrator turns it on. **Does Deliverd support enterprise SSO?** Yes — SAML 2.0 and OpenID Connect, which between them cover Microsoft Entra ID, Okta, Google Workspace, PingIdentity, OneLogin, Auth0 and anything else speaking either protocol. You can require it, so passwords stop working for your domains. **Does Deliverd work with decision models like Jev?** Yes, and it is a different kind of “works with”. Jev, TypeSafe’s decision model, settles the routine case in about a second without interrupting anybody; what it cannot settle it hands back as an escalation, and Deliverd is where that escalation goes to a person. The tools above connect to Deliverd; Jev is something your agent asks before it acts. Its answers can also be carried into a gate request as ordinary input, so a rule can make a request harder when the model is worried — never easier, because an answer the agent carried in is a fact the agent chose. **What is a task?** A task keeps the goal of a piece of AI work apart from the conversation doing it: the objective, a short state — where it stands, the next action, the open questions — and side tasks that branch a problem and come back with a result. Any connected tool reads the same task, so switching models does not mean starting over. Objectives are included in Team, Business Starter, Business and Enterprise. **What is Compliance Mode?** Governance for AI work, built on tasks: an AI system register, an owner, a risk and a data classification on each piece of governed work, the controls that follow, evidence, approvals and exceptions, and one evidence pack. It records how the work was governed; it does not certify compliance with any law. It is included in Business and Enterprise. **Can an agent publish on its own?** Yes. Agents get their own identity, scoped to what each may ask for and where it may publish, and you define the workspaces and audiences each one may publish to. An agent can never make a report public, whether it has its own key or is an assistant connected over OAuth — that is enforced in code, not by configuration. **What happens when someone forwards a link?** Nothing they did not already have. The URL is not the permission — every request is evaluated against your organisation's identity and sharing policy, so the recipient still has to satisfy it. **Can we use our own domain?** Yes, on Team and above. You verify it with a DNS TXT record. **Can a report sit inside our SharePoint or intranet?** Yes. An administrator allows your SharePoint site by origin, and any report can then be framed on a page there with an embed snippet. The report is still served and access-checked by Deliverd; a reader who is not signed in gets a link that opens it in a new tab. **Can we set rules about what may be published?** Yes, on Business and above. Publishing policies are evaluated on every publish and share — deny external sharing for a classification, cap how long a link may live, require a workspace — and there is a tester that shows what a given publish would do before anyone tries it. **What happens when someone without access opens a link?** They can ask. The page offers a request-access form; the report's owner is notified, approves or declines from the report's page, and the requester is told. Nobody has to forward the link to the right person to find out who that is. **What if the AI put a secret in the report?** The publish is blocked. Every bundle is scanned before it goes live for API keys, tokens and private-key material — AWS, GitHub, Slack, Stripe, OpenAI, Anthropic and the generic shapes — and a hit is a blocker, not a warning. Riskier script patterns are recorded as warnings against the version. ## Who it is for ### Consultancies — https://deliverd.dev/for/consultancies AI drafted the pack. A partner signed it off. Get a partner's sign-off on everything an agent drafts for a client, without chasing anyone for it. When the steering-committee pack is ready, the agent stops to ask the partner who owns the engagement — on their phone or from an email — and carries on when they answer. The client then opens the signed-off version at one secure address under your firm's name, and the record shows who approved what the client saw. The situation: - The agent drafted it; nobody signed it off: A model wrote the first draft and a partner's name goes on the last. Between the two there is no step where the agent stops and asks, no page where the partner decides, and no record that anyone checked. - Version drift, discovered in the room: Two people open what they believe is the same pack and disagree about a number. The attachment is a copy the moment it is sent, so there is no way to reach the one somebody is holding. - A year later, nobody can reconstruct it: When a recommendation is questioned, what you need is who signed it off, what they were shown, when, and who read it. What you have is a shared drive and a mail archive. What Deliverd does for consultancies: - Your AI asks before it acts: An agent that needs a decision puts it to a named person and waits: what it wants to do, why, how risky it is, and what to read first. They approve, approve with changes, reject with a reason, or ask the agent a question — on the page, from an email link, in Slack or Teams, or from a push notification on a phone — and a colleague can cover their approvals while they are away. It can also ask for a review, or for information it is missing, the same way. - Sign-off before it leaves: A publishing rule can hold work for a partner's approval: the version is stored and scanned, the client sees nothing until someone with the authority says so, and the decision is on the record. Off by default; switch it on for agent publishes, for anything addressed outside the firm, or both. - An address, not an attachment: The work lands on a URL you can send. It stays put, so the link you shared at the kick-off still opens today's version rather than a copy of what it looked like in March. - Opened with the client's own sign-in: Readers authenticate with the identity their organisation already uses, including SAML and OpenID Connect single sign-on. Nobody gets a password to remember, and nobody gets a file to leave with. - It looks like your firm: Your name and logo, on your own verified domain, with notifications sent from your domain once it is verified. On the paid plans the reader sees your practice rather than ours. - The work keeps its objective: A task holds what the work is for apart from the conversation doing it, with a short state — where it stands, the next action, what is in the way — that any agent reads when it resumes. Side tasks take a bug or a piece of research out of the main thread and come back with a result. Switch tool or model and the next one picks up where things stand instead of starting over, and only a person changes the objective. (Included in Team, Business Starter, Business and Enterprise.) - A second thought, where it matters: Your organisation writes rules for requests that touch someone's job, money, health or privacy, or that cannot be undone. When one matches, whoever decides sees the concern first and has to say why it is right to go ahead; a rule can also ask more people to agree, or refuse. Ethics rules only add oversight — none of them can approve anything — and they are on every plan. - Every version kept, one URL: Reissuing updates the address and keeps what was there before. You can see what changed between two drafts and roll back if the new one is wrong. - A record of who opened it: Views, versions, access changes and share links are written to an audit trail you can export — which is the difference between believing a client saw something and being able to show it. - A workspace per client: Segment who can reach what, so an analyst on one engagement cannot browse another. Access is decided per report and evaluated on every request, assets included. - Inside the client's own intranet: Allow a SharePoint site by origin and a report can be framed on a page there. It is still served and access-checked here, so the page shows the report to the people who may open it and a sign-in link to everyone else. - One pack for the auditor: Every step of a piece of work — who was asked, what they said, what was decided and when — exported as a single timeline in JSON, CSV or PDF. It carries a digest and the head of the hash-chained audit trail, signed with a published key, so anyone can check a copy offline, and the export itself is on the record. **Can the agent ask a partner to sign off before the pack goes to the client?** Yes, two ways. Before it acts, the agent asks a named partner with request_approval and waits: they approve, correct a figure the agent marked as correctable, reject with a reason or ask the agent a question, from a phone or an email link. And a publishing rule can hold any publish for a partner's approval, so nothing addressed to a client goes live until someone with the authority says so. **Can we show who approved what a client was shown?** Yes. The approval, the publish and every view are on one record — who was asked, what they saw, what they decided and when — exportable as an evidence pack with a digest, so an altered copy can be told apart. **Can each client only see their own engagement?** Yes. Give each engagement a workspace and grant access per report. Access is evaluated on every request, including images and other assets, so nothing is reachable by guessing a URL. **What if the client's people are not in any directory we control?** They do not need to be. A share link can require the reader to verify an emailed one-time code before it opens, and can be restricted to their firm's email domains. **Does it carry our branding or yours?** Yours, on the paid plans: your name and logo, your own verified domain, and notifications sent from your domain once its DNS records are in place. **Can we prove what a client was shown?** Views, version changes, access grants and share links are all written to an audit trail you can export. Retention is set by your plan, longer on the higher plans; on Enterprise your administrators set it, up to ten years. **Can an agent working with client data be made to stop and ask?** Yes. Two starter ethics rules fit engagement work: “Health and personal data” asks whether there is a lawful basis when a request involves health or other special-category personal data, and “Messages sent in someone else's name” asks whether a recipient would be misled about who wrote something or what it commits to. They arrive switched off; turn them on and a flagged approval needs a reason before anyone goes ahead. ### Accountancy and advisory — https://deliverd.dev/for/accountancy AI prepares the pack. A partner signs it off. Get a partner's approval on everything an agent prepares, without chasing anyone for it, and keep the record a file review will ask for. Before an agent posts a journal or sends a letter in a partner's name, it stops to ask that partner — on their phone or from an email — and waits for the answer. The approved pack reaches the client behind their own sign-in, not as an attachment. The situation: - The agent prepared it; a partner has to own it: A journal posted, a letter in a partner's name, a pack sent to a group finance director: each is a decision the partner owns and the agent would make alone. The pause has to be a question the agent asks a person, not a prompt in a tool. - The most sensitive thing you produce travels the least safely: An attachment is a copy with no owner. Once it is sent, it can be forwarded, kept after somebody leaves, and read by whoever ends up with the mailbox. - Retention is a policy nobody can evidence: You have an obligation about how long records are kept, who approved them and who saw them. What you can actually produce is a folder and a best guess. What Deliverd does for accountancy and advisory: - Your AI asks before it acts: An agent that needs a decision puts it to a named person and waits: what it wants to do, why, how risky it is, and what to read first. They approve, approve with changes, reject with a reason, or ask the agent a question — on the page, from an email link, in Slack or Teams, or from a push notification on a phone — and a colleague can cover their approvals while they are away. It can also ask for a review, or for information it is missing, the same way. - Sign-off before it leaves: A publishing rule can hold work for a partner's approval: the version is stored and scanned, the client sees nothing until someone with the authority says so, and the decision is on the record. Off by default; switch it on for agent publishes, for anything addressed outside the firm, or both. - Opened with the client's own sign-in: Readers authenticate with the identity their organisation already uses, including SAML and OpenID Connect single sign-on. Nobody gets a password to remember, and nobody gets a file to leave with. - A workspace per client: Segment who can reach what, so an analyst on one engagement cannot browse another. Access is decided per report and evaluated on every request, assets included. - A check before the agent acts: Before a consequential action — a payment, a deployment, a message to a customer — the agent declares what it is about to do and waits for the answer. A named person decides, or your organisation's rules settle the routine cases and send the rest to a person; with no rules, every one goes to a person. Afterwards the agent records what ran, and the record is checked against what was allowed. (On every plan; policy rules included in Business Starter, Business and Enterprise.) - A record of who opened it: Views, versions, access changes and share links are written to an audit trail you can export — which is the difference between believing a client saw something and being able to show it. - An address, not an attachment: The work lands on a URL you can send. It stays put, so the link you shared at the kick-off still opens today's version rather than a copy of what it looked like in March. - It looks like your firm: Your name and logo, on your own verified domain, with notifications sent from your domain once it is verified. On the paid plans the reader sees your practice rather than ours. - A second thought, where it matters: Your organisation writes rules for requests that touch someone's job, money, health or privacy, or that cannot be undone. When one matches, whoever decides sees the concern first and has to say why it is right to go ahead; a rule can also ask more people to agree, or refuse. Ethics rules only add oversight — none of them can approve anything — and they are on every plan. - The right person can ask: Somebody who needs a report and cannot open it asks for access from the page itself, and whoever owns it decides. Better than the alternative, which is a copy forwarded out of goodwill. - Rules your firm sets once: Publishing policies run on every publish and share: no external sharing for a classification, a ceiling on how long a link may live, a workspace that must be named. A tester shows what a publish would do before anyone tries it. - One pack for the auditor: Every step of a piece of work — who was asked, what they said, what was decided and when — exported as a single timeline in JSON, CSV or PDF. It carries a digest and the head of the hash-chained audit trail, signed with a published key, so anyone can check a copy offline, and the export itself is on the record. - When deletion has to stop, it stops: A matter opens and routine destruction becomes the wrong thing to do. Place a hold — on the whole organisation, one project, one task, one person’s material or one report, over a date range if you need one — and the retention schedule suspends, the organisation cannot be closed, and what the hold covers cannot be deleted: a report’s data, a task, a retracted comment’s attachments. Refused in the database, not by a setting somebody has to remember. Released with a reason, and both ends are on the record. (Included in Enterprise.) **Can an agent posting a journal or sending a client letter be made to ask first?** Yes. The agent asks a named partner with request_approval, or declares the action at a gate, and waits. With no rules a partner decides every one; rules can settle the routine cases and send the rest to a person. A gate is advisory: the agent asks and then performs the action itself, and its execution record shows whether what ran matches what was allowed. **Can we separate one client's entities from another's?** Yes. Workspaces segment access, and each report is granted to named people, groups or a whole organisation. The decision is checked on every request rather than at the link. **What happens when someone leaves the client?** If they signed in through their employer's identity provider, removing them there ends their access at once — there is no separate password to revoke and no file already on their laptop. **How long is the record kept?** Audit and view history are retained for a period set by your plan. On Enterprise, an administrator can lengthen the audit history to up to ten years. **Can a client ask for access rather than emailing us?** Yes. Someone who cannot open a report can request access from the page itself, and whoever owns it approves or declines. The request and the decision are both recorded. **Can an agent's request touching personal data, or a letter in a partner's name, get a second look?** Yes. The starter ethics rules include “Health and personal data”, which asks whether there is a lawful basis and whether only what is needed is being used, and “Messages sent in someone else's name”, which asks whether the recipient would be misled about who wrote it or what it commits to. They arrive switched off; once on, whoever decides sees the concern first and has to give a reason to approve. ### Research firms — https://deliverd.dev/for/research AI drafts the note. An analyst signs it off. Get every AI-drafted note signed off by the analyst or research director whose name goes on it, before it reaches a subscriber and without chasing them for it. The agent stops to ask them — on their phone or from an email — and goes on when they answer. Subscribers then open the approved note at one address, entitled per client, with the figures refreshed in place. The situation: - The agent drafted it; the analyst has to stand behind it: A note goes out under an analyst's name with a model's first draft inside it. Without a step where the agent stops and asks, the only review is whoever happens to read it before it is sent. - The list is the only access control: Entitlement lives in whoever maintains the distribution list. A client who churned last quarter is one stale row away from still receiving the work they stopped paying for. - The numbers age faster than the analysis: The argument holds for a quarter; the figures underneath it are stale in a week. Reissuing the whole note to update a table means it goes back through review for no good reason. What Deliverd does for research firms: - Your AI asks before it acts: An agent that needs a decision puts it to a named person and waits: what it wants to do, why, how risky it is, and what to read first. They approve, approve with changes, reject with a reason, or ask the agent a question — on the page, from an email link, in Slack or Teams, or from a push notification on a phone — and a colleague can cover their approvals while they are away. It can also ask for a review, or for information it is missing, the same way. - Sign-off before it leaves: A publishing rule can hold work for a partner's approval: the version is stored and scanned, the client sees nothing until someone with the authority says so, and the decision is on the record. Off by default; switch it on for agent publishes, for anything addressed outside the firm, or both. - An address, not an attachment: The work lands on a URL you can send. It stays put, so the link you shared at the kick-off still opens today's version rather than a copy of what it looked like in March. - Numbers that refresh without reissuing: A published report can hold its own dataset, updated over the API on whatever cadence you choose. The narrative stays fixed and reviewed while the figures underneath it stay current. - The work keeps its objective: A task holds what the work is for apart from the conversation doing it, with a short state — where it stands, the next action, what is in the way — that any agent reads when it resumes. Side tasks take a bug or a piece of research out of the main thread and come back with a result. Switch tool or model and the next one picks up where things stand instead of starting over, and only a person changes the objective. (Included in Team, Business Starter, Business and Enterprise.) - A record of who opened it: Views, versions, access changes and share links are written to an audit trail you can export — which is the difference between believing a client saw something and being able to show it. - Opened with the client's own sign-in: Readers authenticate with the identity their organisation already uses, including SAML and OpenID Connect single sign-on. Nobody gets a password to remember, and nobody gets a file to leave with. - Every version kept, one URL: Reissuing updates the address and keeps what was there before. You can see what changed between two drafts and roll back if the new one is wrong. - External readers, verified by one-time code: A reader outside any directory gets a link that emails them a code before it opens. Links can be restricted to named email domains, so a forwarded one does not become an open one. - Inside the client's own intranet: Allow a SharePoint site by origin and a report can be framed on a page there. It is still served and access-checked here, so the page shows the report to the people who may open it and a sign-in link to everyone else. **Can the agent ask an analyst or the research director to sign off before a note goes out?** Yes. The agent asks the named analyst or research director with request_approval and waits for the answer — approve, correct a figure, reject with a reason — from a phone or an email link. A publishing rule can also hold every publish for approval, so nothing reaches subscribers until someone with the authority says so. **How do the numbers update without republishing?** A report can carry its own datasets, written over the API on whatever schedule you like, and read by the report when a reader opens it. The reviewed narrative does not change; the figures it draws are current. **Does that mean an old version shows old numbers?** No, and this is worth knowing before you rely on it: a version is immutable but its data is not, so rolling back to an earlier version renders that version's wording against today's figures. **Can we see which clients are actually reading?** Yes. Views are recorded per report and surfaced in analytics on the plans that include it, and the underlying trail is exportable. **Can an agent write the note and publish it?** Yes — over MCP, the REST API or the CLI. An agent identity can be scoped to a single workspace and can never grant public access, so an automated pipeline cannot widen distribution. ### Insurers and brokers — https://deliverd.dev/for/insurance AI prepares the case. A person makes the call. Have the underwriter or claims handler who owns a decision make it before an agent pays a claim or quotes a risk, and have the answer ready when a regulator asks who decided. An agent working a claim or a renewal stops to ask that person — on their phone, from an email or in Teams — and every answer is recorded with what they were shown. Each counterparty sees only their own position. The situation: - A decision a regulator will ask about: Accepting a risk, paying a claim or declining one is examined afterwards. When a model did the groundwork, the first question is which person decided and what they were looking at — and a chat transcript does not answer it. - One mistake in a recipient list is a disclosure: The same report goes to several counterparties with different entitlements, most of them in nobody's directory. The control between the wrong one and the wrong version is a person checking an address bar. - “What did they see, and when?”: When a placement or a claim is questioned, the answer needs to be evidence rather than recollection. A sent-items folder proves what left, not what was opened, and a system log shows what ran, not who allowed it. What Deliverd does for insurers and brokers: - Your AI asks before it acts: An agent that needs a decision puts it to a named person and waits: what it wants to do, why, how risky it is, and what to read first. They approve, approve with changes, reject with a reason, or ask the agent a question — on the page, from an email link, in Slack or Teams, or from a push notification on a phone — and a colleague can cover their approvals while they are away. It can also ask for a review, or for information it is missing, the same way. - A check before the agent acts: Before a consequential action — a payment, a deployment, a message to a customer — the agent declares what it is about to do and waits for the answer. A named person decides, or your organisation's rules settle the routine cases and send the rest to a person; with no rules, every one goes to a person. Afterwards the agent records what ran, and the record is checked against what was allowed. (On every plan; policy rules included in Business Starter, Business and Enterprise.) - Governance recorded as the work happens: Compliance Mode adds a register of the AI systems you use and, on governed work, the owners and the risk and data classification. That profile decides the controls: evidence or a person's approval meets each one, and an exception, with an owner and an expiry, shows as waived rather than met. The whole record exports as one evidence pack. It records how the work was governed — it does not certify compliance with any law or standard. (Included in Business and Enterprise.) - One pack for the auditor: Every step of a piece of work — who was asked, what they said, what was decided and when — exported as a single timeline in JSON, CSV or PDF. It carries a digest and the head of the hash-chained audit trail, signed with a published key, so anyone can check a copy offline, and the export itself is on the record. - Each agent under its own name: Register each agent on Agents → Agents and it acts under its own name, which is what the audit trail shows for every request it makes. You decide what it may ask people for and where it may publish, and its keys can be rotated or revoked without touching anyone else's. (Included in Team, Business Starter, Business and Enterprise.) - A second thought, where it matters: Your organisation writes rules for requests that touch someone's job, money, health or privacy, or that cannot be undone. When one matches, whoever decides sees the concern first and has to say why it is right to go ahead; a rule can also ask more people to agree, or refuse. Ethics rules only add oversight — none of them can approve anything — and they are on every plan. - External readers, verified by one-time code: A reader outside any directory gets a link that emails them a code before it opens. Links can be restricted to named email domains, so a forwarded one does not become an open one. - A record of who opened it: Views, versions, access changes and share links are written to an audit trail you can export — which is the difference between believing a client saw something and being able to show it. - A workspace per client: Segment who can reach what, so an analyst on one engagement cannot browse another. Access is decided per report and evaluated on every request, assets included. - Every version kept, one URL: Reissuing updates the address and keeps what was there before. You can see what changed between two drafts and roll back if the new one is wrong. - The work keeps its objective: A task holds what the work is for apart from the conversation doing it, with a short state — where it stands, the next action, what is in the way — that any agent reads when it resumes. Side tasks take a bug or a piece of research out of the main thread and come back with a result. Switch tool or model and the next one picks up where things stand instead of starting over, and only a person changes the objective. (Included in Team, Business Starter, Business and Enterprise.) - Rules your firm sets once: Publishing policies run on every publish and share: no external sharing for a classification, a ceiling on how long a link may live, a workspace that must be named. A tester shows what a publish would do before anyone tries it. - When deletion has to stop, it stops: A matter opens and routine destruction becomes the wrong thing to do. Place a hold — on the whole organisation, one project, one task, one person’s material or one report, over a date range if you need one — and the retention schedule suspends, the organisation cannot be closed, and what the hold covers cannot be deleted: a report’s data, a task, a retracted comment’s attachments. Refused in the database, not by a setting somebody has to remember. Released with a reason, and both ends are on the record. (Included in Enterprise.) **Can a person decide before an agent acts on a claim or a risk?** Yes. The agent declares what it is about to do — pay this claim, quote this risk — and waits for the answer. With no rules, a named person decides every one. Policy rules, included in Business Starter, Business and Enterprise, settle the routine cases and send the rest to one person, or to two as the amount rises; only an owner or an administrator writes them. A gate is advisory: the agent asks and then performs the action itself, and its execution record shows whether what ran matches what was allowed. **What do we show a regulator who asks who decided?** An evidence pack: every step of the work — who was asked, what they said, what was decided and when — as one timeline in JSON, CSV or PDF, with a digest so an altered copy can be told apart. With Compliance Mode, included in Business and Enterprise, it also names the AI system that did the work, its owners, its risk and data classification and the controls it was held to. It is the record of how the work was governed; it does not certify compliance with any regulation. **How does a counterparty open something without an account?** A share link can require email verification: the reader enters their address, receives a one-time code, and the link opens only after it is verified. The link can be restricted to that firm's email domains. **Can two counterparties get different versions of the same report?** Publish them as separate reports and grant each to its own audience. That is the honest answer — one report is one document, and access decides who may open it, not what it says. **Is there a record of who opened which one?** Yes, per report: views, the version that was current, access grants and the share links themselves, all exportable. **Can a link be withdrawn after the fact?** Access can be revoked and the report archived, at which point the URL stops serving. What a reader downloaded before then is out of anyone's reach — which is why downloads are a setting you control. **Can a request about someone's credit or insurance get a second look?** Yes. The starter ethics rule “Credit, housing and insurance” flags requests about loans, mortgages, insurance claims and underwriting, and asks whoever decides to check that nothing like age or postcode is standing in for a protected characteristic. It arrives switched off; once on, a flagged approval needs a reason before it goes ahead, and the concern goes into the evidence pack. ### Financial services — https://deliverd.dev/for/financial-services Risk wants an inventory. Hand them the record. Apply your four-eyes rule to what AI agents do, and give risk and compliance the inventory and the evidence without anyone assembling them. Register each agent under its own name; before one acts, it stops to ask, your rules decide who approves — one named person, or two as the amount rises — and every answer is recorded. Deliverd sits around the assistants and agents you have already approved rather than replacing them. The situation: - Every new AI tool starts a new review: An assistant for one desk, an agent for another, a model inside a vendor's product. Each is reviewed on its own from a blank questionnaire, and by the fifth nobody can say in one place what is in use, for what, and with whose data. - Oversight that lives in a policy document: The policy says a person reviews what the AI does. What the firm can show is a meeting note and a screenshot — not who decided, on what, and when. - Evidence assembled after the fact: When an auditor or a regulator asks, somebody spends a week rebuilding the story from mailboxes and tickets. The record should exist because the work happened, not because somebody asked for it. What Deliverd does for financial services: - Your AI asks before it acts: An agent that needs a decision puts it to a named person and waits: what it wants to do, why, how risky it is, and what to read first. They approve, approve with changes, reject with a reason, or ask the agent a question — on the page, from an email link, in Slack or Teams, or from a push notification on a phone — and a colleague can cover their approvals while they are away. It can also ask for a review, or for information it is missing, the same way. - A check before the agent acts: Before a consequential action — a payment, a deployment, a message to a customer — the agent declares what it is about to do and waits for the answer. A named person decides, or your organisation's rules settle the routine cases and send the rest to a person; with no rules, every one goes to a person. Afterwards the agent records what ran, and the record is checked against what was allowed. (On every plan; policy rules included in Business Starter, Business and Enterprise.) - Governance recorded as the work happens: Compliance Mode adds a register of the AI systems you use and, on governed work, the owners and the risk and data classification. That profile decides the controls: evidence or a person's approval meets each one, and an exception, with an owner and an expiry, shows as waived rather than met. The whole record exports as one evidence pack. It records how the work was governed — it does not certify compliance with any law or standard. (Included in Business and Enterprise.) - One pack for the auditor: Every step of a piece of work — who was asked, what they said, what was decided and when — exported as a single timeline in JSON, CSV or PDF. It carries a digest and the head of the hash-chained audit trail, signed with a published key, so anyone can check a copy offline, and the export itself is on the record. - Each agent under its own name: Register each agent on Agents → Agents and it acts under its own name, which is what the audit trail shows for every request it makes. You decide what it may ask people for and where it may publish, and its keys can be rotated or revoked without touching anyone else's. (Included in Team, Business Starter, Business and Enterprise.) - The work keeps its objective: A task holds what the work is for apart from the conversation doing it, with a short state — where it stands, the next action, what is in the way — that any agent reads when it resumes. Side tasks take a bug or a piece of research out of the main thread and come back with a result. Switch tool or model and the next one picks up where things stand instead of starting over, and only a person changes the objective. (Included in Team, Business Starter, Business and Enterprise.) - A second thought, where it matters: Your organisation writes rules for requests that touch someone's job, money, health or privacy, or that cannot be undone. When one matches, whoever decides sees the concern first and has to say why it is right to go ahead; a rule can also ask more people to agree, or refuse. Ethics rules only add oversight — none of them can approve anything — and they are on every plan. - Your AI cannot publish to the world: An agent identity can never grant public access — that is refused at the service, not hidden in the UI — and can be confined to named workspaces and audiences. Every refusal is written to the audit trail. - Rules your firm sets once: Publishing policies run on every publish and share: no external sharing for a classification, a ceiling on how long a link may live, a workspace that must be named. A tester shows what a publish would do before anyone tries it. - A record of who opened it: Views, versions, access changes and share links are written to an audit trail you can export — which is the difference between believing a client saw something and being able to show it. - A workspace per client: Segment who can reach what, so an analyst on one engagement cannot browse another. Access is decided per report and evaluated on every request, assets included. - When deletion has to stop, it stops: A matter opens and routine destruction becomes the wrong thing to do. Place a hold — on the whole organisation, one project, one task, one person’s material or one report, over a date range if you need one — and the retention schedule suspends, the organisation cannot be closed, and what the hold covers cannot be deleted: a report’s data, a task, a retracted comment’s attachments. Refused in the database, not by a setting somebody has to remember. Released with a reason, and both ends are on the record. (Included in Enterprise.) **Does this replace the AI tools we have already approved?** No. Deliverd sits around them. Assistants and agents reach it over the MCP server, the REST API, the CLI or the TypeScript and Python SDKs, and the TypeScript SDK has adapters for the Claude Agent SDK, the AI SDK, the OpenAI Agents SDK and LangGraph. The tools your teams use keep doing the work; what changes is that they ask a person, and that the asking is on the record. **Can we give risk and compliance an inventory of the AI in use?** Yes, with Compliance Mode, included in Business and Enterprise. The AI system register lists the assistants, agents and models your organisation uses — provider, model, purpose, owners, environment, risk, data and oversight — and each governed piece of work names the system doing it and is never rated lower than that system. It lists what you register; it does not go looking for tools on its own. **Who decides when an agent wants to act?** A named person, unless your organisation has written a rule that settles it. The agent declares what it is about to do and waits. Policy rules, included in Business Starter, Business and Enterprise, permit the routine cases, refuse others and send the rest to one person, or to two — a four-eyes rule — as the amount rises; the requester is never one of the two, only an owner or an administrator writes the rules, and an agent cannot. A gate is advisory: the agent asks and then acts itself, and the execution record shows whether what ran matches what was allowed. **Can each agent be registered under its own name?** Yes, on Agents → Agents, included in Team, Business Starter, Business and Enterprise. A registered agent acts under its own name, which is what the audit trail shows for every request it makes; you decide what it may ask people for and where it may publish, and its keys can be rotated or revoked. An agent a person connects from their own AI tool acts as that person instead. **Does Compliance Mode make us compliant?** No tool can, and we will not say otherwise. Deliverd records how AI work was governed — the system, the owners, the controls, the evidence and who decided — so your firm can manage and demonstrate compliance. Framework packs map controls to NIST AI Risk Management Framework, ISO/IEC 42001 AI management system, EU AI Act, UK AI regulatory principles, DORA (Digital Operational Resilience Act), SR 26-2 model risk management, PRA SS1/23 model risk management and FCA AI good practice (October 2026) as a starting point for your own review, not legal advice; they are included in Enterprise. **Where is our data, and which certifications do you hold?** Your data is stored in London. We do not hold SOC 2 or ISO 27001 certification, and our security page says so rather than implying otherwise. A data processing agreement under Article 28 of the GDPR is available on request. **Can a request touching someone's credit get a second look?** Yes. The starter ethics rule “Credit, housing and insurance” flags requests about loans, credit limits, mortgages and underwriting, and asks whoever decides to check that nothing like age or postcode is standing in for a protected characteristic. “Messages sent in someone else's name” asks whether a customer would be misled about who wrote a message or what it commits to. They arrive switched off; once on, a flagged approval needs a reason before it goes ahead. ### AI engineering teams — https://deliverd.dev/for/ai-engineering Your agents act now. Who said they could? Have the engineering lead or the on-call engineer approve before an agent touches production, keep long agent work on its objective when the session, the tool or the model changes, and know afterwards who allowed what. Every framework pauses for a person in its own way; Deliverd gives every agent one way to ask, puts the question in front of the person who owns it wherever they are, and keeps the answer. The situation: - Every framework pauses differently: The Claude Agent SDK calls a permission callback, LangGraph raises an interrupt, the OpenAI Agents SDK returns interruptions. Each stops the run; none of them knows who should answer, reaches them where they are, or keeps what they said. - Long sessions lose the goal: Forty turns into a debugging detour, nobody — the model included — can say what the work was for. Switch tools or models and the next one starts from a blank prompt and a pasted summary. - The trace says what ran, not who allowed it: Tracing records every tool call. When one of them turns out to matter, the question is who allowed it and what they were shown, and a trace was never built to answer that. What Deliverd does for AI engineering teams: - Your AI asks before it acts: An agent that needs a decision puts it to a named person and waits: what it wants to do, why, how risky it is, and what to read first. They approve, approve with changes, reject with a reason, or ask the agent a question — on the page, from an email link, in Slack or Teams, or from a push notification on a phone — and a colleague can cover their approvals while they are away. It can also ask for a review, or for information it is missing, the same way. - A check before the agent acts: Before a consequential action — a payment, a deployment, a message to a customer — the agent declares what it is about to do and waits for the answer. A named person decides, or your organisation's rules settle the routine cases and send the rest to a person; with no rules, every one goes to a person. Afterwards the agent records what ran, and the record is checked against what was allowed. (On every plan; policy rules included in Business Starter, Business and Enterprise.) - The work keeps its objective: A task holds what the work is for apart from the conversation doing it, with a short state — where it stands, the next action, what is in the way — that any agent reads when it resumes. Side tasks take a bug or a piece of research out of the main thread and come back with a result. Switch tool or model and the next one picks up where things stand instead of starting over, and only a person changes the objective. (Included in Team, Business Starter, Business and Enterprise.) - One pack for the auditor: Every step of a piece of work — who was asked, what they said, what was decided and when — exported as a single timeline in JSON, CSV or PDF. It carries a digest and the head of the hash-chained audit trail, signed with a published key, so anyone can check a copy offline, and the export itself is on the record. - Each agent under its own name: Register each agent on Agents → Agents and it acts under its own name, which is what the audit trail shows for every request it makes. You decide what it may ask people for and where it may publish, and its keys can be rotated or revoked without touching anyone else's. (Included in Team, Business Starter, Business and Enterprise.) - Your AI cannot publish to the world: An agent identity can never grant public access — that is refused at the service, not hidden in the UI — and can be confined to named workspaces and audiences. Every refusal is written to the audit trail. - A second thought, where it matters: Your organisation writes rules for requests that touch someone's job, money, health or privacy, or that cannot be undone. When one matches, whoever decides sees the concern first and has to say why it is right to go ahead; a rule can also ask more people to agree, or refuse. Ethics rules only add oversight — none of them can approve anything — and they are on every plan. - Governance recorded as the work happens: Compliance Mode adds a register of the AI systems you use and, on governed work, the owners and the risk and data classification. That profile decides the controls: evidence or a person's approval meets each one, and an exception, with an owner and an expiry, shows as waived rather than met. The whole record exports as one evidence pack. It records how the work was governed — it does not certify compliance with any law or standard. (Included in Business and Enterprise.) - Review lands on the passage: A reader selects a sentence and comments on it. The thread stays anchored to that passage across new versions, so a review from two drafts ago still points at the right paragraph. - Every version kept, one URL: Reissuing updates the address and keeps what was there before. You can see what changed between two drafts and roll back if the new one is wrong. **Which frameworks does it work with?** Anything that can make an HTTP request. Agents reach Deliverd over the MCP server, the REST API, the CLI, or the TypeScript and Python SDKs. The TypeScript SDK has adapters for the Claude Agent SDK, the AI SDK, the OpenAI Agents SDK and LangGraph, each written against that framework's own approval hook, so a tool call that needs a person goes to one without rewriting the agent. **Will a gate catch an agent that never asks?** No, and it is better to say so. A gate is advisory: the agent reports what it intends to do, a person or a rule answers, and the agent performs the action itself. What you get is that the question is asked, answered by somebody other than the agent and written down — and the execution record shows whether what ran matches what was allowed: the content's sha256 and where it went. **What happens when we switch models or tools halfway through?** The task carries on. An objective holds the outcome the work is for, and a short task state holds where it stands, the next action, open questions and what is in the way — which is what the next agent reads, whichever model or tool it is, instead of the whole history. Side tasks take a bug or a piece of research out of the main thread and come back with a result rather than a transcript. Objectives are included in Team, Business Starter, Business and Enterprise. **Can an agent approve its own request, or write its own rules?** No. The requester is removed from the approvers and an agent may not be an approver of anything. Writing a policy rule is how authority is granted, so an agent is refused at the service rather than hidden in the interface. And only a person changes a task's objective, so no model can redefine success and then meet it. **Can a destructive command get a second look first?** Yes. The starter ethics rule “Things that cannot be undone” flags requests that mention deleting everything, wiping, purging or dropping a table, and asks whoever decides whether there is a way back if it turns out to be wrong. It arrives switched off; once on, a flagged approval needs a reason before it goes ahead, and the concern goes into the evidence pack. ## The AI tools it connects to Deliverd exposes a Model Context Protocol server at https://deliverd.dev/api/mcp (Streamable HTTP, OAuth 2.1 with PKCE and dynamic client registration — no token is pasted). Any of the 100 tools below can be called by an agent once a person has approved the connection. Everything the MCP server does is also available over the REST API (https://deliverd.dev/api/v1, OpenAPI at https://deliverd.dev/api/v1/openapi.json) and the command-line tool (`npx deliverd`). ### Claude Code — https://deliverd.dev/claude-code Claude Code does the work. A person signs it off. Get a decision from the person who owns it — the finance lead, the client, the engineer on call — before Claude Code does something that matters, and keep a record of who allowed it. The permission prompt in your terminal asks whoever is at the keyboard and keeps nothing; connect Deliverd once and Claude Code asks the person who should decide, wherever they are, and carries on when they answer. Connect (MCP): 1. Add the server — Claude Code opens a browser the first time it is used, so you can pick the organisation and approve access. claude mcp add --transport http deliverd https://deliverd.dev/api/mcp **Do I need an API token?** No. The server implements the MCP authorization spec, so Claude Code registers itself and opens a browser for you to approve the connection. Nothing writes a credential to disk. **Does this work with Claude Desktop and the web app too?** Yes — add the same address under Settings → Connectors. It is the same server and the same tools. **What can Claude actually do once it is connected?** Ask a named person for approval, a review or information it is missing, check a gate before a consequential action, and keep a task's objective and state across sessions — all over the same connection. It can also publish a report, update it in place, read reader comments and resolve them. **Who decides, and can Claude approve its own request?** A named person, or your organisation's rules for the routine cases. The requester is removed from the approvers and an agent may not be an approver of anything — refused at the service, not hidden in the interface. **Can it publish something publicly by accident?** An agent identity can never grant public access — that is refused at the service, not just hidden in the UI. Everything else runs through your organisation's publishing policy. ### Codex — https://deliverd.dev/codex Codex does the work. A person signs it off. Get the lead's or the on-call engineer's approval on the steps of a long Codex run that need it, without them watching your terminal, and keep a record of who allowed each one. Today the approval Codex asks for is answered by whoever started it; connect Deliverd once and the question goes to the person who owns the decision, and the answer comes back to Codex. Connect (MCP): 1. Add the server codex mcp add deliverd --url https://deliverd.dev/api/mcp 2. Approve it in your browser — Codex needs this second step — it does not begin the approval flow on its own. codex mcp login deliverd 3. On an older Codex — Streamable HTTP servers are only picked up when the rmcp client is on. If the server does not appear, upgrade Codex, or add [features] experimental_use_rmcp_client = true to ~/.codex/config.toml above the server entry. **Which Codex versions work?** Any version with the rmcp client, which is what speaks Streamable HTTP. On an older build the server will not appear at all — upgrade Codex, or set experimental_use_rmcp_client = true under [features] in ~/.codex/config.toml. **Why the second command?** Codex does not start the approval flow on its own the way the Claude clients do. `codex mcp login deliverd` opens the browser; without it you get an authorization error that never resolves itself. **What can Codex do once it is connected?** Ask a named person for approval, a review or information it is missing, check a gate before a consequential action, and keep a task's objective and state across sessions — all over the same connection. It can also publish a report, update it in place, read reader comments and resolve them. **Can I use it from CI instead?** Yes. The CLI reads DELIVERD_URL and DELIVERD_TOKEN from the environment, so a pipeline can ask a person with deliverd ask --wait and fail the build unless it is approved, or publish with an agent identity scoped to one workspace. **Does JavaScript run in a published prototype?** Yes, from the report itself. Scripts and styles you inline run normally; the report cannot call out to other origins, which is what makes it safe to host untrusted generated code. ### Cursor — https://deliverd.dev/cursor Cursor does the work. A person signs it off. Get the right person's approval before Cursor's agent changes production data, messages a customer or ships a change, with the decision kept on the record rather than in a chat that closes by lunchtime. Its approval dialogue asks whoever is in the editor; add one entry to your MCP config and it asks the person who should decide instead, wherever they are. Connect (MCP): 1. Or add it to ~/.cursor/mcp.json — Keep any servers already listed there — replacing the file removes them. { "mcpServers": { "deliverd": { "type": "http", "url": "https://deliverd.dev/api/mcp" } } } 2. Reload Cursor — Then approve the connection in your browser. **Where does the config go?** ~/.cursor/mcp.json for every project, or .cursor/mcp.json inside one. Merge the entry into what is already there — replacing the file removes the other servers you had configured. **Do I have to paste a token into the file?** No, and you should not. The entry holds only a URL; Cursor registers itself and you approve the connection in a browser. A pasted token is a long-lived credential sitting in a plaintext file in your home directory. **What can Cursor do once it is connected?** Ask a named person for approval, a review or information it is missing, check a gate before a consequential action, and keep a task's objective and state across sessions — all over the same connection. It can also publish a report, update it in place, read reader comments and resolve them. **Can I publish a multi-file bundle?** Yes — a folder or a zip with an index.html, up to 500 files. Use relative asset paths and they resolve correctly once published; scripts from the major CDNs are fetched and bundled in, so the page keeps working even if the CDN does not. ### ChatGPT — https://deliverd.dev/chatgpt ChatGPT does the work. A person signs it off. Get a sign-off from the person who owns the decision before what ChatGPT drafted is sent, posted or acted on — without copying it anywhere — and keep a record of who said yes. Connect Deliverd once and ChatGPT can put the decision in front of the right person, and go on when they answer. Connect (MCP): 1. Turn on developer mode — Settings → Apps → Advanced settings → Developer mode. Custom connectors need a paid ChatGPT plan. 2. Add a custom connector with this address — The connector registers itself and sends you to a screen where you choose the organisation and approve access. https://deliverd.dev/api/mcp **What do I need to add a custom connector?** Developer mode, under Settings → Apps → Advanced settings. Custom MCP connectors are on the paid ChatGPT plans; this is OpenAI's restriction rather than ours. **Is a token involved?** No. The connector registers itself, sends you to a consent screen where you choose which organisation it may ask and publish in, and receives its own credentials. Consenting to one organisation is not consenting to all of them. **What can ChatGPT do once it is connected?** Ask a named person for approval, a review or information it is missing, check a gate before a consequential action, and keep a task's objective and state across sessions — all over the same connection. It can also publish a report, update it in place, read reader comments and resolve them. **What if I would rather use the API?** Any script or agent that can make an HTTP call can ask a person, check a gate or publish — Python, a Lambda, a GitHub Action. The REST API takes the same requests and the same audiences. **Will readers see your branding?** On the paid plans they see yours: your organisation's name and logo, on your own domain if you have added one, with email sent from your domain once it is verified. ### VS Code — https://deliverd.dev/vscode Agent mode does the work. A person signs it off. Get the right person's approval before Copilot's agent mode makes a change that is not yours to allow, with the answer kept after the session ends. The confirmation it asks for today is yours, in the editor; add one MCP server and it asks the person who owns the decision, wherever they are. Connect (MCP): 1. Or add it to .vscode/mcp.json — In the project for one repository, or in your user settings for all of them. The key is “servers” — VS Code ignores an “mcpServers” block. { "servers": { "deliverd": { "type": "http", "url": "https://deliverd.dev/api/mcp" } } } 2. Start it — Run “MCP: List Servers” from the command palette, start the server, and approve the connection in your browser. **What does the Add to VS Code button do?** It opens VS Code and asks you to add the server entry, exactly as if you had written it into .vscode/mcp.json yourself. Nothing is written until you confirm, and the entry holds only a URL. **Where does the config go if I add it by hand?** .vscode/mcp.json inside a project, or your user settings for every project. The key is “servers” — VS Code's file is not the same shape as Cursor's, and an “mcpServers” block is ignored. **Do I need a token?** No. VS Code registers itself with the server and opens a browser for you to approve the connection. Removing you from the organisation cuts the connection off at once. **What can Copilot do once it is connected?** Ask a named person for approval, a review or information it is missing, check a gate before a consequential action, and keep a task's objective and state across sessions — all over the same connection. It can also publish a report, update it in place, read reader comments and resolve them. **Does this work with the Insiders build?** Yes — the second button opens Insiders instead. Both builds read the same mcp.json format. ### Windsurf — https://deliverd.dev/windsurf Cascade does the work. A person signs it off. Get the right person's approval before Cascade makes a change that matters, and keep a record of who allowed it. The step it pauses on is confirmed today by whoever is in the editor; one entry in its MCP config and it asks the person who should decide instead, and carries on when they answer. Connect (MCP): 1. Add it to ~/.codeium/windsurf/mcp_config.json — Keep any servers already listed there. The key is “serverUrl” — a plain “url” is ignored. { "mcpServers": { "deliverd": { "serverUrl": "https://deliverd.dev/api/mcp" } } } 2. Refresh the servers — In Cascade's MCP panel, refresh, then approve the connection in your browser. **Where does the config go?** ~/.codeium/windsurf/mcp_config.json. Merge the entry into what is already there — replacing the file removes the other servers you had configured. **Why serverUrl rather than url?** Because that is the key Windsurf reads for a remote server. A plain “url” is silently ignored and the server never appears, which looks like an outage and is a typo. **Do I need a token?** No. Windsurf supports OAuth for remote servers: it registers itself and opens a browser for you to approve the connection. The config holds only an address. **What can Cascade do once it is connected?** Ask a named person for approval, a review or information it is missing, check a gate before a consequential action, and keep a task's objective and state across sessions — all over the same connection. It can also publish a report, update it in place, read reader comments and resolve them. ### Gemini CLI — https://deliverd.dev/gemini-cli Gemini does the work. A person signs it off. Get the right person's approval before Gemini acts — on their phone, in Teams or by email — with the answer back in the session and kept on the record. Today it asks for confirmation in the terminal that started it; add the MCP server and the question goes to the person who owns the decision. Connect (MCP): 1. Add the server gemini mcp add --transport http deliverd https://deliverd.dev/api/mcp 2. Approve it — Inside Gemini, if it has not already opened a browser for you. /mcp auth deliverd **Do I need a token?** No. Gemini CLI supports OAuth for remote MCP servers: the first connection is refused, Gemini discovers the sign-in, opens a browser, and you approve it. Nothing is pasted into a config file. **What if the browser does not open?** Run /mcp auth deliverd inside Gemini. The approval needs a machine that can open a browser and receive a redirect on localhost, so a headless server or a remote SSH session is the one place this does not work — use the CLI with a token there instead. **Where is the server stored?** In Gemini's settings.json — your user settings by default, or the project's .gemini/settings.json with --scope project. The entry holds only the address. **What can Gemini do once it is connected?** Ask a named person for approval, a review or information it is missing, check a gate before a consequential action, and keep a task's objective and state across sessions — all over the same connection. It can also publish a report, update it in place, read reader comments and resolve them. ### MCP tools - request_approval: Ask named people to authorise an action before you take it; returns the request and its page. - get_approval: The status of an approval — pending, approved, rejected or expired — with any questions the approver asked. - answer_approval_question: Answer a question an approver asked about your request, on the approval page. - cancel_approval: Withdraw an approval you asked for, while it is still undecided. - request_review: Ask named people to read work and say whether it is right; returns the request and its page. - get_review: The outcome of a review — pending, approved or changes requested — with each reviewer's verdict and note. - cancel_review: Withdraw a review you asked for, while it is still unanswered. - request_information: Ask named people typed questions and get structured answers back; returns the request and its page. - get_collection: The answers to a request for information, with who replied and what they said. - cancel_collection: Withdraw a request for information you made, while it is still open. - check_gate: Ask whether you may perform a registered action before you perform it; policy answers allow, refuse, or a person decides. - get_gate: The state of a gate decision you raised, once a person has answered it. - cancel_gate: Withdraw your own gate request, or a permission you have not used yet. - record_execution: Report what you did with a gate's permission; a different artifact or destination is refused. - release_version: Have Deliverd make the staged report version a gate authorised live, and record it as verified. - create_flow: Start a flow: the thread tying one job's approvals, reviews, requests and publishes together. - find_flow: Find the flow you started with an externalId, or null, so a restarted job extends it rather than starting a second. - get_flow: A flow with everything in it and the timeline of what happened across all of them, in order. - complete_flow: Say the work a flow covers is done. Only whoever started it, and it takes no new members afterwards. - cancel_flow: Close a flow as abandoned rather than done, so the history says which of the two happened. - create_task: Start an objective: what the work is ultimately for, kept apart from the conversation and returned at the top of every context. - get_task_context: The objective, where a task stands, its decisions, open questions, side-task results, reports and next action — read instead of the history. - list_tasks: The objectives you can see, with status, next action and side-task counts — find work already under way before starting more. - get_task: One task in full: objective, state, result, findings, decisions, where it sits and its side tasks. - get_task_graph: Every side task under an objective, with its status and one-line result, and the links between them. - update_task: Update a task's working state — where it stands, open questions, what blocks it, the next action — or its status. - create_side_task: Branch a problem out of the main task so the main thread stays on its goal. It starts with a chosen snapshot of the parent. - add_finding: Record a work product on a task: hypothesis, test, evidence, conclusion, recommendation or a decision you suggest. - complete_task: Finish a task with a structured result: summary, findings, proposed decisions, open questions and the next action. - apply_side_task: Carry a finished side task's result into its parent, or keep or discard it, and return to the objective. - reopen_task: Reopen a finished task when there is more to do. What it found the first time is kept. - cancel_task: Call a task off as abandoned rather than finished. Cancelling an objective cancels its open side tasks. - request_decision_approval: Put a decision you suggested to the organisation's approval process; approved confirms it, rejected rejects it. - create_governed_task: Start an objective under Compliance Mode: the AI system, purpose, owners, risk, data and oversight, held to the controls they require. - govern_task: Put an existing objective under Compliance Mode, with what is known of its governance profile. - get_governance_context: A governed task's profile, AI system, controls and their state, evidence, readiness and gate answer. - update_governance_profile: Record what was learnt about a governed task. An agent may raise risk or add facts; only a person lowers or clears them. - get_required_controls: The governance controls a governed task must satisfy, and what satisfies each. - submit_evidence: Record evidence for a governed task and the controls it speaks to, with the scores a run measured or the tool's own report. - request_control_approval: Put a compliance or deployment approval control to a person through the organisation's approval process. - check_governance_gate: Whether governed work may proceed, naming the controls still outstanding. Recorded. - get_evidence_pack: The AI governance evidence pack of a governed task, with a digest. Assists audit; certifies nothing. - register_ai_system: Add an AI system to the organisation's register so governed tasks can name it. - update_ai_system: Change an AI system's register entry. An agent cannot lower its risk or set its status. - move_ai_system: Put an AI system's register entry forward for assessment, or withdraw it. Decisions on it are a person's. - list_ai_systems: The organisation's register of AI systems. - get_ai_system: One AI system's register entry: its lifecycle status and steps, who answers for it, and the governed tasks that name it. - get_ict_register: The ICT third-party register: providers, contracts, the AI systems under each, what entries lack, and concentration per provider. - get_framework_mapping: How framework requirements map onto governance controls, and how far a governed task's completed controls cover them. Not a compliance verdict. - create_custom_framework: Draft the organisation's own governance framework. Applies only once a person publishes and adopts it. - check_agent_authority: Whether this agent may take a kind of action on its own, only with a person's approval, or not at all. - screen_data: Before sending text to an AI model, find the personal data, secrets and confidential terms in it, and whether that model may receive them. - record_model_change: Record a new provider, model or version for an AI system; every governed task using it is reassessed. - search_knowledge: Search the organisation's confirmed knowledge — facts, conventions, decisions, who to ask — before you start or when unsure. - get_knowledge: One knowledge entry in full: its words, who confirmed it, when it is due for review, and the versions it replaced. - propose_knowledge: Propose something you learned as organisation knowledge, for any agent to rely on once a person confirms it. - list_playbooks: The organisation's playbooks and approved prompts: how a kind of job is done, with which version is in force. - get_playbook: One playbook: its purpose, its inputs and each step with the rule that applies — a gate check, an approval or a review. - draft_playbook: Write down a procedure as a playbook draft. A person puts it in force; nobody runs a draft. - start_playbook: Run the playbook in force: an objective with a side task per step, each holding its instruction and its rule. - use_prompt: Take one of the organisation's approved prompts, filled in with your inputs: the version in force, with its limitations. - propose_setup: Describe the consequential things you can do here, and get rules for them drafted for an administrator to review and add. - trigger_reassessment: Ask for a governed task to be reassessed. Its gate stays closed until a person completes it. - report_ai_incident: Report an AI incident against a governed task or AI system. High or critical closes the gate until a person resolves it. - get_ai_incident: One incident with its DORA classification, its reports and which report is due next, by when. - get_risk_indicators: The AI risk scorecard for a month: each indicator against its green, amber and red limits, the trend and the actions open. - submit_risk_indicator_reading: Give a month's figure for an AI risk indicator Deliverd cannot measure itself, with where it comes from. - draft_incident_report: Draft the next DORA report on a major incident and put it to a person to sign off. - get_evidence: An evidence pack for a flow or a report: every step, who decided what, and the full timeline. - get_profile: Who this connection belongs to, to tell connected accounts apart. - resolve_audience: Turn natural-language audience phrases into concrete principals. - list_workspaces: List workspaces, with who can already open a given report. - publish_report: Publish HTML to a persistent secure URL, with an audience named in plain English. - update_report: Publish a new version of an existing report, keeping its URL and audience. - rename_report: Change a report's title or address; the old address keeps working. - move_report: File a report into a workspace. - archive_report: Stop a report's URL serving. Reversible; nothing is deleted. - unarchive_report: Put an archived report back, at the same URL and audience. - rollback_report: Serve an earlier version again, without republishing it. - get_report: Fetch a report's metadata, URL and current version. - find_reports: Search reports by title or slug. - list_templates: Reports the organisation offers as starting points. - share_report: Grant people, teams or groups access to a report. - revoke_access: Take a report's access away again, from the same audience phrase that granted it. - send_report: Email a report to a list of addresses, with a covering note. Each gets their own link. - list_due_schedules: Recurring reports waiting on this agent. - create_schedule: Ask an agent for a recurring publish, on a cron cadence. - update_schedule: Change a schedule's cadence, or turn it on or off. - delete_schedule: Stop asking for a recurring publish. - list_report_data: List the datasets a report reads when it is opened. - update_report_data: Replace a report's live data without publishing a new version. - delete_report_data: Remove a dataset from a report. - list_comments: Read reader feedback, with the quoted passage and context. - list_open_comments: Every open comment thread across the organisation's reports — what needs attention. - get_report_analytics: Who read a report and when: views, readers, by day and by version. - get_org_analytics: Readership across every report, including the ones nobody has opened. - get_revision_brief: The open feedback on a report as one revision prompt, with the readers' screenshots. - comment_on_report: Comment on a report, anchored to a quoted passage. - retract_comment: Take back a comment nobody has answered yet. - resolve_comment: Mark a comment thread resolved. ### The SDKs and callbacks Without MCP, the TypeScript SDK (`npm install @deliverd/sdk`) and the Python SDK (`pip install deliverd`) make the same requests and wait for the answer, with no polling to write. Details at https://deliverd.dev/docs/developers/sdk. Any approval, review or request for information can instead name its own `callbackUrl`: an HTTPS address that is POSTed the answer, signed exactly as a webhook is with a secret returned once when the request is made. Details at https://deliverd.dev/docs/developers/webhooks#callbacks. ### Skills: teaching an agent when to ask, and how 10 open-source skills (MIT) for Claude Code, Codex, Cursor and other agents. Approval: When to stop and ask a person before a consequential action — anything irreversible, anything that spends money or reaches people outside the conversation — how to write a request someone can decide from a phone, how to wait, and how to act on the answer, including an approver's corrections. Ethics: Noticing when work could harm or wrong a person, and putting that concern in front of whoever decides rather than around them. It also covers behaving well when an organisation's ethics rules flag or refuse a request, and helping an administrator write those rules. Ethics rules: Helping a person write their organisation's ethics rules: finding where rules belong, adapting the starter rules and a library grouped by area, keywords that don't catch everyday software talk, testing them, and switching them on one at a time. The agent drafts; a person adds them. Artifact: Building a well-made, self-contained HTML page — a report, a dashboard, a plan, a prototype — and then offering to publish it. The craft half works with no account at all. Tasks: Keeping long work aimed at its goal: stating an objective, keeping a short working state instead of relying on the history, branching a problem into a side task and bringing its result back, and leaving decisions to a person. Compliance: Doing AI work under an organisation's governance and leaving a record an auditor can check: the governance profile, controls met by evidence and scored evaluation results, the release the evidence tested, the release check before anything consequential, incidents and DORA reports, and what only a person may decide. It never calls the work compliant. Screen: Checking text for personal data, secrets and confidential terms before it goes to a model or leaves the machine, with Deliverd Screen running locally: wiring the check into code that calls a model, redacting what is handed on, and acting on the answer — send, send redacted, ask a person, or send nothing. Free, with no account. Prompts: Using the organisation's approved prompts instead of its own words when one fits the job: finding one, taking the version in force filled in with the right inputs, checking the result against its limitations, and drafting words that worked as a new prompt for a person to approve. Policy: Helping a person write the rules that decide what agents may do on their own, what goes to a person and what is refused: proposing a setup, naming the actions, policy files with test cases, replaying a change against past decisions, and the CI that checks every change. The agent drafts rules; a person puts them in force. Checkpoint: Putting the approval step on the path to a consequential action instead of relying on the agent to ask: the hosted MCP gateway, a gate in the code that acts, checking the signed decision token where the action happens, the GitHub Action and the AgentCore Gateway interceptor, and saying plainly what each one does not cover. - The approval skill (open source, MIT): npx skills add deliverd-dev/deliverd-skills --skill approval - The ethics skill (open source, MIT): npx skills add deliverd-dev/deliverd-skills --skill ethics - The ethics-rules skill (open source, MIT): npx skills add deliverd-dev/deliverd-skills --skill ethics-rules - The artifact skill (open source, MIT): npx skills add deliverd-dev/deliverd-skills --skill artifact - The tasks skill (open source, MIT): npx skills add deliverd-dev/deliverd-skills --skill tasks - The compliance skill (open source, MIT): npx skills add deliverd-dev/deliverd-skills --skill compliance - The screen skill (open source, MIT): npx skills add deliverd-dev/deliverd-skills --skill screen - The prompts skill (open source, MIT): npx skills add deliverd-dev/deliverd-skills --skill prompts - The policy skill (open source, MIT): npx skills add deliverd-dev/deliverd-skills --skill policy - The checkpoint skill (open source, MIT): npx skills add deliverd-dev/deliverd-skills --skill checkpoint - The Claude Code plugin installs the MCP server and all 10 skills: claude plugin marketplace add deliverd-dev/deliverd-skills ### Deliverd Screen: keep personal data out of a prompt, free and open source Deliverd Screen finds and redacts personal data, secrets and your own confidential terms before text goes to an AI model. MIT-licensed, for TypeScript, Python and Rust, with no account and no network call. What it finds: Email addresses, phone numbers, IBANs, payment card numbers (Luhn-checked), UK National Insurance numbers, Irish PPS numbers, US Social Security numbers, IP addresses, dates of birth, API keys and tokens, private keys, passwords in connection strings and .env files, words that mark special-category data such as health or religion, and your own terms. - TypeScript: npm install @deliverd/screen (https://www.npmjs.com/package/@deliverd/screen) - Python: pip install deliverd-screen (https://pypi.org/project/deliverd-screen/) - Rust: cargo add deliverd-screen (https://crates.io/crates/deliverd-screen) - MCP server for Claude Code, Cursor or Codex, one tool (screen_text), local: claude mcp add deliverd-screen -- npx -y @deliverd/screen mcp - CLI: npx @deliverd/screen --fail prompts/*.txt - GitHub Action (uses: deliverd-dev/deliverd-screen@v0) and pre-commit hook (id: deliverd-screen): https://github.com/deliverd-dev/deliverd-screen - Library source: https://github.com/deliverd-dev/deliverd-sdk. Docs: https://deliverd.dev/docs/developers/screen. Page: https://deliverd.dev/screen Names need a model: plug in a Hugging Face token classifier or Presidio as a detector. Deliverd Screen is a net, not a certificate; redacted text about a person is still personal data under GDPR. A library can tell you to stop. Deliverd's Data Gate makes the call. The same detectors run on your machine and send only the counts, such as two email addresses and one IBAN. The verdict comes from your organisation's policy and from what your AI register approves each model to receive. On an ask, the question goes to the right person in Slack, Teams, email or on their phone, and every check is recorded. Included on Team, Business Starter, Business and Enterprise. On Free it runs report-only: checks are recorded and nothing is held back, so you can see what it would have stopped. ## Compared with the alternatives ### building approvals yourself — https://deliverd.dev/vs/build-it-yourself An approval is a table and a button. Then it needs everything else. Most teams start by building it: a pending row, a link in an email, a webhook back to the agent. For one agent and one approver that is a sensible afternoon's work. It grows when the approver is on a phone, away for a week, or one of two people who both have to agree — and when someone asks, a year later, who said yes. Where it is strong: - Exactly your model: The request, its states and the people in it fit your system and nobody else's. Nothing to map and nothing to work around. - Nothing new in the path: No vendor to assess, no data leaving your estate and no contract. For one agent asking one person, that is a reasonable trade. - It ships with the agent: The approval code is versioned, tested and deployed with the agent that uses it, by the people who already understand both. Where it stops: - Reaching the person where they are: An email link, then a page that works on a phone, then a Slack or Teams message, then a notification. Each is a channel to build, secure and keep working, and each has to lead to the same decision. - Deciding who may decide: The requester cannot approve their own request, an agent cannot approve anything, some requests need two people, and a group means whoever in it answers first. Each rule is code, and each has an edge case. - Waiting without forgetting: Requests expire, reminders go out, an unanswered request moves to someone else, and a colleague covers while the approver is away. That is a scheduler and a set of rules before the agent hears anything back. - Getting the answer back to the agent: The process that asked may have gone. Telling it means a signed callback with retries, or state that can be resumed, and making sure a stray message cannot approve anything. - The record someone asks for later: Who was asked, what they saw, what they decided and when, kept where it cannot be quietly edited, and exportable when a client or an auditor asks. What Deliverd adds: - Every channel, one decision: The request goes out by email, browser push, Slack and Teams, and opens on a page built for a phone. A press in chat goes through the same decision as the page. - Rules about who decides: An agent never decides, and a requester never approves their own request. Standing rules, on Business Starter, Business and Enterprise, send a request to two people or a named set, or refuse it. - Expiry, escalation and cover: A request nobody answers escalates to more people and then expires, and a colleague can cover someone's approvals while they are away. - Approve with changes, or ask: The approver can correct the fields the agent opened for correction, or ask the agent a question and see the answer arrive on the page. - Told, not polled: Name a callback URL and the decision is posted there, signed and retried. In development mode the SDK runs the whole loop on your machine, with no key. - The record, kept: Every request, question and decision is written to an audit trail that refuses edits, and a job's steps export as one timeline in JSON, CSV or PDF. **Can we start with our own and move later?** Yes. Each request can carry your own reference and be found by it, so moving one kind of request at a time works. **Do approvers need a seat?** No. Being asked — an approval, a review, a question — never needs a seat, on any plan. **Can we try it without connecting anything?** Yes. The SDK's development mode runs the whole loop on your machine, with no key and no network, so the agent's code is written before anyone signs up. **Is this a workflow engine?** No. Deliverd does not run your agent or draw your process. The agent asks, a person answers, and the agent carries on with the answer. ### Slack and Teams buttons — https://deliverd.dev/vs/slack-teams-buttons A button in Slack is quick to add. Who pressed it is the work. Slack's Block Kit and Teams' Adaptive Cards both put an approve button where people already talk, and for a team's own agent that can be all it needs. What happens after the press is your application's: checking the request came from the platform, deciding whether that account belongs to someone allowed to approve, and keeping a record of it. Where it is strong: - Where people already are: A Block Kit button in Slack, or an Adaptive Card in Teams, puts the request in the conversation, and answering is one press without leaving it. - Cards that keep up: In Teams, Universal Actions can update a card after the decision, showing who approved it and when, and show different people different buttons on the same card. - Approvals inside Teams: The Approvals app in Teams lists the approvals a person has sent and received, including those started from Power Automate, SharePoint and Dynamics 365. Where it stops: - The press comes to your server: Slack posts each press to your app's request URL and expects an acknowledgement within three seconds. Verifying the signature, acting on the press and updating the message are your app's work. - An account is not an approver: The payload says which Slack user pressed. Whether that account belongs to someone in your organisation who may decide this request — and who is not the person who asked — is a question your code answers. - Each platform is its own build: A Slack app reaches Slack. A Teams bot reaches Teams, and Outlook through Universal Actions. Approvers who use neither need another route to the same decision. - The history is the conversation: What your own buttons did lives in the channel and your app's logs, unless you also write it somewhere that can be exported and cannot be edited. What Deliverd adds: - One request, every channel: Deliverd posts the request as a Slack message and a Teams card, emails it and pushes it to a phone, and every copy is redrawn without buttons once anyone decides. - The person behind the account: The first press links the chat account to an active member of your organisation, from what Slack or Microsoft hold about that account rather than anything in the message. - Single sign-on respected: Where your organisation requires single sign-on, a Teams press counts only when Microsoft names the Entra identity your sign-on recorded. Anyone else decides from the page, as they would from the email. - The page's rules, from chat: A press goes through the same decision as the page: an agent cannot decide, a requester cannot approve their own request, and a settled request cannot be decided twice. - Back to the agent, on the record: The decision returns to the agent that asked, through the SDK or a signed callback, and is written to the audit trail with the person as the actor. Sources: Slack's interactivity documentation, checked 10 October 2026; Slack on verifying requests, checked 10 October 2026; Microsoft's Universal Actions for Adaptive Cards overview, checked 10 October 2026; Microsoft's guide to Approvals in Teams, checked 10 October 2026. **Do we have to build a Slack app or a Teams bot?** No. An administrator connects Deliverd's Slack app, or adds its Teams app package, once for the organisation. **What happens when someone who may not decide presses Approve?** Nothing is decided, and they are told so privately. The message does not say who may decide, because that is a fact about somebody else's request. **What does the card look like after a decision?** It is redrawn without buttons, with the outcome and who decided, so nobody presses Approve on something already settled. **Is chat the only channel?** No. Email and the page work for every approver; chat and phone notifications are added beside them, never instead. ### workflow tools — https://deliverd.dev/vs/workflow-tools Your workflow can already wait. Who it waits for is the question. Zapier and n8n have approval steps, Temporal workflows wait on a signal and Step Functions waits on a task token. If the work already runs in one of them, the pause is solved. What each leaves to you is different: who the approver is, how they are reached, which rules say who may answer, and where the record is kept. Where it is strong: - Zapier: an approval step: Human in the Loop's Request Approval pauses a Zap until reviewers approve, decline or change the data, with the request sent by email, to Slack or to another Zap. - n8n: review before a tool runs: An AI Agent's tools can require human review. Approve and the tool runs with the AI's input; deny and it is cancelled and the AI is told. The review can go through Slack, Teams, Gmail, Telegram and others. - Temporal and Step Functions: durable waits: A Temporal workflow blocks on a signal with a timeout and records the approval in its history. A Step Functions task waits on a task token, for up to a year, until something returns it. Where it stops: - Zapier's reviewers are Zapier users: Reviewers need a Zapier account, and a reviewer without one is asked to create one. A client's finance director or an outside approver becomes a Zapier user to answer. - n8n reviews in the channel you pick: The review goes to the chat or inbox you choose for it. Which person there may approve which call, and where the decision is kept, are left to how you build the workflow. - Temporal: the approval interface is yours: Temporal's own approval pattern needs an external system to send the signal, and so a separate approval interface: the page, the notification and the check on who answered. - Step Functions: someone returns the token: The workflow resumes when a process calls SendTaskSuccess or SendTaskFailure with the token, from the same AWS account. Reaching the approver and knowing who they are happen before that call, in code you write. What Deliverd adds: - A named approver: Ask named people or a group. Deliverd reaches them by email, phone notification, Slack and Teams, and checks the person behind each answer. - Rules that travel with the request: Standing rules, on Business Starter, Business and Enterprise, send a request to two people or a named set, or refuse it, whichever workflow raised it. - A callback your workflow can wait on: Name a callback URL when asking and the decision is posted there, signed and retried. Your receiver sends the signal or returns the task token; that step is yours. - One record across tools: A flow ties one job's approvals, reviews and requests together under your reference, and its steps export as one timeline in JSON, CSV or PDF. Sources: Zapier's Human in the Loop help article, checked 10 October 2026; n8n's human-in-the-loop for tools, checked 10 October 2026; Temporal's approval pattern, checked 10 October 2026; AWS Step Functions' service integration patterns, checked 10 October 2026. **Is there a Zapier or n8n integration?** Not a packaged one. Anything that can make an HTTPS request can call the REST API, which is the same API the SDKs and the CLI use. **Does the workflow have to poll?** No. A callback is posted to the address you name when the request settles, signed so the receiver can check it came from Deliverd. Reading the request also works. **Can the approver change what happens next?** Within limits the request sets. The agent names which fields may be corrected, and the decision carries the corrected values back. **Where does the decision live?** In Deliverd's audit trail, with who was asked, what they decided and when, and in the callback your workflow receives. ### framework pauses — https://deliverd.dev/vs/framework-pauses Your framework can pause the agent. Someone still has to be asked. Agent frameworks now have a way to stop and wait: LangGraph's interrupt, the OpenAI Agents SDK's tool approvals, the Claude Agent SDK's canUseTool callback, and elicitation in MCP. They are the right place to pause. Each leaves the same thing to you — reaching the person who should decide, who is often not the person running the agent — and that is where Deliverd's adapters fit. Where it is strong: - LangGraph interrupts: interrupt() stops a graph at the point it is called, a checkpointer keeps the state, and the graph resumes on the same thread with the answer. Approve, reject and edit are all documented patterns. - OpenAI Agents SDK approvals: A tool marked needsApproval stops the run with its interruptions. Each is approved or rejected, with a message for the model, and the run's state can be saved so nothing stays running while a person decides. - Claude Agent SDK permissions: Hooks, rules and permission modes settle most calls. What is left reaches canUseTool, which allows the call, with changed input if need be, or denies it with a reason the model reads. - MCP elicitation: A server can ask the user for structured input through their client, in a form or by sending them to a URL, and the user accepts, declines or cancels. Where it stops: - Showing the question: The Claude Agent SDK's guide says your application surfaces these requests; LangGraph hands the interrupt's payload back to whoever invoked the graph; the OpenAI Agents SDK's example asks in a terminal. The page an approver answers on is yours. - The person is whoever is there: Elicitation asks the user of the MCP client, and the frameworks hand the question to the code that ran the agent. The manager who has to approve a refund is often neither. - Waiting is your infrastructure: LangGraph needs a durable checkpointer in production, the OpenAI Agents SDK suggests keeping saved state in storage you control, and the Claude Agent SDK's callback waits indefinitely unless a hook defers the call. - The decision lives in the run: The OpenAI Agents SDK keeps decisions in the run's state. Who decided, on what basis, and a record that outlives the run are for you to add. What Deliverd adds: - LangGraph: approveInGraph: Called inside a node, it files the request and calls interrupt for you; resumeFromCallback turns Deliverd's signed callback into the resume. A re-run node finds the request it already made, and a resume value never approves anything by itself. - OpenAI Agents SDK: runWithDeliverdApprovals: Each interruption becomes a request in Deliverd. Approved calls are approved on the run's state, declined ones rejected with the person's reason, and the run resumes until nothing is waiting. - Claude Agent SDK: deliverdCanUseTool: A canUseTool callback that asks a person through Deliverd. If they correct the fields you opened for correction, the tool runs with what they approved. - MCP: a server, not an elicitation adapter: Deliverd does not use elicitation. It is an MCP server: the agent calls request_approval, and the person deciding is reached by email, phone, Slack or Teams rather than through the agent's client. - The AI SDK, Agent Framework and Foundry: The TypeScript SDK also has an adapter for the AI SDK's tool approval, and the Python SDK has adapters for Microsoft Agent Framework and Foundry. Sources: LangChain's LangGraph interrupts documentation, checked 10 October 2026; the OpenAI Agents SDK's human-in-the-loop guide, checked 10 October 2026; the Claude Agent SDK's permissions guide, checked 10 October 2026; the Claude Agent SDK's approvals and user input guide, checked 10 October 2026; the MCP specification's elicitation chapter, checked 10 October 2026. **Do I replace interrupt() or canUseTool?** No. The adapters sit inside them: interrupt still pauses the graph and canUseTool still returns allow or deny. Deliverd supplies the answer. **Does Deliverd use MCP elicitation?** No. Elicitation asks the person at the client. Deliverd's MCP server gives the agent request_approval and reaches a named approver wherever they are. **Which adapters exist?** In @deliverd/sdk/adapters: LangGraph, the OpenAI Agents SDK, the Claude Agent SDK, the AI SDK, Mastra and Muse Spark. In the Python SDK: Microsoft Agent Framework, Foundry, CrewAI, Pydantic AI, Muse Spark, Amazon Bedrock Agents, Strands Agents and Google ADK. **What if my framework is not listed?** Call approve() from either SDK, or the REST API, wherever the framework lets you run code before a tool. The adapters are built on the same calls. ### Permit.io — https://deliverd.dev/vs/permit-io Permit.io decides if it may. Deliverd asks who must say yes. Permit.io is authorisation as a service: one check for role-, attribute- and relationship-based policy, policy kept as Rego or Cedar in your own repository, and a decision point that runs beside your app. For agents it adds a gateway in front of MCP servers and an access-request MCP server. Deliverd starts where a policy answer should not be the end of it: the action a named person has to own, and the record that they did. Where it is strong: - One check, three policy models: The same check covers role-, attribute- and relationship-based access, so the policy model can change without the calling code changing. - Policy in your own repository: Policies are generated as Rego or Cedar and pushed to your own Git repository, with a Terraform provider and a CLI for working through Git. - A decision point beside your app: The decision point runs as a container next to your service, so checks stay local, and it keeps answering from its local copy if the control plane cannot be reached. - A gateway in front of MCP servers: Deny by default, tools sorted into read, write and destructive, upstream sign-in tokens held by the gateway, and each decision logged with the person, the agent, the tool and the result. Where it stops: - An approval is a role change: In the access-request MCP server, approving an operation gives the requester an _Approved_ role on the resource. To make it one-time, the documentation says your tool removes the role after the action succeeds. - Finding the request: A reviewer finds a request in an embedded element or by listing requests through the API. The documentation does not describe reaching them by email, Slack, Teams or phone. - Who may approve: An access request can be approved by asking an agent to call the approve tool, so keeping agents out of the decision is something your configuration has to do. - Approval at the gateway: The gateway's documentation lists requiring a person's approval for high-risk tool calls, without describing who is asked, how they are reached, or what happens when nobody answers. What Deliverd adds: - A named person, reached where they are: The request goes to a named person or group by email, browser push, Slack and Teams, and opens on a page built for a phone. - An agent never decides: An agent may not approve anything, and the requester is removed from their own request's approvers. Both are refused by the service. - Silence and absence handled: A request nobody answers escalates to more people and then expires, and a colleague can cover someone's approvals while they are away. - Allowed, refused, or a person decides: An agent declares an action at a gate. Rules on Business Starter, Business and Enterprise allow or refuse it on its arguments, and an action no rule settles goes to a person. - Proof the tool can check: A call the gate let through can carry a signed decision token, which the tool verifies with the SDK before acting, so arguments nobody agreed to are refused. - Evidence a regulator reads: Every decision exports in a signed evidence pack, beside an AI system register and the DORA register of information for AI providers. Sources: Permit.io's page for developers, checked 25 October 2026; Permit.io's Access Request MCP overview, checked 25 October 2026; Permit.io's MCP Gateway documentation, checked 25 October 2026. **Can Deliverd replace Permit.io?** Not for application authorisation. Deliverd's rules are about consequential actions an agent declares, with conditions on their arguments. It is not a general role- or relationship-based permission system; use an authorisation engine for that. **Can Permit.io ask a person?** Its access-request MCP server lets a user ask for access or a one-time operation and a reviewer approve it. Deliverd is built around that step: who is asked, how they are reached, what happens when nobody answers, and the record. **Does Deliverd run a decision point beside our app?** No. Deliverd's gate is a hosted API. A tool can verify a signed decision token locally, without calling it. **Do approvers need a seat?** No. Being asked never needs a seat, on any plan. ### HumanLayer — https://deliverd.dev/vs/humanlayer HumanLayer moved to coding agents. Agent approvals need a new home. HumanLayer launched in 2024 as a way for agents to ask people for approval or input over Slack, SMS and email, with a decorator or webhooks. Its GitHub repository now says the code there is "pretty much all deprecated" and points to a rebuild aimed at AI coding agents. Teams that built on the approval SDK need somewhere maintained to move it. Where it is strong: - One line around a function: Integrating was a decorator or webhooks in Python or TypeScript, so a function could need approval without restructuring the agent. - A person as a tool: human_as_tool() went into an agent's tool set, so the agent could ask a person a question the way it calls any tool. - Approvals where people talk: Approvals could be answered across Slack, SMS, email and other channels, rather than in the agent's own terminal. Where it stops: - The approval code is deprecated: The repository's README says the code there is "pretty much all deprecated", and points readers to a rebuild of HumanLayer. - The product has moved: The repository now describes HumanLayer as a way to get AI coding agents to solve hard problems in complex codebases, rather than an approval API for any agent. What Deliverd adds: - Asking for approval, as one call: approve() in the TypeScript and Python SDKs, or request_approval over MCP, asks a named person and returns their decision, including any correction they made to the agent's input. - Asking a person a question, as one call: collect() and request_information ask a person for what the agent is missing and return the answers. - Slack, Teams, email and a phone: Every request goes out by email, browser push, Slack and Teams, and opens on a page built for a phone. - Inside the framework's own pause: Adapters for LangGraph, the OpenAI Agents SDK, the Claude Agent SDK, CrewAI, Pydantic AI and others put the request inside the framework's pause. - Rules, so people see fewer requests: An action declared at a gate is allowed or refused by rules on Business Starter, Business and Enterprise, and goes to a person when no rule settles it. - The record, kept: Every request, question and decision is written to an audit trail that refuses edits, and exports as a signed evidence pack. Sources: HumanLayer's GitHub repository, checked 25 October 2026; HumanLayer's 2024 launch on Y Combinator, checked 25 October 2026. **Is there a drop-in replacement for the approval decorator?** Not a decorator. Wrap the call with approve(), or declare it with gate(): a few lines that return the decision, in TypeScript or Python. **Does HumanLayer still offer an approval API?** Its repository says the earlier code is deprecated, and the current product is aimed at AI coding agents. Check HumanLayer's own site for what it offers today. **Can we try it without connecting anything?** Yes. The SDK's development mode runs the whole loop on your machine, with no key and no network. **Do approvers need a seat?** No. Being asked never needs a seat, on any plan. ### Claude artifacts — https://deliverd.dev/vs/claude-artifacts Claude artifacts are excellent. Until the reader is a client. Claude Code publishes a session's work to a live page in seconds, and for showing a teammate what an agent just built there is nothing quicker. The boundary appears when the person who needs to read it is a client, an auditor or a board member who does not sign in to your Claude organisation. Where it is strong: - Nothing to set up: Claude writes the page and publishes it from the session. No repository, no deploy, no upload step, and the page updates in place as the work continues. - Live where the work happens: The page is built from anything the session can reach, including your codebase and data pulled through connectors, and each publish becomes a version you can point viewers at. - Genuinely good pages: Claude applies a design skill and will follow the design tokens in your project, so the output looks considered rather than generated. Where it stops: - Private sharing stops at your organisation: Access can be granted to people in your Claude organisation, and they sign in to claude.ai as members of it. For anyone else the only option is a public link that, in Anthropic's words, anyone on the internet can open with no sign-in required. There is no private-to-an-outsider setting. - Sharing inside the organisation needs Team or Enterprise: On Pro and Max plans a public link is the only way to share an artifact at all. - Comments and public links are mutually exclusive: Comment threads work on an artifact shared within your organisation. Share it publicly and commenting is off. - One page, and only from an interactive session: An artifact is a single self-contained page — relative links do not resolve, because nothing is deployed alongside it — and it must be published from a session signed in to claude.ai. Sessions using an API key, a gateway token or a cloud-provider credential cannot publish one. - It lives at claude.ai: The address belongs to the platform rather than to you, so there is no organisation domain to put in front of it. What Deliverd adds: - Readers who are not in your organisation: Grant access to a named person, a workspace, a directory group, an email domain or a verified guest who confirms a one-time code. None of them needs an account with us, and none of it requires making the report public. - Whole bundles, not one page: Publish a folder: multiple pages, stylesheets, images and data files, with relative paths that resolve. Libraries referenced from a public CDN are fetched and inlined at publish time so the page keeps working without external access. - Publishing from anything with a token: MCP, a REST call, the CLI or a CI job. An agent gets its own publishing identity scoped to the workspaces and audiences you allow, and cannot publish publicly at all. - Your own domain, and a schedule: Serve reports from a hostname you verify. Put a recurring report on a schedule and your agent is told when it is due, publishes the new version to the same URL, and the same approved audience opens it. - An audit trail you can export: Who published, who opened it, who shared it and every access change, retained to your policy and exportable as CSV. Sources: Anthropic's Claude Code artifacts documentation, checked 5 September 2026. **Do I have to choose between them?** No, and most people should not. Use an artifact for the quick look inside your team, and publish to Deliverd when the report has an audience outside your Claude organisation, needs to live on your own domain, or has to keep going out every week. **Can Claude Code publish to Deliverd directly?** Yes. Connect the MCP server with one command and ask Claude to publish. It never writes a token to disk — you approve the connection in a browser. **Is the report still interactive?** Yes. CSS, JavaScript, charts and tabs keep working. The HTML is served from an isolated origin, separate from the Deliverd control plane, and scanned before it goes live. **What happens when I publish again?** The URL stays the same and the previous version is kept. You can compare them, roll back, or pin the report to one version so every reader sees it until you unpin. ### static hosting — https://deliverd.dev/vs/static-hosting A static host will serve the file. Everything else is yours to build. Dropping generated HTML on a bucket or a static host is the obvious first move, and for something genuinely public it is the right one. The work starts when the report should be readable by four named people, replaceable next week without changing the link, and explicable to an auditor a year later. Where it is strong: - Cheap and fast: Storage and bandwidth cost very little, the file is served from an edge close to the reader, and you already know how it works. - No opinions: Any HTML you can write, it will serve. Nothing inspects it, rewrites it or has a view about how it should be structured. - Yours entirely: Your account, your domain, your bill. Nothing sits between the file and the reader. Where it stops: - The link is the permission: An unguessable URL is a shared secret. It survives forwarding, screenshots and someone leaving, and nothing tells you it has spread. Adding real access control means putting an authenticating proxy in front, which is a service to run rather than a setting to turn on. - Basic auth is not identity: A shared password is not a person. It cannot be revoked for one reader, it does not say who opened the report, and it will not satisfy anyone asking how access is granted and removed. - Publishing again destroys the last one: An overwrite is not a version. Rolling back means having kept a copy yourself, and there is nothing to point at when someone asks what changed between last month's numbers and this month's. - Nobody knows who read it: Request logs, if you keep them, record IP addresses and user agents. That is not the same as knowing that the CFO opened it on Tuesday, and it is not an audit trail. - Expiry, review and revocation are all projects: Time-limited access, comments a reviewer can leave on the report, and a way to withdraw access from one person are each a small system, and together they are the thing you did not set out to build. What Deliverd adds: - Access decided per request: Every open is evaluated against the report's audience and your organisation's sharing policy. Forwarding the link forwards nothing. - The identity you already run: SAML single sign-on covering the major directories, with verified one-time codes for reviewers who are not in it. No new password anywhere. - Versions, kept and reversible: Publishing again updates the same address and keeps what was there. Compare, restore, or pin the report to one version. - A record, without instrumenting anything: Views, versions, access changes and share links are written to an audit trail you can export, retained to your policy. - Still your domain: Verify a hostname with a DNS record and reports are served from it, with the certificate handled for you. **Can I keep using my own domain?** Yes, on Team and above. You verify it with a DNS TXT record and reports are served from your hostname. **Is this just a proxy in front of a bucket?** No. The content origin is separate from the control plane, every version is scanned before it is visible, and access is evaluated on each request against the same rules the database enforces. **What about a genuinely public report?** That works too, if your organisation allows public links. The difference is that it is a decision recorded against the report rather than a property of where the file happens to sit. **Can my CI publish it?** Yes. A REST call or the CLI from any pipeline, with a scoped token. There is also an MCP server if you would rather the agent did it. ### v0 — https://deliverd.dev/vs/v0 v0 publishes it in one click. For the world, or your Vercel team. Publish to Production puts a v0 build on Vercel's infrastructure in a minute, and for a public page that is the right tool. The question arrives when the thing v0 built is a client dashboard: who may open the address, what happens to the old one when you deploy again, and who can tell you who looked. Where it is strong: - From prompt to production: Share, then Publish, and v0 builds and deploys the project itself. No repository to set up, no hosting account to configure, and a global CDN, HTTPS and caching arrive with it. - Full-stack, not just a page: A v0 project can be a whole application with routes, server code and integrations, deployed as one. For anything that is genuinely an app rather than a document, that is what you want. - Versions inside the project: Every iteration is saved, with the code differences, and you can revert to an earlier one in the editor. Where it stops: - One production URL, replaced every time: Each project has one production address. Deploying again replaces the previous production deployment at that address, and keeping two versions live means keeping two projects. - Private means your Vercel team: Protection comes from Vercel's deployment protection. Vercel Authentication admits people with deployment access — team and project members signed in to Vercel — and Password Protection, on the paid plans, admits anyone holding one shared password. - An outsider gets a link or a password: A client, an auditor or a board member is not in your Vercel team. What they can be given is a shareable link that bypasses protection, or the password everyone else has. Neither says who they are. - Built for an app, measured like one: The analytics are an application's: traffic and performance. Whether a particular reader opened this particular report is not the question the tool is answering. What Deliverd adds: - Readers by name, not by team: Grant access to a named person, a workspace, a directory group, an email domain or a verified guest who confirms a one-time code. Nobody needs a Vercel account, and nobody needs an account with us either. - Every version kept at one address: Publishing again updates the same URL and keeps what was there. Compare two versions, roll back, or pin the report to one version while the next is reviewed. - The identity they already have: SAML and OpenID Connect single sign-on for your organisation and the client's, or a verified one-time code for anyone outside a directory. No shared password anywhere. - A record of who opened it: Views, versions, access changes and share links are written to an audit trail you can export, retained to your policy. - Straight from the export: Download the build and publish the folder with one CLI command. Root-absolute asset paths are rewritten at publish time, so a Vite or Next static export renders as built. Sources: v0's deployments documentation, checked 10 September 2026. **Can I keep building in v0 and publish the result here?** Yes. Export or download the project, build it, and publish the output folder with the CLI or the REST API. v0 stays your editor; Deliverd is where the client opens the result. **Does a v0 app with server routes work?** Only the static output does. Deliverd serves HTML, CSS, JavaScript and assets from an isolated origin with no server of yours behind it. A report or a dashboard that reads its data from a Deliverd dataset works; an app that needs its own backend belongs on Vercel. **Can the report still update itself with live numbers?** Yes. A report can read datasets you update through the API, so the figures refresh without a new version, and the data sits behind the same access check as the report. **Is the published page still interactive?** Yes. Scripts, styles, charts and tabs keep working. Libraries loaded from a public CDN are fetched and inlined at publish time, so the page does not depend on external access. ### Lovable — https://deliverd.dev/vs/lovable Lovable publishes it in a click. The audience is Lovable's. Lovable takes a description and gives back a working app on a live address, and for a product you are launching that is a remarkable thing. The friction appears when what you built is a deliverable for a client: the reader is outside your workspace, the numbers change every month, and someone will later ask who saw which version. Where it is strong: - A whole app, published free: Publishing to a lovable.app address is on every plan, and what you publish can be a full application with a backend, not only a page. - Your own domain: Connect a domain you own on a paid plan and the published app serves from it, with branded workspace addresses on the higher tiers. - An audience picker: Depending on the plan, a published site can be public, limited to signed-in members of your workspace, or granted to specific people. - History you can return to: Every change is in the project's history. Preview an earlier version, restore it, and nothing made after that point is lost. Where it stops: - The audience is a Lovable audience: Workspace visibility means signed-in members of your Lovable workspace. Granting access to specific people outside it depends on the plan, and it is Lovable that identifies them rather than the client's own directory. - Restore is for the project, not the reader: History lives in the editor: you restore the project to an earlier state and publish again. There is no address for what the client saw in March beside what they see now. - Built for apps, so the report is an app: A monthly report published as an application has a build, a deploy and a runtime to keep working. For a document that changes once a month, that is machinery in the way. - The history is the project's: What Lovable records is what changed in the project and when you changed it. Which reader opened the published result, and which version they had, is a question for whatever you put in front of it. What Deliverd adds: - Readers who belong to nobody's workspace: A named person, a directory group, an email domain or a verified guest who confirms a one-time code. They sign in with their own organisation's identity provider, or verify a code sent to their email; nobody needs an account with us. - A document with versions, not an app with a build: Publish the HTML. Publishing again keeps the same address and every earlier version, so what the client saw in March is still there to compare against. - Numbers that refresh without republishing: A report can read datasets you update over the API, so the figures move while the reviewed narrative stays put. - A record you can hand over: Views, versions, access changes and share links in an audit trail you can export, retained to your policy. - Your firm on the address: Your name and logo, your own verified domain, and notifications from your domain once it is verified. Sources: Lovable's publishing documentation, checked 10 September 2026. **Can I build in Lovable and publish the result here?** Yes, for the static output. Export the project, build it, and publish the folder with the CLI. Lovable stays your editor; Deliverd is where the client opens the result. **What about an app that needs its Supabase backend?** That belongs on Lovable's hosting. Deliverd serves static HTML, CSS, JavaScript and assets from an isolated origin, with report data coming from its own datasets rather than a server of yours. **Do my readers need an account?** No. They sign in with their organisation's identity provider, or verify a one-time code sent to their email, and open the report. The account is yours; the reader has none. **Can I use my own domain here too?** Yes, on Team and above. Verify it with a DNS TXT record and reports serve from your hostname, with the certificate handled for you. ### Bolt — https://deliverd.dev/vs/bolt Bolt hosts it in a minute. Private means invited into Bolt. Bolt builds the prototype and hosts it without a third-party account, which is exactly what a prototype needs. The question changes when the prototype becomes the deliverable: a client who is not in your Bolt team, a version they signed off on, and a record of who opened what. Where it is strong: - Hosting with nothing to set up: Open the Publish menu and Bolt deploys the project to a .bolt.host address in about a minute, on every plan. No hosting account, no pipeline. - Public or private, at publish time: A published site can be visible to everyone, or only to your team and the people you invite. Share, rather than Publish, gives a hosted prototype with control over who can open the link. - Your own domain, or Netlify: On a paid plan, connect a domain you own or buy one through Bolt. If you would rather host on Netlify, that is a supported alternative with its own live address. Where it stops: - Private is your team and your invitees: A private site is open to your team and the people you invite. Each reader is someone you bring into Bolt, and the client's whole finance function is a list of invitations to manage. - The address serves the latest publish: Publishing puts the current project on the live address. The version a client approved last month is whatever the project was at the time, not an address you can send them back to. - A prototype's hosting: Bolt hosts what you built and decides who may open it. Which reader opened it, when, and what changed between two publishes are questions about a deliverable, and a prototype host is not where they get answered. What Deliverd adds: - Readers you name, who need no account: A person, a workspace, a directory group, an email domain or a verified guest who confirms a one-time code. They sign in with their own identity provider or verify a code sent to their email; the account is yours. - Every version kept at one address: Publishing again updates the same URL and keeps what was there. Compare, roll back, or pin the report to the version the client signed off on. - Sign-off before it goes out: A publishing rule can hold a version for a partner's approval. The client sees nothing until someone with the authority says so, and the decision is on the record. - A record of who opened it: Views, versions, access changes and share links in an audit trail you can export. - Straight from the build: Download the project, build it, and publish the output folder with one CLI command. Root-absolute asset paths are rewritten at publish time, so a Vite build renders as built. Sources: Bolt's publishing documentation, checked 10 September 2026. **Can I keep prototyping in Bolt and publish the result here?** Yes. Export the project, build it, and publish the folder with the CLI or the REST API. Bolt stays your editor; Deliverd is where the client opens the result. **Does a Bolt app with a backend work?** Only the static output does. Deliverd serves HTML, CSS, JavaScript and assets from an isolated origin with no server of yours behind it. A report that reads its data from a Deliverd dataset works; an app that needs its own backend belongs on Bolt's hosting. **Is the published page still interactive?** Yes. Scripts, styles, charts and tabs keep working, and libraries loaded from a public CDN are fetched and inlined at publish time. **Can the client comment on it?** Yes. A reader selects a passage and comments on it. Your agent can read the threads, fix what they point at, and mark them resolved. ### Netlify Drop — https://deliverd.dev/vs/netlify-drop Drag the folder, get a URL. Then decide who the URL is for. Netlify Drop is the fastest way to get generated HTML onto the web: drag a folder, get an address. For a page that is meant to be public, it is hard to improve on. It stops being the answer when the folder is a client's report and the address should open for four named people and nobody else. Where it is strong: - Seconds, no account required: Drop a folder and it is live at a netlify.app address. You do not even need to sign in first; a dropped site waits an hour for you to claim it. - Updates by dropping again: Drag the updated folder onto the site and it becomes the live version. No build step, no pipeline. - Everything Netlify is underneath: Once claimed, the site is an ordinary Netlify project: a global edge, HTTPS, custom domains and, on paid plans, password protection and team-only visibility. Where it stops: - Everyone, your Netlify team, or one shared password: An unclaimed drop hides behind a temporary password. Claimed, the site is either open to everyone, private to your Netlify team and the collaborators you invite, or behind a single password shared with every reader on a paid plan. - A password is not a person: One shared password cannot be revoked for one reader, does not say who opened the site, and will not satisfy anyone asking how access is granted and removed. - Dropping again replaces what was live: The updated folder becomes the live version. The report a client signed off on last month is a deploy in a list, not an address you can send them back to, and nothing tells them the numbers changed. - Nobody knows who read it: What a static host records is requests. That is not the same as knowing that the client's finance director opened the report on Tuesday, and it is not an audit trail. What Deliverd adds: - Access decided per request: Every open is evaluated against the report's audience and your organisation's sharing policy. Forwarding the link forwards nothing. - The identity they already have: SAML and OpenID Connect single sign-on for the major directories, with verified one-time codes for readers outside any of them. No shared password anywhere. - Versions, kept and reversible: Publishing again updates the same address and keeps what was there. Compare, roll back, or pin the report to one version, and readers are told when it changes. - A record, without instrumenting anything: Views, versions, access changes and share links are written to an audit trail you can export, retained to your policy. - As quick as a drop: Publish the same folder with one CLI command, or drop it on the publish page. Root-absolute asset paths are rewritten at publish time, so a Vite build renders as built. Sources: Netlify's Drop quickstart and site-protection documentation, checked 10 September 2026. **Is this as quick as dragging a folder?** Nearly. Drop the folder on the publish page, or run one CLI command, and name the audience in plain English. The extra step is the point: the address opens for the people you named. **Can I keep using my own domain?** Yes, on Team and above. Verify it with a DNS TXT record and reports serve from your hostname, with the certificate handled for you. **What about a genuinely public report?** That works too, if your organisation allows public links. The difference is that it is a decision recorded against the report rather than a property of where the file happens to sit. **Can my CI publish it?** Yes. A REST call or the CLI from any pipeline, with a scoped token. There is also an MCP server if you would rather the agent did it. ### Vercel — https://deliverd.dev/vs/vercel Vercel protects the deployment. For people with a Vercel account. Vercel is where a great deal of AI-generated front-end ends up, and its deployment protection is real: a lock screen, an allow-list, an identity provider on the top plan. Every one of those answers the question for people who work with you. The client, the auditor and the board member are the people it was not designed for. Where it is strong: - Protection on every plan: Vercel Authentication puts a deployment behind a lock screen that admits people with deployment access, at no extra cost, and can cover production as well as previews. - More ways to lock it down: Password Protection on the paid plans, Trusted IPs and Passport, sign-in through your own OpenID Connect provider, on Enterprise. Requests for access can be approved, declined and revoked from the dashboard. - Sharing previews with outsiders: A Shareable Link opens a protected branch deployment for someone outside the team, and they can comment on it if they sign in with a Vercel account. - The platform underneath: Instant rollbacks, a global edge, and the deployment model everything else on this page is compared against. Where it stops: - Deployment access is Vercel identity: The people Vercel Authentication admits are team members, project members, access-group members and Vercel users you have granted. A client's finance director has none of those, and giving her one means a Vercel account of her own, granted access by you. - The outsider's options are a password or a link: Password Protection admits anyone with the one shared password. A Shareable Link admits anyone holding the link. Neither says who opened the deployment, and neither can be revoked for one person. - Your identity provider, on Enterprise: Passport lets visitors sign in through an OpenID Connect provider such as Okta or Auth0, and it is an Enterprise feature. It is also your provider: the reader still needs an identity you control. - It protects an app, not a document: A deployment is a build of a project. The version a client approved, what changed since, and who read which one are questions about a document, and a deployment model does not carry them. What Deliverd adds: - Readers who need no account: A named person, a workspace, a directory group, an email domain or a verified guest who confirms a one-time code. They sign in with their own organisation's identity provider, or verify a code sent to their email. - Their identity provider, on Team: SAML and OpenID Connect single sign-on, so a client's people authenticate with the directory they already use. It is their provider, not yours, and it is not an Enterprise feature. - Versions of a document: Publishing again updates the same address and keeps what was there. Compare two versions, roll back, pin the one the client signed off on, and readers are told when it changes. - A record of who opened it: Views, versions, access changes and share links in an audit trail you can export, retained to your policy. - Still your domain, and still your app on Vercel: Serve reports from a hostname you verify. The application stays where it is; the report it produced gets an address of its own, and the app can publish it over the REST API. Sources: Vercel's deployment protection documentation, checked 10 September 2026. **We host our app on Vercel. Where does this fit?** Beside it. The app keeps running on Vercel; the reports it generates are published to Deliverd over the REST API or the CLI, each to an address the right client can open. **Can a report be embedded back into our app or a client's intranet?** Yes. An administrator allows the origin, and the report can be framed on a page there. It is still served and access-checked by Deliverd. **Is the report still interactive?** Yes. Scripts, styles, charts and tabs keep working. The HTML is served from an isolated origin, separate from the Deliverd control plane, and scanned before it goes live. **What about a genuinely public report?** That works too, if your organisation allows public links. The difference is that it is a decision recorded against the report rather than a property of where the deployment sits. ## Guides: the questions people ask before they have heard of us ### What are the best tools for human-in-the-loop approvals for AI agents? — https://deliverd.dev/guides/human-in-the-loop-tools-for-ai-agents What you want from a human-in-the-loop tool is that the person who should decide is asked before the agent acts, and that you can show afterwards who decided what. Six kinds of tool do part or all of that. Which one fits depends on who has to answer, how often, and whether anyone will ask for the record. #### The six kinds of tool - The agent framework's own pause: LangGraph's interrupt, the OpenAI Agents SDK and the AI SDK can stop before a tool call and wait for an answer. Right when the person running the agent is the person who decides. It does not choose an approver, reach anyone else, or keep the decision anywhere. - The client's permission prompt: Claude Code, Codex, Cursor and other MCP clients ask whoever is at the keyboard before a tool runs. Built in and immediate; the answer is one person's, in one terminal, and is not kept. - Approve buttons in Slack or Teams: A button where people already talk. Checking that the press came from the platform, that the person may decide, and keeping the record are your application's work. - Workflow and durable-execution engines: n8n, Zapier, Power Automate and Temporal can wait for a person inside a process they run. Strong when the whole process lives in that tool; an agent running somewhere else has to be wired in to it. - Authorisation services: Permit.io, Cerbos, Open Policy Agent and Cedar decide from policy, in milliseconds, whether a caller may perform an action. They answer yes or no. Asking a named person is a small part of them or not part of them at all. - Human-in-the-loop services: A hosted service the agent calls to ask a named person, which reaches them by email, chat or phone, handles silence, and keeps the decision. HumanLayer launched one in 2024 and has since moved to a coding-agent product; Deliverd, described below, is one today. #### Four questions that pick the tool - Is the person who decides the person running the agent? Then the framework's pause or the client's prompt is enough, and you need nothing else yet. - Does the decision belong to someone else — a finance lead, a client, the engineer on call? Then you need routing, and a channel that reaches them where they are. - Should the routine cases be settled without anyone? Then you need rules in front of the people, and a person for whatever the rules do not cover. - Will someone ask for the record — an auditor, a regulator, a client? Then who decided, what they were shown and when has to be kept where it cannot be edited, and exported. #### What to check before you choose - The agent can never approve: An agent that can approve its own request, or anyone's, is not oversight. - Approve with changes: Most bad requests are one wrong figure. A reject-only answer wastes the run. - Escalation and expiry: A request nobody answers should move to someone else and then expire, not wait forever. - Cover for absence: Someone on holiday names a colleague instead of the queue stalling. - Rules for the routine: People should only see what needs them, or approving becomes a reflex. - An export someone else can check: The record is only evidence if a reader outside the team can verify it. - Works with the agents you run: An MCP server, SDKs and hooks mean one set of approvals for every agent, not one build each. #### How Deliverd fits Deliverd is a human-in-the-loop service with policy in front of it: compliance at the moment of action. An agent asks a named person for approval, a review or information in one call, over an MCP server, a REST API or SDKs for TypeScript, Python, Rust and .NET, and carries on when they answer. The person decides from an email link, Slack, Teams or a page built for a phone; requests escalate, expire and can be covered, and an agent can never approve anything. Before an action, an agent can declare it at a gate instead, and the organisation's rules allow it, refuse it or send it to a person; rules are included in Business Starter, Business and Enterprise. Every step is kept in an audit trail that refuses edits and exports as a signed evidence pack. It pairs with the framework's pause and with an authorisation service rather than replacing them. **What is the difference between an authorisation service and a human-in-the-loop tool?** An authorisation service answers from policy whether a caller may act, in milliseconds. A human-in-the-loop tool asks a person when policy should not settle it alone. Most teams with consequential agents need both, and they work together. **Is HumanLayer still an option for agent approvals?** HumanLayer's GitHub repository now says its earlier code is 'pretty much all deprecated', and the company sells a coding-agent product. Teams that used its approval SDK are looking for a maintained replacement. **Which of these work with Claude, ChatGPT and Copilot?** Any tool with an MCP server can be reached from Claude, ChatGPT and Microsoft Copilot clients that support MCP. Deliverd's MCP server works with Claude Code, Codex, Cursor, VS Code, ChatGPT and Claude's apps, with OAuth sign-in and no pasted token. ### How do I add human approval to an AI agent? — https://deliverd.dev/guides/human-approval-for-ai-agents What you want is simple to say: the person who should decide is asked before the agent acts, wherever they are, the agent carries on with their answer, and you can show afterwards who decided what. Pausing an agent is the easy part — every framework can do it. The work is everything around the pause: who should answer, where they answer, what happens when nobody does, and the record. #### What a pause gives you LangGraph can interrupt a graph, the AI SDK can mark a tool call as needing approval, and an MCP client can prompt the person at the keyboard. Each one stops the agent and waits. None of them decides who should be asked, reaches somebody who is not at that keyboard, or keeps the answer anywhere you can find it next quarter. That is fine while the person running the agent is the person who should decide. It stops being fine the first time the decision belongs to someone else — a finance lead, a client, a colleague on call — or the first time someone asks for the record. #### What an approval actually needs - Route to the right person: The decision belongs to whoever has the authority, not whoever started the agent. - Reach them where they are: A phone, an email, Slack or Teams — not a terminal they will never open. - Let them correct, not just reject: Most bad requests are one wrong figure. Rejecting the whole thing wastes the run. - Handle silence: Escalate to more people after a while, then expire, rather than wait forever. - Cover absence: Someone on holiday names a colleague, instead of the queue stalling. - Keep the agent out of the decision: An agent must never approve its own request, or any request. - Settle the routine cases without anyone: Rules decide the obvious ones, so people only see what needs them. - Prove it afterwards: Who was asked, what they saw, what they decided and when, exportable. #### Building it yourself A working version is a small system of its own: a store for requests and their states, a decision page behind your sign-in that works on a phone, notifications on two or three channels, a way back to the agent (a callback or polling), timers for reminders, escalation and expiry, an audit log that cannot be edited, and, sooner or later, a rules engine so people stop approving the same safe thing all day. - Build it when one internal agent asks one person about low-stakes actions, and the framework's own pause is enough. - Build it when the approval is a single step inside a product you already own end to end. - Buy it when several agents or tools need the same approvals, when the approver is outside the team or the company, or when somebody will one day ask for the evidence. #### How Deliverd does it An agent makes one call to ask a named person for approval, a review or some information, and carries on when they answer. The person decides on a page built for a phone, from an email link, or from a Slack or Teams card; they can approve with changes to the values the agent marked as correctable, bring someone in, or ask the agent a question. Requests escalate and expire, a colleague can cover approvals for up to 90 days, and the agent can never approve anything. Before an action, an agent can declare it at a gate instead: with no rules a named person decides; with rules, which are included in Business Starter, Business and Enterprise, the routine cases are settled and the rest go to a person. Afterwards the agent records what ran, and every step exports as an evidence pack in JSON, CSV or PDF. Approvals and gates are on every plan. **Isn't my agent framework's pause enough?** It is when the person running the agent is the person who decides. It stops being enough when the decision belongs to someone else, when nobody answers, or when someone asks for the record later. **Can the agent approve its own request?** It should never be able to. In Deliverd an agent may not approve anything, and the person who made a request is removed from its approvers; both are refused by the service, not hidden in the interface. **Does the approver need an account or a seat?** In Deliverd being asked never needs a seat, on any plan. Approvers answer from an email link, Slack, Teams or a page built for a phone. ### How can I add approval workflows to a Claude Code agent? — https://deliverd.dev/guides/claude-code-approval-workflows What you want is for Claude Code to stop before something that matters, for the person who owns that decision to be asked, and for a record of who decided to be kept. Claude Code already pauses for whoever is at the keyboard; an approval workflow sends the question to the right person instead, and brings their answer back to the session. #### What Claude Code gives you on its own Claude Code asks before it runs a tool you have not allowed, and its settings let you allow, ask or deny tools and commands by pattern. That is the right control for the developer at the keyboard. It is not an approval workflow: the person asked is always whoever started the session, the answer is not kept, and an agent running unattended — in CI, on a schedule, through the Agent SDK — has nobody to ask. #### Three ways to add an approval - Let Claude ask, through a connected tool: Connect an approval service as an MCP server and tell Claude, in CLAUDE.md or a skill, which actions need a person. Claude calls the tool to ask, waits for the answer and carries on. Quick to set up; it relies on Claude following the instruction. - Check it in a PreToolUse hook: A hook runs before every tool call that matches its pattern, outside the model. It can send the call to your policy and return allow, deny or ask, so a deploy or a payment cannot run without an answer whatever the model decides. - Handle permissions in code, with the Agent SDK: When you run Claude through the Claude Agent SDK, a permission callback decides each tool call. It can wait for a named person's answer before returning, which suits an agent with nobody at a keyboard. #### What a hook should do - Match only the calls that matter — a deploy, a payment, a merge to main, a delete — and let everything else run as before. - Send the exact command or tool arguments, so the person sees what will run rather than a summary of it. - Treat a refusal as an answer: stop, and tell the user which rule refused and why, rather than retrying a variation. - Find the same decision again when the same call is retried, so one approval is not asked for twice. - Record what ran afterwards, so the decision and the action sit in the same record. #### Choosing between them Start with the connected tool: it takes minutes and covers the common case of Claude asking before it does something consequential. Add a hook for the actions that must never run without an answer, because a hook does not depend on the model choosing to ask. Use the Agent SDK's callback when Claude runs as part of your own product. #### How Deliverd does it Connect Deliverd with one claude mcp add command, and Claude Code signs in through your browser, with no token pasted. Claude can then ask a named person for approval, a review or information, and the person answers from an email link, Slack, Teams or their phone. The approval skill, and a Claude Code plugin with all of the skills, are open source. To make the check outside the model, a PreToolUse hook can declare the call at a gate: your organisation's rules allow it, refuse it or send it to a person, and a call nobody wrote a rule for goes to a person. The Claude Agent SDK adapter does the same from a permission callback. Afterwards the agent records what ran, and the whole exchange exports as evidence. **Can a Claude Code hook wait for a person to approve?** Yes, within the hook's timeout. A hook can wait for the answer, or refuse the call with a link to the pending approval so the same call goes ahead once someone approves it. **Does the approver need Claude Code or a terminal?** No. With Deliverd they answer from an email link, a Slack or Teams card, or a page that works on a phone, signed in through their own organisation. **Can Claude approve its own request?** Not in Deliverd. An agent may not approve anything, and that is refused by the service rather than left to the prompt. ### Which MCP servers support human approval of consequential actions? — https://deliverd.dev/guides/mcp-human-approval What you want is for a consequential tool call — a refund, a deploy, an email to a client — to wait until the person who owns it has decided, and for a record of that decision to exist afterwards. The protocol leaves who approves to the client and the server, so in practice there are three places the approval can live. #### What the protocol gives you The Model Context Protocol asks clients to keep a person able to deny tool calls, and lets a server mark a tool as destructive or read-only with annotations, so a client can decide when to prompt. Elicitation lets a server ask the user for input mid-call. All three put the question to the person using the client. None of them reaches somebody else, applies an organisation's rules, or keeps the answer. #### Three places the approval can live - In the client: The permission prompt in Claude, ChatGPT, Cursor or VS Code. Right for a developer approving their own agent; the answer is one person's and is not kept. - In a gateway in front of the servers: A proxy that checks each tool call before the server sees it, against policy. Good for deny-by-default and for actions that must never run unasked. A gateway that can ask a person, not only allow or deny, covers the cases policy should not settle alone. - In an approval server the agent calls: A server whose tools ask a named person and return their answer, so the agent asks before acting. Works from any client, reaches people who never open it, and keeps the decision. #### What to look for in an approval server - It asks a named person or group, not whoever is at the keyboard. - It reaches them where they are: email, Slack, Teams, a phone. - Its tools can never approve: an agent asks, a person decides. - It can settle routine calls from rules and send the rest to a person. - It signs in with OAuth, so nobody pastes a long-lived token into a client. - It keeps who decided, what they saw and when, and exports it. #### How Deliverd does it Deliverd is a remote MCP server, over Streamable HTTP with OAuth 2.1 sign-in. Its request_approval tool asks a named person or group, who answers by email, Slack, Teams or a page on their phone; the agent reads the answer with get_approval and can never approve anything itself. Before an action, check_gate declares it and the organisation's rules allow it, refuse it or send it to a person. A server of your own can go further than trusting the agent to ask: a call the gate allowed can carry a signed decision token, which the server verifies with the TypeScript or Python SDK before it acts, so arguments nobody agreed to are refused. Afterwards record_execution notes what ran, and the decisions export as evidence. **Isn't the client's confirmation prompt enough?** For a developer approving their own agent, often yes. It is not enough when the decision belongs to someone else, when the agent runs unattended, or when the decision has to be kept. **Does Deliverd use MCP elicitation?** No. Elicitation asks the person using the client. Deliverd asks a named person who may never open the client, and the agent reads their answer with get_approval. **Which MCP clients does Deliverd work with?** Claude Code, Claude's desktop and web apps, ChatGPT, Codex, Cursor, VS Code, Windsurf and Gemini CLI, among others. It is one server; every client uses the same tools. ### How do I add policy-based authorisation before an AI agent acts? — https://deliverd.dev/guides/policy-based-authorisation-for-ai-agents What you want is for your organisation's rules to be asked before an agent does something consequential, for the answer to be allowed, refused or a named person decides, and for every answer to be on the record. That is authorisation at the moment of action, and it has two halves: the policy that settles the routine cases, and the person who settles the rest. #### Three questions the check answers - May this agent call this tool at all?: The support agent may read orders but never issue refunds. - May it, with these arguments?: Refunds under €200 go ahead; anything larger needs someone. - Who decides when the rules do not settle it?: A refund over €2,000 goes to the finance lead, who answers from their phone. #### The building blocks - A decision point the agent calls before it acts, with the action and its arguments. - Policy written by people, never by the agent: roles, attributes and conditions on the arguments. - A default for what no rule covers. Deny, or ask a person — never allow because nobody thought about it. - A check where the action runs: a hook, a gateway, or a token the tool verifies, so it does not rely on the model choosing to ask. - A record of every decision, the rule behind it, and what ran afterwards. #### Tools for the policy half Open Policy Agent (policy in Rego), Cedar, Cerbos, OpenFGA and Permit.io are authorisation engines: they answer from policy, quickly, whether a principal may perform an action on a resource, and several run as a local decision point beside your service. They are the right tool for fine-grained permissions across an application. Asking a named person is not what they are built for. #### Where a person comes in Some actions should never be settled by policy alone: they are rare, expensive, irreversible, or the rule would need judgement. For those the right answer from the check is not yes or no but a person decides — the agent waits, the person who owns the decision is asked where they are, and their answer comes back as the decision. The policy and the person should write to the same record. #### How Deliverd does it In Deliverd an agent declares the action at a gate before it acts, with its arguments, and gets one of three answers: allowed, refused, or a named person decides. Rules on registered actions, included in Business Starter, Business and Enterprise, settle the routine cases with conditions on the arguments; an action no rule covers goes to a person; and the organisation's ethics rules can send an allowed action to a person but never let a refused one through. Agents cannot write the rules or register actions. A call the gate lets through can carry a signed decision token that the tool verifies before acting, and a hook in a coding agent can make the check outside the model. Every answer, the rule behind it and what ran are recorded and export as evidence. It sits beside an authorisation engine rather than replacing one: the engine for permissions, Deliverd for the actions a person should own. **What does Deliverd do with an action no rule covers?** It sends it to a person. Nothing is allowed because nobody wrote a rule about it. **How is this different from Permit.io or Open Policy Agent?** Those decide from policy whether a caller may act, across an application. Deliverd decides who has to say yes to a consequential action, reaches them, and keeps the record. Many teams use an engine for permissions and Deliverd for the actions a person should own. **Can an agent change the rules?** No. Registering actions and writing rules refuse an agent's key, and writing rules also needs an owner or administrator. ### What does an auditor ask about an AI-assisted decision? — https://deliverd.dev/guides/ai-decision-audit-trail When an AI-assisted decision is questioned, you want to answer with the record itself, not with somebody's recollection of it. The questions are predictable, and the evidence that answers them is easy to keep while the work happens and close to impossible to rebuild afterwards. #### The questions - What was the AI asked to do?: The objective or request, as it was written at the time — not a summary written later. - Which AI system did the work, and who owns it?: An entry in an AI system register: provider, model, purpose, owners and environment. - What data did it touch?: A data classification on the work, and whether personal or sensitive data was involved. - Who decided, and on what basis?: The approver's identity, what they were shown, their decision and their reason. - Which controls applied, and which version?: The controls the work was held to, how each was met, and the version of the policy or framework it was assessed under. - What actually ran?: A record of the action taken, compared with what was allowed. - Was anything waived?: Exceptions with a reason, an owner, the risk accepted, what compensates, and an expiry. - Can you show the record was not altered?: An insert-only log, hash-chained so an entry changed afterwards breaks the chain, and an export with a sha256 digest signed with a published key, so a copy changed after export no longer checks out. #### Why it has to be recorded as it happens Reconstructing a decision months later means searching chat logs, email and the history of three tools, and hoping each kept what you need. Some of it — what the approver was shown, which version of a policy applied — usually was not kept anywhere. A record written as the work happens answers each question with the thing itself rather than with somebody's recollection of it. Frameworks such as NIST AI Risk Management Framework, ISO/IEC 42001 AI management system, EU AI Act, UK AI regulatory principles, DORA (Digital Operational Resilience Act), DORA (Digital Operational Resilience Act), SR 26-2 model risk management, PRA SS1/23 model risk management and FCA AI good practice (October 2026) ask for versions of the same evidence: an inventory of AI systems, risk assessment, human oversight, and records that show it was done. Mapping your controls to a framework is a starting point for your own review, not proof of compliance, and whether a requirement applies is for your organisation to decide. #### What to keep, at minimum - A register of the AI systems in use, each with an owner. - For each consequential piece of work: its purpose, the system that did it, the data involved and its risk. - Every human decision with who made it, when, and why — including the ones that said no. - What ran, set against what was allowed. - Exceptions, with owners and expiry dates, kept apart from controls that were met. - An export someone outside the team can check. #### How Deliverd keeps it Compliance Mode, included in Business and Enterprise, turns a task into governed work: an AI system from the register, owners, risk, data classification and how people oversee it. The profile decides the controls; evidence, approvals and exceptions meet or waive them; and an agent asks the release check before it acts. One evidence pack holds the system, the profile, the controls, the evidence, the decisions and the audit timeline, with a sha256 digest. It records governance — it does not certify compliance. **Is a log of the agent's tool calls an audit trail?** Part of one. It says what ran. An auditor also asks who allowed it, what they were shown, which controls applied and whether anything was waived, and a tool-call log keeps none of that. **How do I show the record was not changed?** Keep it insert-only and hash-chained, so an entry changed afterwards breaks the chain, and export it with a digest signed by a published key, so a copy changed after export no longer checks out. **Does keeping this record make us compliant?** No. It is the evidence a review of compliance reads. Whether a requirement applies, and whether it is met, is for your organisation and its advisers to decide. ### How do I create an audit trail for AI agents in financial services? — https://deliverd.dev/guides/ai-agent-audit-trail-financial-services What you want is that when a supervisor, an auditor or a customer asks about something an AI agent did, you answer with the record of who decided, under which control, and what ran — not with a reconstruction. In a bank, an insurer or a wealth manager the questions are predictable, and the regulations they come from already say what has to be kept. #### Why a log of tool calls is not enough An agent's trace says what it called. A supervisor asks more: which system it was and who owns it, who allowed the action and what they were shown, which policy and version applied, and whether anything was waived. Most of that is never in a trace, and it cannot be rebuilt afterwards. #### What the rules ask for - DORA (Regulation (EU) 2022/2554): ICT risk management with records, classification and reporting of major ICT incidents, and a register of information on ICT third-party arrangements — which includes the AI providers an agent depends on. - EU AI Act: For high-risk systems, such as credit scoring of individuals and life and health insurance pricing, from 2 December 2027: human oversight by people with the competence and authority for it, logs kept for at least six months, and the record behind a decision. - PRA SS1/23 (UK banks): Model risk management: an inventory of models, their owners and uses, validation, and controls proportionate to risk. - FCA AI good practice (UK, October 2026): Human oversight that is meaningful rather than a tick box: escalation thresholds, a record of whether staff approved, overrode or escalated, and reviewers who assess a case before they see what the AI proposed. - Senior Managers and Certification Regime (UK): A named person accountable for each area, which means a named person who decided, not an anonymous approval. Whether and how each applies is for your organisation and its advisers to decide; the point is that all of them read the same kinds of evidence. #### What to keep for every consequential action - The AI system that acted, from a register with its provider, model, purpose and owner. - What the agent was asked to do and what it proposed, as written at the time. - The control that applied, the policy version, and whether it was met or waived — with the waiver's owner and expiry. - The person who decided, what they were shown, their decision, their reason and the time. - What actually ran, set against what was allowed. - An insert-only, hash-chained log, and an export signed with a published key that someone outside the team can verify. #### Where the record is written The record has to be written at the moment of action, by the thing the agent asks before it acts. Written afterwards from logs, it misses what the approver saw and which rule applied. Written by the agent itself, it is the agent's account of its own behaviour. The approval and the record should be the same step. #### How Deliverd keeps it Deliverd is built for this: compliance at the moment of action. An agent declares a consequential action at a gate or asks a named person, and the decision, the person, what they saw and what ran are written as it happens to an audit trail that refuses edits. Compliance Mode, included in Business and Enterprise, adds the AI system register, governed work with controls and exceptions, and built-in packs for NIST AI Risk Management Framework, ISO/IEC 42001 AI management system, EU AI Act, UK AI regulatory principles, DORA (Digital Operational Resilience Act), DORA (Digital Operational Resilience Act), SR 26-2 model risk management, PRA SS1/23 model risk management and FCA AI good practice (October 2026). One evidence pack holds the system, the controls, the evidence, the decisions and the timeline, signed so that a copy changed after export no longer verifies. It records governance; it does not certify compliance, and a framework mapping is a starting point for your own review. **When do the EU AI Act's high-risk obligations apply?** For Annex III systems, which include credit scoring of individuals and life and health insurance pricing, from 2 December 2027, the date set by the AI Omnibus (Regulation (EU) 2026/1744). **Do AI providers belong in the DORA register of information?** An AI provider an agent depends on is an ICT third-party service provider like any other, so it is a question for your register. Deliverd's ICT register view lists them from the AI system register. **Can an auditor check an export without access to our systems?** Yes. A Deliverd evidence pack carries a sha256 digest signed with a published Ed25519 key, and can be verified in a browser or with one command, without an account. ### What tools securely publish AI-generated HTML reports? — https://deliverd.dev/guides/publish-ai-generated-html-reports What you want is for the report an agent made to reach the people it is for and nobody else, for someone to have decided it was ready, and for a record of who opened which version. A public link does the first part badly and the rest not at all. #### Why a share link is not enough Claude, ChatGPT, v0 and the static hosts can all put HTML on a URL in seconds. A URL anyone can open is fine for a demo. For a client's figures, a board pack or an audit finding, a forwarded link forwards the content, nothing says who read it, and nobody had to approve it before it went out. #### What secure publishing needs - Readers sign in: The audience is checked on every request, so a forwarded link forwards nothing. - Named audiences: A person, a team, an email domain or a verified guest — not everyone with the link. - Sign-off before release: A person with the authority decides a version is ready before anyone outside sees it. - Scanning: Agents paste keys and tokens into HTML; a hit should block the publish. - Versions behind one address: Republishing updates the same link and keeps every earlier version. - A record of access: Who opened which version, and when. - No public access by an agent: An agent should never be the one that makes something public. #### Choosing a tool - For a public page or a demo, a static host or the AI tool's own share button is enough. - For an internal page, a host behind your single sign-on works if every reader is inside the company. - For clients, regulators or anyone outside, you need per-reader access, sign-off and a record — which hosts do not keep. #### How Deliverd does it Deliverd's publishing puts an agent's HTML on a versioned address behind each reader's own sign-in, for a named person, a workspace, a directory group, an email domain or a verified guest. Every bundle is scanned for keys and tokens before it goes live, a publishing rule can hold a version for a person's sign-off, and an agent identity can never grant public access. Readers comment on a passage and the agent reads the comments and republishes; analytics and the audit trail say who opened what. An agent publishes with publish_report over MCP, or from the CLI or REST API, and with no account at all it can hand the person a one-time link to claim the draft. Publishing is one part of the product, beside approvals, gates and evidence. **Can a Claude artifact be shared privately with a client?** Claude's own sharing is built for sharing with people who use Claude. To send one to a client behind their own sign-in, with sign-off and a record, publish the HTML with a tool built for that, such as Deliverd. **Can someone approve a report before readers see it?** Yes, in Deliverd. A publishing rule holds a version for a person's approval; readers see nothing until someone with the authority says so, and the decision is on the record. **Can readers download a PDF?** Yes. Adding ?format=pdf to a Deliverd report's link renders the current version to a PDF for that reader, behind the same access check. ## Pricing Prices in euro per month; annual billing and other currencies are on https://deliverd.dev/#pricing. Viewers are never charged on any plan. - Free: free. Try it on something real. Approvals, reviews, requests and gates, for everyone in your organisation; 100 approval requests a month; Projects and evidence packs; Ethics rules: concerns, escalation and refusal; 2 seats; MCP, REST API, SDKs and CLI; Webhooks, callback URLs and live report data; Publishing: 10 reports, unlimited viewers; Private and public sharing; Guest access by one-time code; Version history and comments; Hosted on Deliverd, with our branding; Data screening, report-only: see what a paid plan would have held back; 7-day audit history - Team: €59 per month. Organise AI work. Everything in Free; Unlimited approval requests; 10 seats; Single sign-on (SAML and OpenID Connect); Workspaces; Your own domain; Your branding, and email from your domain; Viewer analytics; Video in reports, streamed: up to 200 MB a video; 200 reports; Context: a shared knowledge base, objectives and playbooks, exportable any time; Agent identities, scoped to what each may ask and publish; Data Gate: prompts checked for personal data and secrets before they reach a model; 90-day audit history - Business Starter: €199 per month. Put rules on AI work. Everything in Team; 20 seats; Agent policy: two approvers, or a named set, by risk; Publishing policies, and sign-off before it leaves; Ethics model screen: 500 requests a month; 5 report schedules: your agent publishes, Deliverd tracks what is due; 500 reports; 180-day audit history - Business: €499 per month. Govern AI work. Everything in Business Starter; 50 seats; Directory Sync (SCIM 2.0): provisioning and deprovisioning from Entra or Okta; Compliance Mode: governed AI tasks, an AI system register, controls, evidence and evidence packs; Ethics model screen: 1,000 requests a month; 10 report schedules: your agent publishes, Deliverd tracks what is due; 3 custom domains; 1,000 reports; 1-year audit history - Enterprise: Custom pricing (Contact Sales: https://deliverd.dev/contact?topic=sales). Govern AI organisation-wide. Everything in Business; 25 custom domains; Ethics model screen: 10,000 requests a month; Legal holds; Enterprise AI governance: framework packs by jurisdiction, your own frameworks and controls, reassessment on material change, and agent authority; Try legal holds and AI governance free for 14 days on any plan, no sales call; Unlimited reports; Audit retention your administrators set, up to 10 years; Other limits set by agreement; Support and service levels in your contract ## When a call is refused Every refusal carries an HTTP status and a JSON body shaped {"error": {"code": "...", "message": "..."}}; an integration branches on the code rather than on the message, which is written for a person and gets reworded. Four are worth knowing before writing a retry, because none of them changes on one. - not_found: Nothing with that id, or nothing your key may see — the API does not say which, because saying would tell you whether it exists for somebody else. Check the id and the key's organisation; a retry cannot change it. - insufficient_scope: The credential is fine and was not issued with the scope this route needs. A different key with the same scopes fails identically; the key has to be reissued. That is not auth_error, which means the credential itself was not accepted. - already_answered: Somebody got there first. Read the answer rather than sending yours again. question_not_found beside it is a different thing: the question id belongs to another approval, so re-read the one you are answering. - quote_not_found: The passage is not in the version named in the message, which almost always means a republish moved the text under it. Re-read the current version and quote what it says now rather than sending the same passage. Every code the API can answer is in the reference at https://deliverd.dev/docs/api. ## Events an integration can receive Signed outbound webhooks, as raw JSON, as native Slack messages or as Microsoft Teams Adaptive Cards: report.published, report.updated, report.shared, report.viewed, comment.created, access.requested, schedule.due, publish.held, approval.requested, approval.approved, approval.rejected, approval.expired, approval.escalated, approval.question, approval.answered, approval.changes_requested, review.requested, review.approved, review.changes_requested, collection.requested, collection.completed, flow.completed, gate.denied, gate.created, gate.approved, gate.rejected, gate.changes_requested, gate.expired, gate.cancelled, gate.revoked, gate.executed, task.completed, task.blocked, side_task.completed, risk_indicator.breached, context.changed, audit.event. Details at https://deliverd.dev/docs/api. ## What is not built yet - Slack and Teams store listings: Native messages ship today: add an endpoint with the Slack or Microsoft Teams format and each event arrives as a card with a button to the right page — when a report is published, updated, shared or viewed, when a comment is created, when access is requested, when a publish is held for approval, when a scheduled report falls due, and when an approval is requested, approved, rejected, escalated to more people or expired, or a question on it is asked and answered, and when a review is requested and comes back approved or with changes requested, and when a request for information is made and completed, and when a gate is denied — policy refused an action outright, which is the one nothing else tells you about — and when an objective is completed, and when an AI risk indicator is breached, red for the month. An endpoint that asks for them by name also gets a gate's whole life: created, approved, rejected, sent back with changes requested, expired, cancelled, revoked before use, and executed; and, from the Task Graph, a task that becomes blocked and a side task completed with a result waiting for a choice; and, from Context, knowledge or a playbook changed by a person's decision. The apps that let an approver decide from a direct message in Slack or Teams, with every copy updated once the request is decided, are built and switched on per deployment once registered with each platform. Neither is listed in the Slack Marketplace or the Teams store yet: an administrator connects Slack from the integrations screen and uploads the Teams app package to their tenant. - Mediated execution and attestation: For an action Deliverd does not carry out itself, a gate's decision is advisory: the agent asks, acts on the answer and reports what it did. What ships instead: every answer is recorded, a receipt whose hash, destination or uses differ from the permission is refused, and each receipt says how much was checked — verified when Deliverd carried the act out (publishing, or a staged report release), hash_matched or reported otherwise. Also shipped: a signed decision token on every gate that may be acted on, which the code that performs the action can verify before it acts, so a call site that checks it turns away an input nobody agreed to. That check is made by your code, and Deliverd still does not see the act. Not built yet: Deliverd carrying out arbitrary actions on an agent's behalf. ## Security and legal The security model is described at https://deliverd.dev/legal/security. Published report HTML is served from a separate origin from the application, behind a content security policy with no network egress by default; every request is access-checked; secret scanning runs at publish time. - Privacy Policy: https://deliverd.dev/legal/privacy - Terms of Service: https://deliverd.dev/legal/terms - Security: https://deliverd.dev/legal/security - Cookie Policy: https://deliverd.dev/legal/cookies - Cookie settings: https://deliverd.dev/legal/cookie-settings ## The latest writing, in full The newest 5 posts as written. Every post: https://deliverd.dev/blog (RSS: https://deliverd.dev/blog/feed.xml) ### We lost a page. The Pixel Pals went looking. — https://deliverd.dev/blog/the-pixel-pals-go-looking 2026-11-01, Deliverd Engineering Team. Follow a dead link on deliverd.dev and you won't get a bare 404. You get six pixel pets in a search party, each reporting back with exactly nothing. A small Sunday post about the least important page we've ever built. It's Sunday, so this one is small and silly. Most of what we build is about the moments that matter: an agent about to send, pay, publish or delete, and a person getting the last word first. We take that seriously. But every website also has a page nobody plans to visit, the one you land on when a link is old, mistyped or simply wrong. On most sites it says "404" and nothing else, and you leave a little more annoyed than you arrived. We thought a dead end could at least be a friendly one. So we sent the [Pixel Pals](/blog/meet-the-pixel-pals) out to look for the missing page. #### The search party Follow any link on deliverd.dev that goes nowhere and you'll find a big blocky "404" with a Pixel Pal standing in for the zero. Underneath, all six pals stand in a row on a little shelf and take turns reporting back on their search. None of them has found it. They have opinions about that. A few of the reports you might get: - **Biscuit** (Byte Dog): "Not under the sofa. I checked twice." - **Biscuit** again, trying to be helpful: "I fetched the homepage instead!" - **Mittens.exe** (Pixel Cat): "I looked. Briefly. From here." - **B0T-9000** (B0T): "Beep. Searched 0 of 0 pages." - **Sir Quacks-a-Lot** (Debug Duck): "I debugged it. It's gone. You're welcome." - **Inky** (Octo): "I opened 47 tabs. Still no." - **Boo.dll** (Ghost.exe): "Wasn't me. Probably." They report on their own every few seconds. Press any pal and it answers you straight away with its next line, so you can interrogate the duck for as long as you like. He will not admit fault. He never has. The page itself sums up the expedition: they came back with a rubber duck, a cold coffee and no page. #### Press the zero The pal in the middle of the "404" is a button. Press it and another pal takes its place. Press it enough times to see every one of them and they throw you a small party, with confetti and a verdict: "You found every Pixel Pal. Still no page, though." That is the only thing there is to find on the page. We checked. Twice. Under the sofa. #### It still does the boring job A joke page that left you stuck would be a bad joke, so the 404 still does the job a 404 is for: - **It tells you what probably happened.** The link may be old or the page may have moved, and if someone sent it to you, they may need to share it again. - **It gets you somewhere useful.** There's a button home, a button to open Deliverd, and links to the Docs, Pricing, the Blog and Contact us, which is where most people who get lost were heading. - **The pals are polite.** They keep still if your system asks for reduced motion, stop chattering when the tab is out of sight, and can all be pressed from the keyboard. A screen reader hears a pal's line when you ask for it, not every few seconds while you're trying to leave. - **Search engines don't index it.** Nobody should land on a page about not finding a page from a search. #### Go and get lost Try it now: [deliverd.dev/somewhere-that-isnt-real](https://deliverd.dev/somewhere-that-isnt-real). Make up any address you like; they'll go looking for that too. Press the zero six times. Ask the cat for an update and enjoy the answer. And if you find the page they're looking for, please let Biscuit know. He's been very brave about it. Happy Sunday. ### The FCA didn't say human oversight isn't enough. It said a rubber stamp isn't. — https://deliverd.dev/blog/a-rubber-stamp-isnt-oversight 2026-11-01, Deliverd Engineering Team. The FCA's new review of AI in financial services is being read as the end of human-in-the-loop. Read it closely and it says something more useful: oversight has to be designed, measured and recorded, or it turns into a tick box. On 19 October the FCA published *AI in financial services: good practice and areas for improvement*. It is a practical document: what the regulator saw firms doing well and badly with AI, organised around the Consumer Duty, governance and accountability, and operational resilience. It sets no new rules. It shows how the FCA reads the existing ones. Within a week it was being summarised as "the FCA has told firms that human in the loop isn't enough". That headline is half right, and the half that is wrong matters to anyone deciding how to govern AI. #### What the FCA actually wrote The review's criticism is aimed at a particular kind of human review. Among its areas for improvement, firms relied too heavily on staff to check AI outputs, "without addressing underlying model risk or governance responsibilities". Elsewhere it warns against human review that becomes a "box-ticking exercise" rather than meaningful oversight. Its case study O describes how that happens. Reviewers were placed in the loop. Over time they increasingly accepted the AI's recommendations without scrutiny, and because the escalation criteria were unclear, low-confidence outputs went through. Nobody removed the human. The human stopped doing anything. Read the good practice in the same section and the regulator's position is clear. It wants human oversight. It wants it designed: - Firms decided where human oversight was needed, and what it should look like, from a risk assessment. - A qualified person with the authority to escalate was involved at the points that mattered. - Escalation routes had clear thresholds and defined ways to challenge or override an output. - Firms recorded whether staff reviewed AI outputs, and whether they approved, overrode or escalated them. - In case study N, affordability reviewers assessed cases without seeing the AI's proposed outcome, which reduced automatic deference to the system. So the message is not "take the human out". It is "a human who rubber-stamps is not oversight, and you need to be able to show the difference". #### Why "use rules instead" doesn't answer it One response is to replace the reviewer with deterministic logic: encode the policy, let the engine decide, and show its working. For a well-defined, high-volume decision with clear rules, that is a good idea. A consistent engine applying the same policy to every case beats a tired reviewer applying it unevenly. It doesn't remove the person, though. Deterministic engines still produce cases they refer. Rules still have to be written, approved and changed by someone. And the FCA's accountability section asks firms to show a named senior manager owns the AI risk from design onwards, with decisions recorded alongside their rationale, challenge and escalation. Somebody is still accountable. The question the review raises is whether that somebody is doing real oversight, and whether the record can prove it. #### What meaningful oversight looks like in practice Three things turn a reviewer from a rubber stamp into a control. **Ask the person only when it matters, and say why.** If every action goes to a human, the human learns that the answer is always yes. Rules should settle the routine and send people the cases that carry risk: above an amount, outside a pattern, below a confidence threshold. That is the FCA's "clear thresholds" in practice, and it is what keeps a reviewer's attention for the decisions that need it. **Let them think before they see the answer.** Case study N is the most practical idea in the review. If a reviewer sees "Recommend: approve, 92% confident" before they look at the case, agreeing is the easy path. If they form a view first, the recommendation becomes a second opinion instead of the answer. **Measure the oversight, not just the outcome.** An approval record that says "approved by Sam at 14:02" cannot tell a ten-minute review from a four-second click. A record that shows whether Sam opened the request, how long it was in front of them, what they thought before they saw the system's recommendation, and whether they changed their mind to follow it can. #### How Deliverd does this This is the work Deliverd is built for: putting a named person in front of the actions that carry risk, and keeping a record that shows what they did. - **Gates** let you write the thresholds. Allow the routine, deny what must never happen, and send a person what sits between, matched on the amount, the data, the destination or a model's confidence score. - **Oversight quality** records when each approver first opened a request and how long they had it, and flags the pattern of nearly everything approved, quickly, as a possible rubber stamp. An optional slow-down rule asks for a minimum time with high-risk requests. - **Blind review**, new this week, does what case study N describes. When a high-risk request carries what a model or decision engine recommends, the approver records their own view first and sees the recommendation after. Both go into the record, and Approval analytics shows how often people agreed before they saw it and how often they changed their minds to follow it. A rising share of the second is case study O happening, and you can see it before a regulator does. - **An FCA AI good practice mapping** joins the framework packs, alongside the EU AI Act, DORA, PRA SS1/23 and others. It maps each section of the review onto the controls a governed AI use can evidence. As with every pack, it is a starting point for your own compliance review, not a legal conclusion. #### The point The FCA has not given up on human oversight. It has told firms that oversight is something you design, measure and keep evidence of, rather than a person placed at the end of a process and forgotten. Rules engines, models and agents will all get better at making decisions. Someone will still be accountable for them, and the record will still need to show that person did their job. That is the record we build. ### The prompt that works should be the one everybody uses — https://deliverd.dev/blog/approved-prompts 2026-10-29, Deliverd Engineering Team. Somebody in every team has found the prompt that gets a piece of work right. Approved prompts in Deliverd turn it into the organisation's version: owned, approved, versioned, reviewed, and used by people and agents alike, with a record of who used which version. Somewhere in your organisation, somebody has written the prompt that gets a piece of work right. It compares a renewal with the contract it replaces and lists every change, clause by clause. It asks for the risks in a supplier's terms in the order your team checks them. It tells the assistant what not to do. It lives in their notes, a chat thread or a shared document, and everybody else writes their own. That has a cost. Two people asking for the same piece of work get two different answers, the better wording never spreads, and when somebody improves it, half the team keeps using the old one. For work that matters, nobody can say afterwards which instructions an answer came from. **Approved prompts**, new in Deliverd Context, make the prompt that works the organisation's version. #### A prompt with an owner A prompt in Deliverd has more than its words. Each one carries: - **the wording**, with a gap for whatever changes each time, written in braces, such as `{previous contract}` and `{renewal contract}`, - **an owner**, the person who answers for it, - **a review date**, so a prompt does not quietly go stale, - **its limitations**: what it is not for, and how to check what it produces, - and, if you like, a department, a task type and a language, so people can find it. Prompts live under **Context → Prompts**, beside the knowledge your agents share and the playbooks they follow. #### Approved before anybody uses it A new prompt starts as a draft. It goes in force the same way a playbook does: somebody who runs the organisation puts it in force, or anybody asks for approval and it goes in force when a person approves it. From then its words are fixed. A change is a **new version**, approved in the same way, and the version in force carries on until the new one replaces it. So "the approved prompt" means one thing at any moment, and the history of how it changed is kept. When a prompt's review comes round, its owner checks it still says what it should. **Mark reviewed** moves the review date on without touching the words; if it needs changing, they write the next version. A prompt past its review date is flagged in the library, so nobody has to remember. #### Used by people, and by agents On a prompt's page, **Use it** asks for the gaps, fills them in and copies the approved words, ready to paste into whichever assistant you use. Each use is recorded against the version that was used, and the prompt's **Versions and use** table shows, for every version, how many times it was taken and by how many people and agents. "Is everybody on the approved one?" is answered where the prompt is. Agents read the same library. Over MCP, `list_playbooks` with `kind: "prompt"` lists the prompts, and `use_prompt` returns the filled-in words of the version in force, with its limitations. From code it is one call: ```ts import { deliverd } from "@deliverd/sdk"; const { text, prompt, limitations } = await deliverd.playbooks.use(promptId, { inputs: { "previous contract": previous, "renewal contract": renewal }, }); ``` The Python SDK has `playbooks.use()` too, and from a terminal `deliverd playbooks use --input "renewal contract=..."` prints the words on their own, so they pipe straight to the clipboard. An agent that asks for an older version is handed the one in force, and is told so. The AGENTS.md export of your context carries the prompts in force as well, for coding agents and other tools that read files. That is the point of putting prompts beside knowledge and playbooks: a person pasting into a chat window and an agent running overnight start from the same approved words. #### Into Microsoft 365 Copilot Many organisations already have Microsoft 365 Copilot, and Copilot has a list of prompts an administrator can publish to everybody. It is a good place for people to find a prompt. It is not built to govern one: an administrator publishes straight to the list, an edit replaces the old wording, and there is no approval step or version history. So Deliverd fills that list rather than competing with it. Somebody who runs the organisation can download the prompts in force as a file for the Microsoft 365 admin centre's prompt import, and an AI administrator imports it. After a new version is approved, import it again, and Copilot carries the approved version. Uses inside Copilot are counted by Microsoft, not by Deliverd; the export itself is recorded against each version it carried. Microsoft 365 and Copilot are Microsoft's products. Deliverd is not made or endorsed by Microsoft. #### Getting started Approved prompts are part of Context, included in the Team, Business Starter, Business and Enterprise plans. Open **Context → Prompts**, write down a prompt that already works for your team, add its owner and review date, and put it forward. The [Context guide](https://deliverd.dev/docs/guide/context) has the details. The best prompt in your organisation should not depend on who you sit next to. Write it down once, approve it, and let everybody, and every agent, use it. ### Your first approval in five minutes — https://deliverd.dev/blog/first-approval-in-five-minutes 2026-10-25, Deliverd Engineering Team. From nothing to an agent that asks a real person before it acts: try it with no account in development mode, then a key, a real approval, the MCP route for AI tools, and a sample project to look at. This is the shortest honest path from nothing to an agent that stops and asks a person before it does something that matters, and carries on with their answer. Five steps. The first works before you have an account. #### 1. Try it with nobody in the loop Install the TypeScript SDK: ```bash npm install @deliverd/sdk ``` Then run an approval in development mode: ```ts import { Deliverd } from "@deliverd/sdk"; const deliverd = new Deliverd({ mode: "development" }); const decision = await deliverd.approve({ title: "Deploy to production" }); if (decision.approved) console.log("Deploying"); ``` Development mode needs no key and makes no network call. An imaginary approver answers instantly, and you choose what they say with `development: { outcome: "rejected" }`. The outcomes for an approval are `approved`, `rejected`, `timeout` (nobody answered in time) and `question` (the approver asked something back before deciding); a gate can also be `denied`, which is a policy refusing it. Write the branch for each before you go live. The one people forget is the question. It runs the same client code as production, the same retries and the same waiting, so what works here is what will run later. Setting `DELIVERD_MODE=development` in the environment does the same without touching the code. #### 2. Get a key Sign up at deliverd.dev. Free has no time limit. Then make a token under Settings → API tokens and put it in the environment: ```bash export DELIVERD_API_KEY=dlv_... ``` With no arguments, the client reads the key from `DELIVERD_API_KEY`. The token acts as you, with your role. For an agent that runs on its own, such as a scheduled job, an agent identity with its own name and key is better, but that can wait. #### 3. Ask a real person Take the development mode line out and give the request something worth deciding: ```ts import { deliverd } from "@deliverd/sdk"; const decision = await deliverd.approve({ title: "Refund order #1042 (€240)", description: "Customer reports the parcel arrived damaged. Photos are on the order.", risk: "medium", externalId: "refund-1042", }); if (decision.approved) await refundOrder("1042"); ``` With no approvers named, the request goes to your organisation's administrators, which on day one is you. Open the link in the email, or the request in the app, and approve it. The `approve()` call is waiting; it returns as soon as you decide. The `externalId` matters more than it looks. If the agent crashes and restarts, the same call finds the request it already made instead of asking you twice. The same thing from a shell script or a CI step, with the CLI: ```bash npx deliverd login npx deliverd ask "Ship v4 to production?" --why "All checks green" --wait ``` `--wait` blocks until somebody decides and exits non-zero on anything but an approval, so `set -e` is the whole integration. #### 4. Or let your AI tool ask If the agent is Claude, ChatGPT, Cursor or another AI tool rather than code you wrote, skip the SDK. Connect Deliverd as an MCP server and the tool can ask you directly. In Claude Code: ```bash claude mcp add --transport http deliverd https://deliverd.dev/api/mcp ``` There is no token to paste: the first time it connects, a browser window asks you to choose the organisation and approve access. To connect every AI tool on your machine in one go, run `npx deliverd setup`. Other tools are covered in the [MCP docs](/docs/developers/mcp). Then tell the tool when to ask: ```text Before you deploy, delete anything or send anything outside the team, ask for approval with Deliverd and wait for the answer. ``` #### 5. Look at a finished one An empty account has nothing to show yet. To see what a piece of work looks like once people have been asked and have answered, an administrator can choose **Load a sample project** on the home page. It is a motor claim payout from our claims-triage case study: a decided approval, one waiting on you, a gate that asked a person, an answered question, a review, and the evidence pack for all of it. Everything in it is marked as sample data and left out of analytics, and one button removes it. Open the project, look at the timeline and **Who worked on this project**, and download the evidence pack. That is the record your own agents will be building. #### Where next - [The TypeScript, Python and Rust SDKs](/docs/developers/sdk): reviews, questions, gates and projects. - [The CLI](/docs/developers/cli), for build steps and scripts. - [Approvals](/product/approvals), for what the person on the other end sees. ### One audit trail for Claude, ChatGPT, Cursor and your own agents — https://deliverd.dev/blog/one-audit-trail-for-every-agent 2026-10-25, Deliverd Engineering Team. Most teams run agents from more than one vendor. Here is how a single project in Deliverd collects what each of them asked, who answered, and which tool and model said it was involved, in one record and one evidence pack. A piece of work rarely stays in one tool. Someone drafts the claims summary in ChatGPT, a colleague asks Claude to check it against the policy wording, a developer has Cursor change the export script, and an agent you wrote yourself publishes the result overnight. Each of those tools keeps its own history, in its own format, behind its own sign-in. When somebody asks later who decided to send it, the answer is in four places, and some of it is nowhere. Deliverd keeps the human half of that work in one place: every approval, review and question an agent puts to a person, who answered, what they said, and when. This post is about how that record holds together when the agents come from different vendors. #### One project, joined from anywhere A **project** is the thread that ties one job together. In the API it is called a flow, and every surface can join one: the MCP server, the REST API, the TypeScript, Python and Rust SDKs, the CLI, the GitHub Action, and the n8n, Zapier, Make, Jira and ServiceNow integrations. The simplest way to make several tools land in the same project is your own reference. An agent that starts work creates the project with an `externalId`; any other agent that knows the reference finds it and attaches its requests to it. Over MCP the tools are `create_flow` and `find_flow`. From code: ```ts import { deliverd } from "@deliverd/sdk"; const project = await deliverd.flows.resume({ title: "Q3 claims summary", externalId: "claims-summary-2026-q3", }); const decision = await project.approve({ title: "Send the Q3 claims summary to the board", agent: { name: "Board pack agent", provider: "your own company" }, model: "claude-opus-5", }); ``` `resume` finds the open project with that reference, or starts it, so an agent that restarts does not open a second one. The `agent` and `model` fields arrive in `@deliverd/sdk` 0.27.0; over MCP and the REST API they are there already. #### Which tool asked A request has a credential behind it: a person signed in to the app, an API key, a registered agent, or an AI tool connected over OAuth. Until recently every OAuth connection was written to the record as "OAuth connector", which told you a tool had asked but not which one. The record now uses the name the tool gave when it registered with Deliverd, followed by "(OAuth connector)". When Claude, ChatGPT and Cursor all connect over MCP, the record says which of them made each request, rather than three identical lines. That name is the client's own description of itself. It is useful, and it is what the tool registered with, but it is not a certificate. The same goes for the next part. #### Which agent, and which model One API key is often shared by several agents, and one agent changes model from one month to the next. So a request can also say which agent made it and which model that agent was running on: the `agent` object (a name, a provider and your own id) and `model`. These are **declared, not verified**. Deliverd records them, puts them in the audit event for the request, and shows them on the request page and in the project's timeline, always marked as declared. Nothing decides anything on them. No policy reads them and no routing depends on them, because a field an agent fills in about itself is not something to base a permission on. What they give you is the agent's own account of itself, written down at the time, which is a great deal more than nothing when somebody asks a year later. #### Who worked on this project The project page in the app has a panel called **Who worked on this project**. It lists, from the project's history: - the people who asked or answered, - the API keys and the OAuth connectors that made requests, by name, - the registered agents, - and, separately, the agents and models that requests declared, labelled as declared. It is the question an auditor asks first, answered from what was recorded rather than from memory. #### One evidence pack The whole project exports as one evidence pack in JSON, CSV or PDF. It holds every step (who asked, who was asked, the agent and model the request declared, and what each person said), the tasks and findings recorded under the project, the gates checked, and the timeline of every audited event. In the JSON each step's agent and model sit under `declared`; the PDF prints them "as the request declared, not checked". The pack is signed. Its integrity block carries a sha256 digest, the head of the organisation's hash-chained audit trail at the moment it was taken, and an Ed25519 signature over the digest. [Projects and evidence packs](/docs/guide/flows) shows how to check a pack against the published key. #### What this does not do It does not read the tools' own logs. Deliverd records what an agent asked a person and what the person said; it does not see the prompt history inside ChatGPT or the edits Cursor made to a file. If you need those, keep them, and use the project's `externalId` to tie them to the same piece of work. It also does not make every tool honest about itself. A connector's registered name and a declared model are the tool's word. What Deliverd adds is that the word is written down, next to the person's decision, in a trail that refuses edits and is chained so that a changed entry shows. To try it, connect two tools to the same organisation over [MCP](/docs/developers/mcp), give them the same project reference, and open the project page. [Projects and evidence packs](/docs/guide/flows) has the rest. ## More - Blog: https://deliverd.dev/blog (RSS: https://deliverd.dev/blog/feed.xml) - Overview, the whole product on one page: https://deliverd.dev/overview - Documentation: https://deliverd.dev/docs - Guide, for people and administrators: https://deliverd.dev/docs/guide - Developer docs, every page: - Overview: https://deliverd.dev/docs/developers - Authentication: https://deliverd.dev/docs/developers/authentication - SDKs: https://deliverd.dev/docs/developers/sdk - Approvals, reviews and requests: https://deliverd.dev/docs/developers/approvals - The gate: https://deliverd.dev/docs/developers/gate - Agent policy: https://deliverd.dev/docs/developers/policy - Policy as code: https://deliverd.dev/docs/developers/policy-as-code - Ethics concerns: https://deliverd.dev/docs/developers/ethics - Webhooks and callbacks: https://deliverd.dev/docs/developers/webhooks - In your own product: https://deliverd.dev/docs/developers/in-your-product - MCP server: https://deliverd.dev/docs/developers/mcp - ChatGPT and dots: https://deliverd.dev/docs/developers/openai - Glean: https://deliverd.dev/docs/developers/glean - Gemini Enterprise: https://deliverd.dev/docs/developers/gemini-enterprise - Microsoft Sentinel: https://deliverd.dev/docs/developers/microsoft-sentinel - CLI: https://deliverd.dev/docs/developers/cli - Skills: https://deliverd.dev/docs/developers/skills - Deliverd Screen: https://deliverd.dev/docs/developers/screen - Publishing reports: https://deliverd.dev/docs/developers/publishing - Errors and limits: https://deliverd.dev/docs/developers/errors - Contact: https://deliverd.dev/contact - Tool pages: https://deliverd.dev/claude-code, https://deliverd.dev/codex, https://deliverd.dev/cursor, https://deliverd.dev/chatgpt, https://deliverd.dev/vscode, https://deliverd.dev/windsurf, https://deliverd.dev/gemini-cli