# 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, and Deliverd handles the rest: the page the person answers on, the notifications, who is allowed to answer, and the record. The result comes back so the agent can continue. It works with any agent or tool over MCP, the REST API, the TypeScript and Python SDKs and the CLI; it can check an agent's action against policy, or ask a person, before the agent acts, keep each job's objective and state, publish what the agent made behind your own sign-in, and keep the evidence of who decided what.

## Asking a person

When something needs a human — permission for a consequential action, a fact
you are missing, work that should be read before it goes anywhere — do not
guess and do not stop. Make the request and poll it. A person answers on a
page that works on a phone, signed in through their own organisation, and
every step is audited. None of these needs a report to exist first.

The whole integration, in the TypeScript SDK (the Python one reads the same):

    import { deliverd } from "@deliverd/sdk";

    const decision = await deliverd.approve({
      title: "Deploy to production"
    });

    if (decision.approved) await deploy();

Over MCP the same ask is request_approval, then get_approval until it is
decided; over REST it is POST https://deliverd.dev/api/v1/approvals, then GET
https://deliverd.dev/api/v1/approvals/{id}. Every request below has the same three shapes.

- Collect: Typed questions to named people, with reminders and a due date. (request_information, get_collection)
- Review: Named readers approve the work or ask for changes, with a note. (request_review, get_review)
- Approve: Authorisation before a consequential act, decided by a person. (request_approval, get_approval, answer_approval_question)
- Publish: The finished thing, on a secure versioned address. (publish_report, update_report)
- Evidence: Every step of the job as one timeline an auditor can read. (get_evidence)
- Flows: The thread tying one job's requests together. (create_flow, get_flow)
- Agent policy: What each agent may ask for, and what must happen first. (not callable by an agent)

Before a consequential action you can ask whether to proceed at all, rather
than asking a named person: declare the action and the arguments and the
organisation's policy answers allow, deny, or a person decides (check_gate, get_gate),
and its ethics rules can still send an allowed action to a person or refuse it
(see Ethics below). Branch on allowed — that one boolean is the whole integration, and a refusal
is an answer rather than an error. An action no rule covers goes to a person,
so nothing is permitted by nobody having thought about it. 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. The
decision is advisory — you report what you intend and then act — and it is
recorded either way.

The rules are not yours to write, and neither are the actions they are written
against: registering an action and authoring policy both refuse an agent key,
and authoring also needs an owner or an administrator. So a deny is not
something to retry, work around, or fix by registering a different action —
it is an answer, and the way past it is a person. An action nobody registered
is refused before any rule is read, so if that is what you meet, say so rather
than trying variations of the name.

An agent may not approve its own request and may not decide anything. See
https://deliverd.dev/product/approvals.

Without MCP, the SDKs make the same requests and wait for the answer:
TypeScript (npm install @deliverd/sdk) and Python (pip install deliverd).
Rather than polling, a request can name its own callbackUrl: an HTTPS address
that is POSTed the answer, signed with a secret returned once when the request
is made. See https://deliverd.dev/docs/developers/sdk and https://deliverd.dev/docs/developers/webhooks.

## 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.
- 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)

Tasks are included in Team, 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.

## Connect an agent

The MCP server is at https://deliverd.dev/api/mcp (Streamable HTTP). Authentication is OAuth 2.1 with PKCE and dynamic client registration: a client registers itself and a person approves it in a browser. No token is pasted.

- Claude Code: claude mcp add --transport http deliverd https://deliverd.dev/api/mcp
- Codex: codex mcp add deliverd --url https://deliverd.dev/api/mcp, then codex mcp login deliverd
- Gemini CLI: gemini mcp add --transport http deliverd https://deliverd.dev/api/mcp
- Cursor, VS Code, Windsurf, ChatGPT, Claude desktop and web: https://deliverd.dev/connect
- Microsoft 365 Copilot, Copilot Studio, Foundry and Agent Framework: https://deliverd.dev/microsoft
- Inside your own product (a hosted or embedded decision for one approver, and an approver's inbox): https://deliverd.dev/docs/developers/in-your-product
- Any tool the installer knows: npx deliverd setup --url https://deliverd.dev
- 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 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
- Claude Code plugin (the MCP server and all 4 skills): claude plugin marketplace add deliverd-dev/deliverd-skills
- Built on Jev, TypeSafe's decision model: connect the client you run the agent in, above. Jev has no install path here and never connects to us — your agent calls Jev, and a verdict that comes back escalate: true is what you bring here, as one of the requests in "Asking a person".

## 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.
- 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 retire it.
- list_ai_systems: The organisation's register of AI systems.
- get_ai_system: One AI system's register entry 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.
- record_model_change: Record a new provider, model or version for an AI system; every governed task using it is reassessed.
- 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.
- 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.

## Ethics

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 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.

## Publishing

When an agent has made something people need to read, publish_report puts the HTML on a secure versioned URL behind the reader's own sign-in, with comments the agent can read, live datasets, schedules, a PDF from the link, and a portal at https://deliverd.dev/product/publishing. Publishing is one of the tools here; nothing above needs it.

## Publishing without MCP

- REST API: https://deliverd.dev/api/v1 — OpenAPI at https://deliverd.dev/api/v1/openapi.json, reference at https://deliverd.dev/docs/api
- CLI: npx deliverd publish ./report --audience "Finance team"
- A token from Settings → API tokens is needed for both; MCP clients need none.

## When a call is refused

Every refusal is a JSON body shaped {"error": {"code": "...", "message":
"..."}} alongside an HTTP status. Branch on the code: the message is written
for a person to read and will be reworded. Four are worth knowing before you
write 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.

## Pages

- [claude-code](https://deliverd.dev/claude-code)
- [codex](https://deliverd.dev/codex)
- [cursor](https://deliverd.dev/cursor)
- [chatgpt](https://deliverd.dev/chatgpt)
- [vscode](https://deliverd.dev/vscode)
- [windsurf](https://deliverd.dev/windsurf)
- [gemini-cli](https://deliverd.dev/gemini-cli)
- [for consultancies](https://deliverd.dev/for/consultancies)
- [for accountancy](https://deliverd.dev/for/accountancy)
- [for research](https://deliverd.dev/for/research)
- [for insurance](https://deliverd.dev/for/insurance)
- [for financial-services](https://deliverd.dev/for/financial-services)
- [for ai-engineering](https://deliverd.dev/for/ai-engineering)
- [vs build-it-yourself](https://deliverd.dev/vs/build-it-yourself)
- [vs slack-teams-buttons](https://deliverd.dev/vs/slack-teams-buttons)
- [vs workflow-tools](https://deliverd.dev/vs/workflow-tools)
- [vs framework-pauses](https://deliverd.dev/vs/framework-pauses)
- [vs claude-artifacts](https://deliverd.dev/vs/claude-artifacts)
- [vs static-hosting](https://deliverd.dev/vs/static-hosting)
- [vs v0](https://deliverd.dev/vs/v0)
- [vs lovable](https://deliverd.dev/vs/lovable)
- [vs bolt](https://deliverd.dev/vs/bolt)
- [vs netlify-drop](https://deliverd.dev/vs/netlify-drop)
- [vs vercel](https://deliverd.dev/vs/vercel)
- [overview](https://deliverd.dev/overview)
- [quickstart](https://deliverd.dev/quickstart)
- [approvals, reviews and requests](https://deliverd.dev/product/approvals)
- [gates and evidence](https://deliverd.dev/product/gates)
- [tasks](https://deliverd.dev/product/tasks)
- [publishing](https://deliverd.dev/product/publishing)
- [compliance mode](https://deliverd.dev/product/compliance)
- [enterprise](https://deliverd.dev/enterprise)
- [microsoft 365 copilot, copilot studio and foundry](https://deliverd.dev/microsoft)
- [partners](https://deliverd.dev/partners)
- [guide: human-approval-for-ai-agents](https://deliverd.dev/guides/human-approval-for-ai-agents)
- [guide: ai-decision-audit-trail](https://deliverd.dev/guides/ai-decision-audit-trail)
- [case study: credit-decisioning](https://deliverd.dev/case-studies/credit-decisioning)
- [case study: claims-triage](https://deliverd.dev/case-studies/claims-triage)
- [documentation](https://deliverd.dev/docs)
- [guide for people and administrators](https://deliverd.dev/docs/guide)
- [developers: Overview](https://deliverd.dev/docs/developers)
- [developers: Authentication](https://deliverd.dev/docs/developers/authentication)
- [developers: SDKs](https://deliverd.dev/docs/developers/sdk)
- [developers: Approvals, reviews and requests](https://deliverd.dev/docs/developers/approvals)
- [developers: The gate](https://deliverd.dev/docs/developers/gate)
- [developers: Agent policy](https://deliverd.dev/docs/developers/policy)
- [developers: Ethics concerns](https://deliverd.dev/docs/developers/ethics)
- [developers: Webhooks and callbacks](https://deliverd.dev/docs/developers/webhooks)
- [developers: In your own product](https://deliverd.dev/docs/developers/in-your-product)
- [developers: MCP server](https://deliverd.dev/docs/developers/mcp)
- [developers: ChatGPT and dots](https://deliverd.dev/docs/developers/openai)
- [developers: CLI](https://deliverd.dev/docs/developers/cli)
- [developers: Skills](https://deliverd.dev/docs/developers/skills)
- [developers: Publishing reports](https://deliverd.dev/docs/developers/publishing)
- [developers: Errors and limits](https://deliverd.dev/docs/developers/errors)
- [pricing](https://deliverd.dev/pricing)
- [blog](https://deliverd.dev/blog)
- [API reference](https://deliverd.dev/docs/api)
- [security and trust](https://deliverd.dev/security)
- [security](https://deliverd.dev/legal/security)
- [privacy](https://deliverd.dev/legal/privacy)
- [terms](https://deliverd.dev/legal/terms)
- [contact](https://deliverd.dev/contact)

## Writing

The newest first. Every post: https://deliverd.dev/blog (RSS: https://deliverd.dev/blog/feed.xml)

- [Not high-risk, still accountable: an AI that routes motor claims, end to end](https://deliverd.dev/blog/ai-claims-triage-case-study) (2026-10-15): A worked example at a fictional EU insurer: an AI assistant that takes first notice of motor claims and routes them. Outside the AI Act's high-risk list, it still owes 24 controls. The insurer's own EIOPA framework, the injuries an eval missed, a policy that says what the AI may do, and a DORA incident.
- [Inside the limit, and still not shipped: an AI credit assistant, end to end](https://deliverd.dev/blog/ai-credit-decisioning-case-study) (2026-10-14): A worked example at a fictional EU bank: an AI assistant that recommends loan decisions, followed from the register through evals, a red team, approvals and a model update to the evidence pack. Why credit work owes so much, and the two moments a release was held back.
- [Your eval tool measures it. A person decides what passes.](https://deliverd.dev/blog/eval-scores-as-release-evidence) (2026-10-14): Deliverd now reads release evidence from Langfuse, LangSmith, Braintrust and W&B Weave. The scores stay in your eval tool, an agent never holds its key, and a person sets the bar the release has to clear. Why we built it that way.
- [W&B Weave evaluations as release evidence](https://deliverd.dev/blog/weave-evaluations-as-release-evidence) (2026-10-14): Connect your W&B project once, and a build step can name a Weave evaluation and have every score it returned recorded as evidence, with each failed case linked. Read with your organisation's W&B key, never a case's inputs or outputs, and a person sets the bar.
- [Braintrust experiments as release evidence](https://deliverd.dev/blog/braintrust-experiments-as-release-evidence) (2026-10-14): Connect a Braintrust project once, and a build step can name an experiment and have its scores recorded as evidence, mapped exactly as a braintrust eval --jsonl report is, so one threshold meets either. Read with your organisation's key and never a case's inputs or outputs.
- [LangSmith experiments as release evidence](https://deliverd.dev/blog/langsmith-experiments-as-release-evidence) (2026-10-14): Connect LangSmith once, and a build step can name an experiment, or the prefix it gave evaluate(), and have every evaluator's score recorded as evidence. Read with your organisation's key, in the workspace you connected, and never a run's inputs or outputs.
- [Langfuse experiments as release evidence](https://deliverd.dev/blog/langfuse-experiments-as-release-evidence) (2026-10-14): Connect your Langfuse project once, and a build step can name an experiment and have its scores recorded as evidence on a governed task. Deliverd reads it with your organisation's keys, never an item's inputs or outputs, and a person sets the bar.
- [Video in reports](https://deliverd.dev/blog/video-in-reports) (2026-10-12): AI tools now make videos as well as pages. A report can now carry one too: it streams and seeks in the browser's own player, a video on its own gets a page written for it, and subtitles come with it. On Team, Business and Enterprise.
- [Put the article your AI wrote on your own website](https://deliverd.dev/blog/ai-article-on-your-site) (2026-10-12): Ask your AI to write and publish an article, make it public yourself, and paste one iframe into your site. Updates keep the same address, and an agent can never make anything public. Plus an early-access switch for search indexing.
- [Your AI already knows how to do the work. Deliverd makes sure it's allowed to.](https://deliverd.dev/blog/allowed-to-act) (2026-10-12): Your agents can already find the record and call the API. What they cannot know is whether they are allowed to. One real workflow, start to finish: check policy, get approval, record evidence, and then your own system does the work.
- [The model does the work. The authority sits outside it.](https://deliverd.dev/blog/authority-sits-outside-the-model) (2026-10-11): Satya Nadella argues that frontier models should be governed like insiders, with identity, least privilege, a record and a brake, all kept outside the model. That is what Deliverd is built for. His principles one by one: what ships today, and what is not ours to solve.
- [What a receipt can prove](https://deliverd.dev/blog/what-a-receipt-can-prove) (2026-10-06): When an agent reports what it did, Deliverd checks it against what was approved. Three levels of receipt, the boundary we cannot see past, and why the evidence pack says what it does not prove.
- [Complex infrastructure. Simple interface.](https://deliverd.dev/blog/complex-infrastructure-simple-interface) (2026-10-06): Deliverd has a new look. One obvious action per screen, one word per status, a serif used sparingly, two colours we changed after measuring them, and a composer that does exactly what it says.
- [Only the apps you recognise](https://deliverd.dev/blog/only-recognised-apps-can-connect) (2026-10-06): A security researcher showed us how a client named "Claude" could ask for access on our real consent screen. What a client cannot fake, what the consent screen now leads with, and a setting that refuses everything else.
- [Jev decides the routine call. A person decides the rest.](https://deliverd.dev/blog/jev-decides-the-routine-call) (2026-09-28): Jev, from TypeSafe, settles the routine call in about a second. What it cannot settle comes back as an escalation with nowhere to go. Deliverd supports Jev: that branch becomes a person, on a page, under your policy.
- [Some requests deserve a second thought](https://deliverd.dev/blog/some-requests-deserve-a-second-thought) (2026-09-28): Most requests an agent sends are routine. A few look routine and are not. Deliverd's ethics rules put the right question in front of whoever decides — and never approve anything themselves.
- [Your agent can act. It still has to ask.](https://deliverd.dev/blog/ask-before-you-act) (2026-09-18): An agent that is not given a way to ask will decide for itself — and will decide in whatever way finishes the task. What OpenAI's misalignment reports actually show, and what to do about it.
- [Running agents against Deliverd](https://deliverd.dev/blog/running-agents-against-deliverd) (2026-09-12): A technical walk through the agent surface: two kinds of principal, what an agent identity can and cannot do, the tools in the order a working loop calls them, how policies hold an agent's publish for approval, and how to run one from CI. With the JSON.
- [From a comment to a version, without the retyping](https://deliverd.dev/blog/from-a-comment-to-a-version) (2026-09-12): How the new feedback loop is built: why images on a comment are served through the report's access check rather than a bucket URL, how a snapshot is taken as the member who asked for it, what goes into a revision brief and why it is recorded, and the three things that are still rough.
- [Say it on the page](https://deliverd.dev/blog/say-it-on-the-page) (2026-09-12): Feedback on a report used to be an email with a screenshot in it. Now a reader selects the passage, adds a picture of what they see, and the conversation stays attached to the report — and when you are ready, one button turns everything that is open into the next version.

## Optional

- [Everything above in full, one document](https://deliverd.dev/llms-full.txt)