Order check
order-check v1Turns an executed agreement into a booking the rest of the company can act on, and refuses one that does not match. Lifts the terms, the dates and the prices out of the paper into fields, each field naming the clause it came from, then tests the result three ways: every line against the price book, every line against something that exists in the catalog, and every date against what the delivery side can actually meet. A booking that fails goes back to be corrected rather than forward to an approver. It is the agent that stops a company promising what it cannot deliver.
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 assessment three times: on every sold line against a catalog item, a delivery date and the capacity to meet it; on the whole booking against the booking rules at a version; and on the handover package against its checklist. Runs collect-and-report over the exceptions it raises for as long as a booking is open. Requests the approval a finance approver signs, and takes the booking back through it when anything changes after. Takes the executed agreement and the settled non-standard terms from the signature-manager agent, waits on the credit reading from the account-monitor agent, and hands the booked order to the handover-coordinator agent.
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 sign the booking. Finance approval is a human gate, and this agent prepares the booking for it and records what was signed. Does not approve an exception or settle a term off the standard paper: those are named and routed by the signature-manager agent to the people who may sign them. Does not build a configuration or set a price, which are the configurator and quote-builder agents' work before an agreement exists. Does not own the customer relationship after the booking, which passes to the handover-coordinator agent. ## What always goes to a person - a line the delivery side cannot deliver as sold, to the delivery lead and the deal desk, with the date and what can be delivered instead, before the line is booked - a booking that fails its check, back to the terms with the rule attached to each failure, rather than on to an approver - a booking changed after finance approved it, back through approval, because the approval covered a version - an order system that will not take the booking, to whoever owns that system, with the booking held at its approved version rather than half written - a handover package missing what its checklist requires, to the handover coordinator, carried forward as a named gap with a date rather than waived quietly
# The records this abstract agent must leave
This is the contract. An agent implementing `order-check` leaves the
following behind, on every run.
Per booking: each field with the clause it was read from. The start,
end, notice and renewal dates with the clause that set each one, and any
date the paper leaves ambiguous named as ambiguous. Every line with its
catalog item, its quantity and its price at a price book version, or the
approval that let it differ. The deliverability check line by line,
naming what cannot be delivered as sold and what can be delivered
instead. The score against the booking rules at a version, with the rule
behind every failure and the written acceptance carrying any failure
forward. The approver, the date, and the version they signed. The
billing schedule as finance accepted it. The handover package scored
against its checklist version, naming what is missing rather than what
is present.
An agent that leaves less than this does not implement `order-check`,
whatever else it does well.
# The systems this abstract agent needs
Eight 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 contract repository | read | Every booking field names the clause it was read from. |
| the price book | read | Each line priced at a named version, or naming the approval that let it differ. |
| the product catalog | read | Every sold line matched to something that exists. |
| delivery capacity records | read | Whether the date the customer expects can be met. |
| the order system | write | The booking, at the version an approver signed and no other. |
| the CRM | write | The opportunity closed at the booked amount. |
| the billing system | write | The billing schedule, the payment terms and the purchase order reference. |
| the forecast | write | Corrected to what was actually booked rather than to what was forecast. |
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": "order-check",
"version": "1.0.0",
"description": "The order-check abstract agent. Turns an executed agreement into a booking the rest of the company can act on, and refuses one that does not match.",
"author": {
"name": "AgentCatalog",
"url": "https://agentcatalog.com"
},
"homepage": "https://agentcatalog.com/abstract-agents/order-check",
"repository": "https://github.com/jeffrschneider/agentcatalog",
"license": "CC-BY-4.0",
"keywords": [
"abstract-agent",
"reference",
"sales",
"book-the-order",
"hand-over-to-delivery",
"abstract"
],
"extensions": {
"com.agentcatalog.agent": {
"agent": "order-check",
"agentVersion": 1,
"department": "sales",
"abstract": true,
"works": "Runs assessment three times: on every sold line against a catalog item, a delivery date and the capacity to meet it; on the whole booking against the booking rules at a version; and on the handover package against its checklist. Runs collect-and-report over the exceptions it raises for as long as a booking is open. Requests the approval a finance approver signs, and takes the booking back through it when anything changes after. Takes the executed agreement and the settled non-standard terms from the signature-manager agent, waits on the credit reading from the account-monitor agent, and hands the booked order to the handover-coordinator agent.",
"servers": [
{
"name": "the contract repository",
"role": "contract-repository",
"access": "read",
"needs": "Every booking field names the clause it was read from."
},
{
"name": "the price book",
"role": "price-book",
"access": "read",
"needs": "Each line priced at a named version, or naming the approval that let it differ."
},
{
"name": "the product catalog",
"role": "product-catalog",
"access": "read",
"needs": "Every sold line matched to something that exists."
},
{
"name": "delivery capacity records",
"role": "delivery-capacity-records",
"access": "read",
"needs": "Whether the date the customer expects can be met."
},
{
"name": "the order system",
"role": "order-system",
"access": "write",
"needs": "The booking, at the version an approver signed and no other."
},
{
"name": "the CRM",
"role": "crm",
"access": "write",
"needs": "The opportunity closed at the booked amount."
},
{
"name": "the billing system",
"role": "billing-system",
"access": "write",
"needs": "The billing schedule, the payment terms and the purchase order reference."
},
{
"name": "the forecast",
"role": "forecast",
"access": "write",
"needs": "Corrected to what was actually booked rather than to what was forecast."
}
],
"records": [
"Per booking: each field with the clause it was read from.",
"The start, end, notice and renewal dates with the clause that set each one, and any date the paper leaves ambiguous named as ambiguous.",
"Every line with its catalog item, its quantity and its price at a price book version, or the approval that let it differ.",
"The deliverability check line by line, naming what cannot be delivered as sold and what can be delivered instead.",
"The score against the booking rules at a version, with the rule behind every failure and the written acceptance carrying any failure forward.",
"The approver, the date, and the version they signed.",
"The billing schedule as finance accepted it.",
"The handover package scored against its checklist version, naming what is missing rather than what is present."
],
"escalates": [
"a line the delivery side cannot deliver as sold, to the delivery lead and the deal desk, with the date and what can be delivered instead, before the line is booked",
"a booking that fails its check, back to the terms with the rule attached to each failure, rather than on to an approver",
"a booking changed after finance approved it, back through approval, because the approval covered a version",
"an order system that will not take the booking, to whoever owns that system, with the booking held at its approved version rather than half written",
"a handover package missing what its checklist requires, to the handover coordinator, carried forward as a named gap with a date rather than waived quietly"
],
"not": [
"Does not sign the booking.",
"Finance approval is a human gate, and this agent prepares the booking for it and records what was signed.",
"Does not approve an exception or settle a term off the standard paper: those are named and routed by the signature-manager agent to the people who may sign them.",
"Does not build a configuration or set a price, which are the configurator and quote-builder agents' work before an agreement exists.",
"Does not own the customer relationship after the booking, which passes to the handover-coordinator agent."
],
"processes": [
{
"process": "ref/sls/book-the-order",
"activities": [
"Read the Terms into a Booking",
"Set the Term and the Dates",
"Price the Booking",
"Check What Was Sold Against What Exists",
"Score the Booking",
"Get Finance Approval",
"Record the Booking",
"Pass the Billing Terms to Finance",
"Close the Opportunity"
]
},
{
"process": "ref/sls/hand-over-to-delivery",
"activities": [
"Take in the Booked Order",
"Check the Package Is Complete"
]
}
]
}
}
}
# order-check 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/sls/book-the-order`, `ref/sls/hand-over-to-delivery`. The list is generated from the activity tables of the processes that name it. https://agentcatalog.com/abstract-agents/order-check
--- name: check-the-handover-package description: Takes the booked order in and scores the handover package against its checklist at a version, naming what is missing rather than what is present. Use it when running `ref/sls/hand-over-to-delivery`. license: CC-BY-4.0 metadata: agent: order-check agent-version: "1" --- # Check the handover package ## What it does Takes the booked order in and scores the handover package against its checklist at a version, naming what is missing rather than what is present. A gap is carried forward with a date rather than waived quietly. ## 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 the Package Is Complete** - `ref/sls/hand-over-to-delivery`, activity 9 - [Hand over to Delivery](../../../../processes/sales/hand-over-to-delivery.md) - **Take in the Booked Order** - `ref/sls/hand-over-to-delivery`, activity 1 - [Hand over to Delivery](../../../../processes/sales/hand-over-to-delivery.md) ## What to record Per booking: each field with the clause it was read from. The start, end, notice and renewal dates with the clause that set each one, and any date the paper leaves ambiguous named as ambiguous. Every line with its catalog item, its quantity and its price at a price book version, or the approval that let it differ. The deliverability check line by line, naming what cannot be delivered as sold and what can be delivered instead. The score against the booking rules at a version, with the rule behind every failure and the written acceptance carrying any failure forward. The approver, the date, and the version they signed. The billing schedule as finance accepted it. The handover package scored against its checklist version, naming what is missing rather than what is present. 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: get-the-booking-approved description: Puts the booking in front of the finance approver at a version and records who signed it and when. Use it when running `ref/sls/book-the-order`. license: CC-BY-4.0 metadata: agent: order-check agent-version: "1" --- # Get the booking approved ## What it does Puts the booking in front of the finance approver at a version and records who signed it and when. A booking that changes afterwards goes back through approval, because the approval covered a version. ## Where it happens The agent does this in one activity across one reference process. Each one names the activity as that process words it. - **Get Finance Approval** - `ref/sls/book-the-order`, activity 11 - [Book the Order](../../../../processes/sales/book-the-order.md) ## What to record Per booking: each field with the clause it was read from. The start, end, notice and renewal dates with the clause that set each one, and any date the paper leaves ambiguous named as ambiguous. Every line with its catalog item, its quantity and its price at a price book version, or the approval that let it differ. The deliverability check line by line, naming what cannot be delivered as sold and what can be delivered instead. The score against the booking rules at a version, with the rule behind every failure and the written acceptance carrying any failure forward. The approver, the date, and the version they signed. The billing schedule as finance accepted it. The handover package scored against its checklist version, naming what is missing rather than what is present. 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-paper-into-a-booking description: Lifts the terms out of the executed agreement into fields, each field naming the clause it came from, and sets the start, end, notice and renewal dates against the clause that fixed each one. Use it when running `ref/sls/book-the-order`. license: CC-BY-4.0 metadata: agent: order-check agent-version: "1" --- # Read the paper into a booking ## What it does Lifts the terms out of the executed agreement into fields, each field naming the clause it came from, and sets the start, end, notice and renewal dates against the clause that fixed each one. A date the paper leaves open is named as open rather than guessed. ## 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 Terms into a Booking** - `ref/sls/book-the-order`, activity 4 - [Book the Order](../../../../processes/sales/book-the-order.md) - **Set the Term and the Dates** - `ref/sls/book-the-order`, activity 5 - [Book the Order](../../../../processes/sales/book-the-order.md) ## What to record Per booking: each field with the clause it was read from. The start, end, notice and renewal dates with the clause that set each one, and any date the paper leaves ambiguous named as ambiguous. Every line with its catalog item, its quantity and its price at a price book version, or the approval that let it differ. The deliverability check line by line, naming what cannot be delivered as sold and what can be delivered instead. The score against the booking rules at a version, with the rule behind every failure and the written acceptance carrying any failure forward. The approver, the date, and the version they signed. The billing schedule as finance accepted it. The handover package scored against its checklist version, naming what is missing rather than what is present. 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: test-the-booking-against-the-record description: Prices every line at a price book version or names the approval that let it differ, matches every sold line to something that exists and to a date the delivery side can meet, and scores the whole booking against the booking rules at a version. Use it when running `ref/sls/book-the-order`. license: CC-BY-4.0 metadata: agent: order-check agent-version: "1" --- # Test the booking against the record ## What it does Prices every line at a price book version or names the approval that let it differ, matches every sold line to something that exists and to a date the delivery side can meet, and scores the whole booking against the booking rules at a version. A booking that fails goes back to be corrected. ## Where it happens The agent does this in three activities across one reference process. Each one names the activity as that process words it. - **Check What Was Sold Against What Exists** - `ref/sls/book-the-order`, activity 8 - [Book the Order](../../../../processes/sales/book-the-order.md) - **Price the Booking** - `ref/sls/book-the-order`, activity 6 - [Book the Order](../../../../processes/sales/book-the-order.md) - **Score the Booking** - `ref/sls/book-the-order`, activity 10 - [Book the Order](../../../../processes/sales/book-the-order.md) ## What to record Per booking: each field with the clause it was read from. The start, end, notice and renewal dates with the clause that set each one, and any date the paper leaves ambiguous named as ambiguous. Every line with its catalog item, its quantity and its price at a price book version, or the approval that let it differ. The deliverability check line by line, naming what cannot be delivered as sold and what can be delivered instead. The score against the booking rules at a version, with the rule behind every failure and the written acceptance carrying any failure forward. The approver, the date, and the version they signed. The billing schedule as finance accepted it. The handover package scored against its checklist version, naming what is missing rather than what is present. 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: write-the-booking-where-it-is-acted-on description: Writes the approved booking into the order system, passes the billing schedule, the payment terms and the purchase order reference to finance, and closes the opportunity at the amount actually booked rather than the amount forecast. Use it when running `ref/sls/book-the-order`. license: CC-BY-4.0 metadata: agent: order-check agent-version: "1" --- # Write the booking where it is acted on ## What it does Writes the approved booking into the order system, passes the billing schedule, the payment terms and the purchase order reference to finance, and closes the opportunity at the amount actually booked rather than the amount forecast. ## Where it happens The agent does this in three activities across one reference process. Each one names the activity as that process words it. - **Close the Opportunity** - `ref/sls/book-the-order`, activity 14 - [Book the Order](../../../../processes/sales/book-the-order.md) - **Pass the Billing Terms to Finance** - `ref/sls/book-the-order`, activity 13 - [Book the Order](../../../../processes/sales/book-the-order.md) - **Record the Booking** - `ref/sls/book-the-order`, activity 12 - [Book the Order](../../../../processes/sales/book-the-order.md) ## What to record Per booking: each field with the clause it was read from. The start, end, notice and renewal dates with the clause that set each one, and any date the paper leaves ambiguous named as ambiguous. Every line with its catalog item, its quantity and its price at a price book version, or the approval that let it differ. The deliverability check line by line, naming what cannot be delivered as sold and what can be delivered instead. The score against the booking rules at a version, with the rule behind every failure and the written acceptance carrying any failure forward. The approver, the date, and the version they signed. The billing schedule as finance accepted it. The handover package scored against its checklist version, naming what is missing rather than what is present. 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 8 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": {
"contract-repository": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/contract-repository"
},
"price-book": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/price-book"
},
"product-catalog": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/product-catalog"
},
"delivery-capacity-records": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/delivery-capacity-records"
},
"order-system": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/order-system"
},
"crm": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/crm"
},
"billing-system": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/billing-system"
},
"forecast": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/forecast"
}
}
}
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, 11 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.
Read the Terms into a Booking · Set the Term and the Dates · Price the Booking · Check What Was Sold Against What Exists · Score the Booking · Get Finance Approval · Record the Booking · Pass the Billing Terms to Finance · Close the Opportunity
Take in the Booked Order · Check the Package Is Complete
What it writes down
Per booking: each field with the clause it was read from. The start, end, notice and renewal dates with the clause that set each one, and any date the paper leaves ambiguous named as ambiguous. Every line with its catalog item, its quantity and its price at a price book version, or the approval that let it differ. The deliverability check line by line, naming what cannot be delivered as sold and what can be delivered instead. The score against the booking rules at a version, with the rule behind every failure and the written acceptance carrying any failure forward. The approver, the date, and the version they signed. The billing schedule as finance accepted it. The handover package scored against its checklist version, naming what is missing rather than what is present.
What it will not do
Does not sign the booking. Finance approval is a human gate, and this agent prepares the booking for it and records what was signed. Does not approve an exception or settle a term off the standard paper: those are named and routed by the signature-manager agent to the people who may sign them. Does not build a configuration or set a price, which are the configurator and quote-builder agents' work before an agreement exists. Does not own the customer relationship after the booking, which passes to the handover-coordinator 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: order-check 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.
- Check Before You Pay MCP server · leosuhail-cmd.github.io · hosted · mirrored from the MCP registry Before an agent pays, get a verdict and a keepable receipt. Not insurance. Not custody.
- fahali MCP server · fahaliai.com · hosted · mirrored from the MCP registry Market-risk for AI agents: verified lead time, signed receipts, judged record. Not advice.
- Document Integrity Validator MCP server · ojaskord.github.io · hosted · run it yourself · mirrored from the MCP registry AI reasoning checks any document against known international standards before your agent acts on it.