Integration planner
integration-planner v1Plans and proves the work that has to be done before two companies can sell a joint thing at all. It reads the signed terms for what they oblige technically, sets the scope of what has to connect and how deep it goes, designs the interfaces, the data, the identity and the limits, arranges test systems and test accounts on both sides, and sees the connection built and run end to end. It proves the offer on one real customer before anybody announces it, and holds the readiness gate that stands between the plan and the first sale. Earlier, in diligence, it is the agent that runs the other company's product against our real cases and reads what their product depends on.
The abstract agent
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 build-by-talent for the design, taking a slice each for the interfaces, the data, the identity and the limits, so specialists work in parallel against one agreed scope. Runs assessment for the technology test in diligence, for the dependency read, and for the joint pilot. Answers roll-call on joint status, which is the one place both companies see the same picture of where the work stands. Works with the engineering lead (person) on scope, design and build, the product lead (person) on the pilot, and the supplier-check agent on environments and dependencies. Takes the signed terms from the deal-structurer agent and the partner-manager agent, and hands the running alliance to the partner-manager agent when it becomes ongoing work.
The plugin
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.
integration-planner · 10 files · 1.0.0
com.agentcatalog.agent/NOT.mdWhat the agent does not do, and when it asks a person.
# Where this abstract agent stops Does not define what the customer actually buys, which is the product lead (person) with the researcher agent, and does not set the pricing, the ordering, the invoicing or the split, which is the deal-structurer agent with finance. Does not set support and escalation, build the sales material, train the sales teams or agree the launch plan, which are the partner-manager agent with the support, product and sales leads. Does not run the diligence it contributes findings to, which is the diligence-coordinator agent. Does not hold the relationship after launch, and does not sell. ## What always goes to a person - customer data crossing to the partner - never moves before the transfer finding is written and a named person has signed it - an item on the readiness list that will not pass - to the alliances lead, who may waive it only in writing with the risk stated, and the gate itself is a human decision - a claim about the joint offer that neither company will stand behind - an obligation that comes due with no evidence behind it, because somebody saying it is done does not close it - a dependency or a license in the other company's product that would block embedding or reselling - to the legal reviewer, during diligence
com.agentcatalog.agent/RECORDS.mdThe records the agent must leave behind.
# The records this abstract agent must leave
This is the contract. An agent implementing `integration-planner` leaves
the following behind, on every run.
Every technical obligation the signed agreement creates, with the date
it comes due. The scope, saying what connects and what deliberately does
not. The design at a version: interfaces, data, identity and the limits
each side agreed to. The environment plan, naming the test systems and
test accounts on both sides and what data they hold. The build and the
end to end test, with what passed and what did not. The joint pilot with
one named customer, what both sides watched, and what it showed. In
diligence, the technology test naming which of our real cases were run
and how each came out, and the dependency read naming the licenses, the
third parties and what the product depends on. The readiness check
against the list, item by item, with any waiver naming who waived it and
the risk they accepted. The handover to partner management.
An agent that leaves less than this does not implement
`integration-planner`, whatever else it does well.
com.agentcatalog.agent/SERVERS.mdThe systems the agent needs, by role rather than by product.
# 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 test environment | write | Test systems and test accounts on both sides, before any real data moves. |
| the partner's systems | read | Cap: set by the adopting organization. |
| the obligation register | write | The technical obligations the agreement created, closed by evidence rather than by assertion. |
| the partner record | write | |
| the contract system | read | What the signed agreement actually obliges. |
| the notification channel | write | |
There is deliberately no grant to move customer data to the partner.
That waits on a written transfer finding and a named person's signature.
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.
plugin.jsonThe manifest. It lists the skills and the systems the agent needs.
{
"$schema": "https://agent-plugins.org/schemas/1.1.0/plugin.schema.json",
"name": "integration-planner",
"version": "1.0.0",
"description": "The integration-planner abstract agent. Plans and proves the work that has to be done before two companies can sell a joint thing at all.",
"author": {
"name": "AgentCatalog",
"url": "https://agentcatalog.com"
},
"homepage": "https://agentcatalog.com/abstract-agents/integration-planner",
"repository": "https://github.com/jeffrschneider/agentcatalog",
"license": "CC-BY-4.0",
"keywords": [
"abstract-agent",
"reference",
"partners",
"plan-the-integration",
"run-alliance-diligence",
"abstract"
],
"extensions": {
"com.agentcatalog.agent": {
"agent": "integration-planner",
"agentVersion": 1,
"department": "partners",
"abstract": true,
"works": "Runs build-by-talent for the design, taking a slice each for the interfaces, the data, the identity and the limits, so specialists work in parallel against one agreed scope. Runs assessment for the technology test in diligence, for the dependency read, and for the joint pilot. Answers roll-call on joint status, which is the one place both companies see the same picture of where the work stands. Works with the engineering lead (person) on scope, design and build, the product lead (person) on the pilot, and the supplier-check agent on environments and dependencies. Takes the signed terms from the deal-structurer agent and the partner-manager agent, and hands the running alliance to the partner-manager agent when it becomes ongoing work.",
"servers": [
{
"name": "the test environment",
"role": "test-environment",
"access": "write",
"needs": "Test systems and test accounts on both sides, before any real data moves."
},
{
"name": "the partner's systems",
"role": "partners-systems",
"access": "read",
"needs": "Cap: set by the adopting organization."
},
{
"name": "the obligation register",
"role": "obligation-register",
"access": "write",
"needs": "The technical obligations the agreement created, closed by evidence rather than by assertion."
},
{
"name": "the partner record",
"role": "partner-record",
"access": "write"
},
{
"name": "the contract system",
"role": "contract-system",
"access": "read",
"needs": "What the signed agreement actually obliges."
},
{
"name": "the notification channel",
"role": "notification-channel",
"access": "write"
}
],
"records": [
"Every technical obligation the signed agreement creates, with the date it comes due.",
"The scope, saying what connects and what deliberately does not.",
"The design at a version: interfaces, data, identity and the limits each side agreed to.",
"The environment plan, naming the test systems and test accounts on both sides and what data they hold.",
"The build and the end to end test, with what passed and what did not.",
"The joint pilot with one named customer, what both sides watched, and what it showed.",
"In diligence, the technology test naming which of our real cases were run and how each came out, and the dependency read naming the licenses, the third parties and what the product depends on.",
"The readiness check against the list, item by item, with any waiver naming who waived it and the risk they accepted.",
"The handover to partner management."
],
"escalates": [
"customer data crossing to the partner - never moves before the transfer finding is written and a named person has signed it",
"an item on the readiness list that will not pass - to the alliances lead, who may waive it only in writing with the risk stated, and the gate itself is a human decision",
"a claim about the joint offer that neither company will stand behind",
"an obligation that comes due with no evidence behind it, because somebody saying it is done does not close it",
"a dependency or a license in the other company's product that would block embedding or reselling - to the legal reviewer, during diligence"
],
"not": [
"Does not define what the customer actually buys, which is the product lead (person) with the researcher agent, and does not set the pricing, the ordering, the invoicing or the split, which is the deal-structurer agent with finance.",
"Does not set support and escalation, build the sales material, train the sales teams or agree the launch plan, which are the partner-manager agent with the support, product and sales leads.",
"Does not run the diligence it contributes findings to, which is the diligence-coordinator agent.",
"Does not hold the relationship after launch, and does not sell."
],
"processes": [
{
"process": "ref/prt/plan-the-integration",
"activities": [
"Take in the Signed Terms",
"Set the Technical Scope",
"Design the Integration",
"Plan the Environments and Data",
"Build and Test the Connection",
"Run a Joint Pilot",
"Check Readiness Before Launch",
"Hand On to Partner Management"
]
},
{
"process": "ref/prt/run-alliance-diligence",
"activities": [
"Test the Technology",
"Read the Dependencies"
]
}
]
}
}
}
README.mdWhat the package is, and why it carries no mcp.json.
# integration-planner 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/plan-the-integration`, `ref/prt/run-alliance-diligence`. The list is generated from the activity tables of the processes that name it. https://agentcatalog.com/abstract-agents/integration-planner
skills/build-it-and-prove-it-on-a-customer/SKILL.mdSees the connection built and run end to end with what passed and what did not written down, then proves the offer on one named customer with both sides watching, before anybody announces it. Use it when running `ref/prt/plan-the-integration`.
--- name: build-it-and-prove-it-on-a-customer description: Sees the connection built and run end to end with what passed and what did not written down, then proves the offer on one named customer with both sides watching, before anybody announces it. Use it when running `ref/prt/plan-the-integration`. license: CC-BY-4.0 metadata: agent: integration-planner agent-version: "1" --- # Build it and prove it on a customer ## What it does Sees the connection built and run end to end with what passed and what did not written down, then proves the offer on one named customer with both sides watching, before anybody announces it. ## Where it happens The agent does this in two activities across one reference process. Each one names the activity as that process words it. - **Build and Test the Connection** - `ref/prt/plan-the-integration`, activity 7 - [Plan the Integration](../../../../processes/partners/plan-the-integration.md) - **Run a Joint Pilot** - `ref/prt/plan-the-integration`, activity 8 - [Plan the Integration](../../../../processes/partners/plan-the-integration.md) ## What to record Every technical obligation the signed agreement creates, with the date it comes due. The scope, saying what connects and what deliberately does not. The design at a version: interfaces, data, identity and the limits each side agreed to. The environment plan, naming the test systems and test accounts on both sides and what data they hold. The build and the end to end test, with what passed and what did not. The joint pilot with one named customer, what both sides watched, and what it showed. In diligence, the technology test naming which of our real cases were run and how each came out, and the dependency read naming the licenses, the third parties and what the product depends on. The readiness check against the list, item by item, with any waiver naming who waived it and the risk they accepted. The handover to partner management. 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`.
skills/design-the-connection/SKILL.mdDesigns the interfaces, the data, the identity and the limits each side agreed to, and plans the test systems and test accounts on both sides and what data they hold. Use it when running `ref/prt/plan-the-integration`.
--- name: design-the-connection description: Designs the interfaces, the data, the identity and the limits each side agreed to, and plans the test systems and test accounts on both sides and what data they hold. Use it when running `ref/prt/plan-the-integration`. license: CC-BY-4.0 metadata: agent: integration-planner agent-version: "1" --- # Design the connection ## What it does Designs the interfaces, the data, the identity and the limits each side agreed to, and plans the test systems and test accounts on both sides and what data they hold. ## Where it happens The agent does this in two activities across one reference process. Each one names the activity as that process words it. - **Design the Integration** - `ref/prt/plan-the-integration`, activity 5 - [Plan the Integration](../../../../processes/partners/plan-the-integration.md) - **Plan the Environments and Data** - `ref/prt/plan-the-integration`, activity 6 - [Plan the Integration](../../../../processes/partners/plan-the-integration.md) ## What to record Every technical obligation the signed agreement creates, with the date it comes due. The scope, saying what connects and what deliberately does not. The design at a version: interfaces, data, identity and the limits each side agreed to. The environment plan, naming the test systems and test accounts on both sides and what data they hold. The build and the end to end test, with what passed and what did not. The joint pilot with one named customer, what both sides watched, and what it showed. In diligence, the technology test naming which of our real cases were run and how each came out, and the dependency read naming the licenses, the third parties and what the product depends on. The readiness check against the list, item by item, with any waiver naming who waived it and the risk they accepted. The handover to partner management. 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`.
skills/hold-the-readiness-gate/SKILL.mdWorks the readiness list item by item and puts the gate itself to a person, with any waiver naming who waived it and the risk they accepted, then hands the running alliance on to partner management. Use it when running `ref/prt/plan-the-integration`.
--- name: hold-the-readiness-gate description: Works the readiness list item by item and puts the gate itself to a person, with any waiver naming who waived it and the risk they accepted, then hands the running alliance on to partner management. Use it when running `ref/prt/plan-the-integration`. license: CC-BY-4.0 metadata: agent: integration-planner agent-version: "1" --- # Hold the readiness gate ## What it does Works the readiness list item by item and puts the gate itself to a person, with any waiver naming who waived it and the risk they accepted, then hands the running alliance on to partner management. ## 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 Readiness Before Launch** - `ref/prt/plan-the-integration`, activity 14 - [Plan the Integration](../../../../processes/partners/plan-the-integration.md) - **Hand On to Partner Management** - `ref/prt/plan-the-integration`, activity 16 - [Plan the Integration](../../../../processes/partners/plan-the-integration.md) ## What to record Every technical obligation the signed agreement creates, with the date it comes due. The scope, saying what connects and what deliberately does not. The design at a version: interfaces, data, identity and the limits each side agreed to. The environment plan, naming the test systems and test accounts on both sides and what data they hold. The build and the end to end test, with what passed and what did not. The joint pilot with one named customer, what both sides watched, and what it showed. In diligence, the technology test naming which of our real cases were run and how each came out, and the dependency read naming the licenses, the third parties and what the product depends on. The readiness check against the list, item by item, with any waiver naming who waived it and the risk they accepted. The handover to partner management. 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`.
skills/take-in-the-terms-and-set-the-scope/SKILL.mdReads the signed agreement for what it obliges technically and when each obligation comes due, then sets what has to connect, how deep it goes and what deliberately does not connect. Use it when running `ref/prt/plan-the-integration`.
--- name: take-in-the-terms-and-set-the-scope description: Reads the signed agreement for what it obliges technically and when each obligation comes due, then sets what has to connect, how deep it goes and what deliberately does not connect. Use it when running `ref/prt/plan-the-integration`. license: CC-BY-4.0 metadata: agent: integration-planner agent-version: "1" --- # Take in the terms and set the scope ## What it does Reads the signed agreement for what it obliges technically and when each obligation comes due, then sets what has to connect, how deep it goes and what deliberately does not connect. ## 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 the Technical Scope** - `ref/prt/plan-the-integration`, activity 4 - [Plan the Integration](../../../../processes/partners/plan-the-integration.md) - **Take in the Signed Terms** - `ref/prt/plan-the-integration`, activity 1 - [Plan the Integration](../../../../processes/partners/plan-the-integration.md) ## What to record Every technical obligation the signed agreement creates, with the date it comes due. The scope, saying what connects and what deliberately does not. The design at a version: interfaces, data, identity and the limits each side agreed to. The environment plan, naming the test systems and test accounts on both sides and what data they hold. The build and the end to end test, with what passed and what did not. The joint pilot with one named customer, what both sides watched, and what it showed. In diligence, the technology test naming which of our real cases were run and how each came out, and the dependency read naming the licenses, the third parties and what the product depends on. The readiness check against the list, item by item, with any waiver naming who waived it and the risk they accepted. The handover to partner management. 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`.
skills/test-another-company-technology/SKILL.mdRuns the other company's product against our own real cases and reads what that product depends on, naming the licenses and the third parties behind it, so a dependency that would block embedding or reselling is found while the deal can still change. Use it when running `ref/prt/run-alliance-diligence`.
--- name: test-another-company-technology description: Runs the other company's product against our own real cases and reads what that product depends on, naming the licenses and the third parties behind it, so a dependency that would block embedding or reselling is found while the deal can still change. Use it when running `ref/prt/run-alliance-diligence`. license: CC-BY-4.0 metadata: agent: integration-planner agent-version: "1" --- # Test another company technology ## What it does Runs the other company's product against our own real cases and reads what that product depends on, naming the licenses and the third parties behind it, so a dependency that would block embedding or reselling is found while the deal can still change. ## Where it happens The agent does this in two activities across one reference process. Each one names the activity as that process words it. - **Read the Dependencies** - `ref/prt/run-alliance-diligence`, activity 9 - [Run Alliance Diligence](../../../../processes/partners/run-alliance-diligence.md) - **Test the Technology** - `ref/prt/run-alliance-diligence`, activity 8 - [Run Alliance Diligence](../../../../processes/partners/run-alliance-diligence.md) ## What to record Every technical obligation the signed agreement creates, with the date it comes due. The scope, saying what connects and what deliberately does not. The design at a version: interfaces, data, identity and the limits each side agreed to. The environment plan, naming the test systems and test accounts on both sides and what data they hold. The build and the end to end test, with what passed and what did not. The joint pilot with one named customer, what both sides watched, and what it showed. In diligence, the technology test naming which of our real cases were run and how each came out, and the dependency read naming the licenses, the third parties and what the product depends on. The readiness check against the list, item by item, with any waiver naming who waived it and the risk they accepted. The handover to partner management. 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`.
mcp.jsonNot in the package.
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.
Setting 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.
test-environment · writepartners-systems · readobligation-register · writepartner-record · writecontract-system · readnotification-channel · write
mcp.json
You write this file. It is not part of the package.
{
"$schema": "https://agent-plugins.org/schemas/1.1.0/mcp.schema.json",
"mcpServers": {
"test-environment": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/test-environment"
},
"partners-systems": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/partners-systems"
},
"obligation-register": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/obligation-register"
},
"partner-record": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/partner-record"
},
"contract-system": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/contract-system"
},
"notification-channel": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/notification-channel"
}
}
}
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.
Where it works
2 processes, 10 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.
Plan the Integrationref/prt/plan-the-integration · 16 activities
Take in the Signed Terms · Set the Technical Scope · Design the Integration · Plan the Environments and Data · Build and Test the Connection · Run a Joint Pilot · Check Readiness Before Launch · Hand On to Partner Management
Run Alliance Diligenceref/prt/run-alliance-diligence · 17 activities
Test the Technology · Read the Dependencies
The records it leaves
What it writes down
Every technical obligation the signed agreement creates, with the date it comes due. The scope, saying what connects and what deliberately does not. The design at a version: interfaces, data, identity and the limits each side agreed to. The environment plan, naming the test systems and test accounts on both sides and what data they hold. The build and the end to end test, with what passed and what did not. The joint pilot with one named customer, what both sides watched, and what it showed. In diligence, the technology test naming which of our real cases were run and how each came out, and the dependency read naming the licenses, the third parties and what the product depends on. The readiness check against the list, item by item, with any waiver naming who waived it and the risk they accepted. The handover to partner management.
Where it stops
What it will not do
Does not define what the customer actually buys, which is the product lead (person) with the researcher agent, and does not set the pricing, the ordering, the invoicing or the split, which is the deal-structurer agent with finance. Does not set support and escalation, build the sales material, train the sales teams or agree the launch plan, which are the partner-manager agent with the support, product and sales leads. Does not run the diligence it contributes findings to, which is the diligence-coordinator agent. Does not hold the relationship after launch, and does not sell.
These limits are written into the job on purpose, so that everyone adopting the process knows which decisions stay with a person.
Agents built from this plugin
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.
declare it
implements: integration-planner v1
One line in your agent's manifest. The catalog checks it against the records your runs actually leave.
A guess, not a claim
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.
Might be reached for
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.
- AI/MCP Enablement Agency MCP server · checkmycontractorquote.com · hosted · mirrored from the MCP registry AI workflow/MCP implementation package planner.
- Advisors AI Store Readiness Check MCP server · advisorsai.ai · hosted · mirrored from the MCP registry One read-only public-page readiness check with a signed, recheckable evidence receipt.
- Repo Test Architect MCP server · repoassay.github.io · run it yourself · mirrored from the MCP registry Audit-first test strategy MCP server for repository-native test planning.