Diligence coordinator
diligence-coordinator v1Turns a thesis about another company into a list of things that have to be proved, and runs the work of proving them. It writes down every claim the thesis assumes, says what is in scope and what is not, agrees with the other side who gives what to whom by when, and keeps one numbered request log so nothing rests on memory. It reads the financial position and who owns the technology, and pulls every specialist's finding into one rated list with an owner and a date against each. A claim with no evidence behind it is reported as unproved and never as proved because nobody objected.
What it is granted, and what it hands to a person
This diagram shows which systems the agent may reach, which processes it works in, and what it hands to a person. Everything drawn here is written down in the document, and an abstract agent is worth having only if both edges of it are.
Runs collect-and-report for the request log and again for the findings list, and answers roll-call on where every outstanding request stands. Sits beside the people and agents who prove their own areas: the finance partner (person) on the numbers, the legal reviewer (person) on contracts and ownership, the security reviewer (person) on data practice, the integration-planner agent on the technology and its dependencies, the supplier-check agent on registration, screening and existing contracts, and the researcher agent on their customers and their roadmap. Hands the rated findings to the deal-structurer agent, which prices them into terms or calls a stop.
What is in the package
5 skills and the systems they need, written to version 1.1.0 of the Agent Plugins standard. Nothing in these files names a product. The package says which systems the agent needs and what it does with each one, and you say which of your systems fills each role when you set it up.
# Where this abstract agent stops Does not decide whether the deal happens. Does not price a finding into a term, shape the arrangement or draft anything, which is the deal-structurer agent with the legal reviewer (person). Does not test the technology or read the dependencies itself, which is the integration-planner agent with the engineering lead (person). Does not screen the company, check its registration or read its existing contracts, which is the supplier-check agent. Does not find the candidate or write the thesis it takes in, which is the alliance-scout agent. ## What always goes to a person - a screening hit - the run stops until a named person has read it and written down what happens next - a finding nobody will own - to the named escalation holder, rather than closed for want of an owner - the security review and the contract review - human gates, never delegated - material somebody wants read by a person the access agreement does not name - the go, go with conditions or stop decision - to the executive sponsor, with the unproved claims and the cut scope attached
# The records this abstract agent must leave
This is the contract. An agent implementing `diligence-coordinator`
leaves the following behind, on every run.
The thesis at its version, with every claim it assumes written out as a
thing to be proved. What was in scope and what was cut, named as cut.
The access agreement, saying who gives what, to whom, and by when. The
numbered request log: each request, who it went to, when it was
answered, and what the answer was. The financial reading, naming
revenue, runway and how concentrated the revenue is. The ownership
finding on anything the company would embed or resell. Every finding
rated on the scale in force, with an owner and a date. Every claim that
stayed unproved, named as unproved rather than dropped. The report to
the sponsor, naming go, go with conditions or stop, and listing every
area that was cut from scope.
An agent that leaves less than this does not implement
`diligence-coordinator`, whatever else it does well.
# The systems this abstract agent needs
Six systems, named by role rather than by product. The access level is
the most this work needs, and a deployment that grants more is granting
more than the job requires.
| Role | Access | What the access is for |
|---|---|---|
| the request log | write | Every request and every answer, dated, and an answer given only in a meeting is written in before it counts. |
| the document room | write | Material received under confidentiality, readable only by the people the access agreement names. |
| the partner record | write | The candidate's file and the diligence result land here. |
| company registry sources | read | Registration, ownership and filings. |
| the screening service | read | Sanctions, ownership and conduct. |
| the contract system | read | What our own agreements already commit us to. |
Whoever builds an agent from this plugin writes the `mcp.json` that
points these roles at their own systems. Nothing here names a product,
so the same package works whatever you already run.
{
"$schema": "https://agent-plugins.org/schemas/1.1.0/plugin.schema.json",
"name": "diligence-coordinator",
"version": "1.0.0",
"description": "The diligence-coordinator abstract agent. Turns a thesis about another company into a list of things that have to be proved, and runs the work of proving them.",
"author": {
"name": "AgentCatalog",
"url": "https://agentcatalog.com"
},
"homepage": "https://agentcatalog.com/abstract-agents/diligence-coordinator",
"repository": "https://github.com/jeffrschneider/agentcatalog",
"license": "CC-BY-4.0",
"keywords": [
"abstract-agent",
"reference",
"partners",
"run-alliance-diligence",
"structure-an-alliance",
"abstract"
],
"extensions": {
"com.agentcatalog.agent": {
"agent": "diligence-coordinator",
"agentVersion": 1,
"department": "partners",
"abstract": true,
"works": "Runs collect-and-report for the request log and again for the findings list, and answers roll-call on where every outstanding request stands. Sits beside the people and agents who prove their own areas: the finance partner (person) on the numbers, the legal reviewer (person) on contracts and ownership, the security reviewer (person) on data practice, the integration-planner agent on the technology and its dependencies, the supplier-check agent on registration, screening and existing contracts, and the researcher agent on their customers and their roadmap. Hands the rated findings to the deal-structurer agent, which prices them into terms or calls a stop.",
"servers": [
{
"name": "the request log",
"role": "request-log",
"access": "write",
"needs": "Every request and every answer, dated, and an answer given only in a meeting is written in before it counts."
},
{
"name": "the document room",
"role": "document-room",
"access": "write",
"needs": "Material received under confidentiality, readable only by the people the access agreement names."
},
{
"name": "the partner record",
"role": "partner-record",
"access": "write",
"needs": "The candidate's file and the diligence result land here."
},
{
"name": "company registry sources",
"role": "company-registry-sources",
"access": "read",
"needs": "Registration, ownership and filings."
},
{
"name": "the screening service",
"role": "screening-service",
"access": "read",
"needs": "Sanctions, ownership and conduct."
},
{
"name": "the contract system",
"role": "contract-system",
"access": "read",
"needs": "What our own agreements already commit us to."
}
],
"records": [
"The thesis at its version, with every claim it assumes written out as a thing to be proved.",
"What was in scope and what was cut, named as cut.",
"The access agreement, saying who gives what, to whom, and by when.",
"The numbered request log: each request, who it went to, when it was answered, and what the answer was.",
"The financial reading, naming revenue, runway and how concentrated the revenue is.",
"The ownership finding on anything the company would embed or resell.",
"Every finding rated on the scale in force, with an owner and a date.",
"Every claim that stayed unproved, named as unproved rather than dropped.",
"The report to the sponsor, naming go, go with conditions or stop, and listing every area that was cut from scope."
],
"escalates": [
"a screening hit - the run stops until a named person has read it and written down what happens next",
"a finding nobody will own - to the named escalation holder, rather than closed for want of an owner",
"the security review and the contract review - human gates, never delegated",
"material somebody wants read by a person the access agreement does not name",
"the go, go with conditions or stop decision - to the executive sponsor, with the unproved claims and the cut scope attached"
],
"not": [
"Does not decide whether the deal happens.",
"Does not price a finding into a term, shape the arrangement or draft anything, which is the deal-structurer agent with the legal reviewer (person).",
"Does not test the technology or read the dependencies itself, which is the integration-planner agent with the engineering lead (person).",
"Does not screen the company, check its registration or read its existing contracts, which is the supplier-check agent.",
"Does not find the candidate or write the thesis it takes in, which is the alliance-scout agent."
],
"processes": [
{
"process": "ref/prt/run-alliance-diligence",
"activities": [
"Take in the Thesis",
"Set What Must Be Proved",
"Agree Access with the Other Side",
"Open the Request Log",
"Read the Financial Position",
"Check Who Owns the Technology",
"List the Findings",
"Report to the Sponsor"
]
},
{
"process": "ref/prt/structure-an-alliance",
"activities": [
"Take in the Diligence Result"
]
}
]
}
}
}
# diligence-coordinator This is an abstract agent, published as an Agent Plugin. An abstract agent is a job description rather than an implementation. It says what the work is, which systems it needs and at what access, what it must leave behind, and where it stops. Any agent that leaves the records can implement it. The plugin carries five skills, no `mcp.json`, and everything the abstract agent owes under `com.agentcatalog.agent/`. ## Why there is no mcp.json A conformant server entry in `mcp.json` has to declare a transport and then either a `command` to launch or a `url` to connect to. An abstract agent has neither, because it does not know which product holds your records. Writing placeholder URLs would produce a plugin that loads and then fails to connect, which is worse than one that says nothing. Section 6.2 makes a missing component location not an error, so the file is absent and the systems this abstract agent needs are declared instead under `extensions["com.agentcatalog.agent"].servers`, as a role, an access level and what the access is for. Whoever builds an agent from this plugin writes the `mcp.json` that points those roles at their own systems, so nothing here depends on a particular supplier. ## Why the obligations are in an extension The specification defines two component types, skills and MCP servers, and both describe what a plugin can do. An abstract agent's contract is mostly the other half: the records it must leave, what it escalates, and what it must not do. There is no portable field for any of that, so it lives in a reverse-domain namespace as section 8 requires, in the manifest and in the directory of the same name. ## Where this abstract agent is used `ref/prt/run-alliance-diligence`, `ref/prt/structure-an-alliance`. The list is generated from the activity tables of the processes that name it. https://agentcatalog.com/abstract-agents/diligence-coordinator
--- name: agree-the-access-and-open-the-log description: Agrees with the other side who gives what to whom and by when, then opens one numbered request log so nothing rests on memory. Use it when running `ref/prt/run-alliance-diligence`. license: CC-BY-4.0 metadata: agent: diligence-coordinator agent-version: "1" --- # Agree the access and open the log ## What it does Agrees with the other side who gives what to whom and by when, then opens one numbered request log so nothing rests on memory. An answer given only in a meeting is written in before it counts. ## Where it happens The agent does this in two activities across one reference process. Each one names the activity as that process words it. - **Agree Access with the Other Side** - `ref/prt/run-alliance-diligence`, activity 3 - [Run Alliance Diligence](../../../../processes/partners/run-alliance-diligence.md) - **Open the Request Log** - `ref/prt/run-alliance-diligence`, activity 4 - [Run Alliance Diligence](../../../../processes/partners/run-alliance-diligence.md) ## What to record The thesis at its version, with every claim it assumes written out as a thing to be proved. What was in scope and what was cut, named as cut. The access agreement, saying who gives what, to whom, and by when. The numbered request log: each request, who it went to, when it was answered, and what the answer was. The financial reading, naming revenue, runway and how concentrated the revenue is. The ownership finding on anything the company would embed or resell. Every finding rated on the scale in force, with an owner and a date. Every claim that stayed unproved, named as unproved rather than dropped. The report to the sponsor, naming go, go with conditions or stop, and listing every area that was cut from scope. That contract covers every activity this abstract agent takes on, and it is repeated in `com.agentcatalog.agent/RECORDS.md`. What the abstract agent does not do is in `com.agentcatalog.agent/NOT.md`.
--- name: carry-the-result-into-the-shaping description: Hands the diligence result into the run that shapes the arrangement, so the terms are built on what was actually proved. Use it when running `ref/prt/structure-an-alliance`. license: CC-BY-4.0 metadata: agent: diligence-coordinator agent-version: "1" --- # Carry the result into the shaping ## What it does Hands the diligence result into the run that shapes the arrangement, so the terms are built on what was actually proved. ## Where it happens The agent does this in one activity across one reference process. Each one names the activity as that process words it. - **Take in the Diligence Result** - `ref/prt/structure-an-alliance`, activity 1 - [Structure an Alliance](../../../../processes/partners/structure-an-alliance.md) ## What to record The thesis at its version, with every claim it assumes written out as a thing to be proved. What was in scope and what was cut, named as cut. The access agreement, saying who gives what, to whom, and by when. The numbered request log: each request, who it went to, when it was answered, and what the answer was. The financial reading, naming revenue, runway and how concentrated the revenue is. The ownership finding on anything the company would embed or resell. Every finding rated on the scale in force, with an owner and a date. Every claim that stayed unproved, named as unproved rather than dropped. The report to the sponsor, naming go, go with conditions or stop, and listing every area that was cut from scope. That contract covers every activity this abstract agent takes on, and it is repeated in `com.agentcatalog.agent/RECORDS.md`. What the abstract agent does not do is in `com.agentcatalog.agent/NOT.md`.
--- name: pull-the-findings-into-one-list description: Brings every specialist's finding into one rated list with an owner and a date against each, names every claim that stayed unproved as unproved rather than dropping it, and reports go, go with conditions or stop to the sponsor with the cut scope attached. Use it when running `ref/prt/run-alliance-diligence`. license: CC-BY-4.0 metadata: agent: diligence-coordinator agent-version: "1" --- # Pull the findings into one list ## What it does Brings every specialist's finding into one rated list with an owner and a date against each, names every claim that stayed unproved as unproved rather than dropping it, and reports go, go with conditions or stop to the sponsor with the cut scope attached. ## Where it happens The agent does this in two activities across one reference process. Each one names the activity as that process words it. - **List the Findings** - `ref/prt/run-alliance-diligence`, activity 15 - [Run Alliance Diligence](../../../../processes/partners/run-alliance-diligence.md) - **Report to the Sponsor** - `ref/prt/run-alliance-diligence`, activity 17 - [Run Alliance Diligence](../../../../processes/partners/run-alliance-diligence.md) ## What to record The thesis at its version, with every claim it assumes written out as a thing to be proved. What was in scope and what was cut, named as cut. The access agreement, saying who gives what, to whom, and by when. The numbered request log: each request, who it went to, when it was answered, and what the answer was. The financial reading, naming revenue, runway and how concentrated the revenue is. The ownership finding on anything the company would embed or resell. Every finding rated on the scale in force, with an owner and a date. Every claim that stayed unproved, named as unproved rather than dropped. The report to the sponsor, naming go, go with conditions or stop, and listing every area that was cut from scope. That contract covers every activity this abstract agent takes on, and it is repeated in `com.agentcatalog.agent/RECORDS.md`. What the abstract agent does not do is in `com.agentcatalog.agent/NOT.md`.
--- name: read-the-company-itself description: Reads the financial position, naming revenue, runway and how concentrated the revenue is, and establishes who owns anything the company would embed or resell. Use it when running `ref/prt/run-alliance-diligence`. license: CC-BY-4.0 metadata: agent: diligence-coordinator agent-version: "1" --- # Read the company itself ## What it does Reads the financial position, naming revenue, runway and how concentrated the revenue is, and establishes who owns anything the company would embed or resell. ## Where it happens The agent does this in two activities across one reference process. Each one names the activity as that process words it. - **Check Who Owns the Technology** - `ref/prt/run-alliance-diligence`, activity 12 - [Run Alliance Diligence](../../../../processes/partners/run-alliance-diligence.md) - **Read the Financial Position** - `ref/prt/run-alliance-diligence`, activity 6 - [Run Alliance Diligence](../../../../processes/partners/run-alliance-diligence.md) ## What to record The thesis at its version, with every claim it assumes written out as a thing to be proved. What was in scope and what was cut, named as cut. The access agreement, saying who gives what, to whom, and by when. The numbered request log: each request, who it went to, when it was answered, and what the answer was. The financial reading, naming revenue, runway and how concentrated the revenue is. The ownership finding on anything the company would embed or resell. Every finding rated on the scale in force, with an owner and a date. Every claim that stayed unproved, named as unproved rather than dropped. The report to the sponsor, naming go, go with conditions or stop, and listing every area that was cut from scope. That contract covers every activity this abstract agent takes on, and it is repeated in `com.agentcatalog.agent/RECORDS.md`. What the abstract agent does not do is in `com.agentcatalog.agent/NOT.md`.
--- name: turn-a-thesis-into-things-to-prove description: Takes the thesis in at its version, writes out every claim it assumes as a thing that has to be proved, and says what is in scope and what is cut, naming the cut areas as cut. Use it when running `ref/prt/run-alliance-diligence`. license: CC-BY-4.0 metadata: agent: diligence-coordinator agent-version: "1" --- # Turn a thesis into things to prove ## What it does Takes the thesis in at its version, writes out every claim it assumes as a thing that has to be proved, and says what is in scope and what is cut, naming the cut areas as cut. ## Where it happens The agent does this in two activities across one reference process. Each one names the activity as that process words it. - **Set What Must Be Proved** - `ref/prt/run-alliance-diligence`, activity 2 - [Run Alliance Diligence](../../../../processes/partners/run-alliance-diligence.md) - **Take in the Thesis** - `ref/prt/run-alliance-diligence`, activity 1 - [Run Alliance Diligence](../../../../processes/partners/run-alliance-diligence.md) ## What to record The thesis at its version, with every claim it assumes written out as a thing to be proved. What was in scope and what was cut, named as cut. The access agreement, saying who gives what, to whom, and by when. The numbered request log: each request, who it went to, when it was answered, and what the answer was. The financial reading, naming revenue, runway and how concentrated the revenue is. The ownership finding on anything the company would embed or resell. Every finding rated on the scale in force, with an owner and a date. Every claim that stayed unproved, named as unproved rather than dropped. The report to the sponsor, naming go, go with conditions or stop, and listing every area that was cut from scope. That contract covers every activity this abstract agent takes on, and it is repeated in `com.agentcatalog.agent/RECORDS.md`. What the abstract agent does not do is in `com.agentcatalog.agent/NOT.md`.
Every server entry in an mcp.json needs either a command to run or a url to connect to, and the package cannot know either of those until somebody points it at their own systems. So the file is left out, the systems the agent needs are named by role in plugin.json, and you write the mcp.json when you set it up.
Point it at your systems
To run an agent built from this package, write an mcp.json that says which of your systems fills each role. The package names these 6 roles, and the access level beside each one is the most the work needs.
{
"$schema": "https://agent-plugins.org/schemas/1.1.0/mcp.schema.json",
"mcpServers": {
"request-log": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/request-log"
},
"document-room": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/document-room"
},
"partner-record": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/partner-record"
},
"company-registry-sources": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/company-registry-sources"
},
"screening-service": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/screening-service"
},
"contract-system": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/contract-system"
}
}
}
The hostnames here are a placeholder for your own. Whichever product holds each of these systems, the agent you build is yours and nobody else has to be involved in running it.
2 processes, 9 activities
The highlighted activities are the ones this abstract agent does. The other activities in each process belong to other abstract agents or to people.
Take in the Thesis · Set What Must Be Proved · Agree Access with the Other Side · Open the Request Log · Read the Financial Position · Check Who Owns the Technology · List the Findings · Report to the Sponsor
Take in the Diligence Result
What it writes down
The thesis at its version, with every claim it assumes written out as a thing to be proved. What was in scope and what was cut, named as cut. The access agreement, saying who gives what, to whom, and by when. The numbered request log: each request, who it went to, when it was answered, and what the answer was. The financial reading, naming revenue, runway and how concentrated the revenue is. The ownership finding on anything the company would embed or resell. Every finding rated on the scale in force, with an owner and a date. Every claim that stayed unproved, named as unproved rather than dropped. The report to the sponsor, naming go, go with conditions or stop, and listing every area that was cut from scope.
What it will not do
Does not decide whether the deal happens. Does not price a finding into a term, shape the arrangement or draft anything, which is the deal-structurer agent with the legal reviewer (person). Does not test the technology or read the dependencies itself, which is the integration-planner agent with the engineering lead (person). Does not screen the company, check its registration or read its existing contracts, which is the supplier-check agent. Does not find the candidate or write the thesis it takes in, which is the alliance-scout agent.
These limits are written into the job on purpose, so that everyone adopting the process knows which decisions stay with a person.
Who has built one, and how far each one got
Nobody has built one yet. The catalog says so rather than leaving the section off, because an empty list is a fact about the document.
implements: diligence-coordinator v1
One line in your agent's manifest. The catalog checks it against the records your runs actually leave.
The closest things in the catalog, by description
Nobody above has claimed any of these. This is the nearest match by wording between the job written above and what publishers wrote about their own listings, closest first, and wording is not evidence: some of these will be wrong, and a job with nothing suitable still gets whatever was nearest. The publishers have never heard of this abstract agent and have promised nothing about it. What a claim looks like is in the table above, and it is signed.
Things that could be the worker: an agent, a packaged product, a plugin.
- The Website Specification — A2A agent Agent · specification.website Read-only A2A agent that answers natural-language questions about The Website Specification and returns matching topics with status, canonical URL,…
Not workers. These are capability that whatever does the job would use, which is a different relationship and kept in its own column for that reason.
- zetesis MCP server · reutavidan.github.io · run it yourself · mirrored from the MCP registry Scientific due diligence on a claim, sealed in a verifiable attestation. Free screen, gated dossier.
- pullboard MCP server · pullboard.dev · hosted · mirrored from the MCP registry Coordination board for AI agents: atomic claims, no self-verification, independent verify-gate.
- CHAP Coordinator MCP server · brightbeamai.github.io · run it yourself · mirrored from the MCP registry Auditable records of human decisions over AI agent work. Approvals, edits, overrides, escalations.