One audit trail for Claude, ChatGPT, Cursor and your own agents

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:

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 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, give them the same project reference, and open the project page. Projects and evidence packs has the rest.