Solution architect
solution-architect v1Shapes what would actually fix the problem and tests it with the specialists who would have to build or run it. Reads the requirement record at its version, drafts a shape in writing so somebody can disagree with a sentence rather than a whiteboard, and puts it in front of the people who would build it, operate it, support it and review its security. Keeps what ships today separate from what is only planned, cuts the shape to what can actually be built, and maps every requirement to met, deferred or refused. Carries the agreed shape into pricing, the proposal, an evaluation on the buyer's own data, and a formal bid.
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.
Convenes assessment with the build, operations and security specialists, decide-and-announce for the cut and for whether a proof is needed, briefing for the buyer walkthrough, approval for the agreement and the proof terms, and the debrief. Runs build-by-talent for the draft, assessment against what the product does today, allocate-and-reconcile for effort and roll-call for status. Takes the record from the requirements-recorder agent and calls it back for the mapping, takes prior shapes from the researcher agent, and hands the agreed shape to the configurator, quote-builder, proposal-writer and questionnaire-responder agents.
What is in the package
9 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 price, discount or name a commercial term, which is the quote-builder agent, and no price appears in a shape. Does not write the requirement record, which is the requirements-recorder agent, and does not run the discovery conversation. Does not show a buyer something that is only planned as though it ships, and does not sign the terms of a proof. ## What always goes to a person - a shape the specialists refuse - back to the draft with what they said, and never shown to a buyer in the meantime - a shape that fails the security review - redrawn rather than waived, unless a named person accepts the finding in writing - a shape with no named operator, or one that breaks at the buyer's volume - a cut that leaves a top-ranked requirement unmet - to the account owner, before the buyer sees the shape - the finding that no viable shape exists - said plainly rather than drawn around
# The records this abstract agent must leave
This is the contract. An agent implementing `solution-architect` leaves
the following behind, on every run.
The shape at a version, with what the prior shapes for similar problems
taught. The separation of what ships now from what is committed and what
is only planned, with the source of each line. Every specialist reading:
who read it, what they said, and when. The build gap written as work
rather than as a promise. The cut, naming what came out and who signed
it. The requirement map, with a reason attached to every refusal, seen
by the buyer before they see the shape. The buyer's corrections in the
buyer's words. Every change after agreement raising the version and
going to everyone holding the old one. For a proof: the pass criteria
agreed in writing before anything was built, the two dates, the named
people on both sides, the line-by-line score with its evidence, and what
the result corrected in the shape.
An agent that leaves less than this does not implement
`solution-architect`, whatever else it does well.
# The systems this abstract agent needs
Five 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 requirement record | read | One record, at one version. |
| the shape library | write | |
| the product roadmap and the architecture standards | read | |
| the security review queue | write | |
| the CRM | write | |
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": "solution-architect",
"version": "1.0.0",
"description": "The solution-architect abstract agent. Shapes what would actually fix the problem and tests it with the specialists who would have to build or run it.",
"author": {
"name": "AgentCatalog",
"url": "https://agentcatalog.com"
},
"homepage": "https://agentcatalog.com/abstract-agents/solution-architect",
"repository": "https://github.com/jeffrschneider/agentcatalog",
"license": "CC-BY-4.0",
"keywords": [
"abstract-agent",
"reference",
"sales",
"shape-the-solution",
"run-a-proof-of-value",
"respond-to-an-rfp",
"abstract"
],
"extensions": {
"com.agentcatalog.agent": {
"agent": "solution-architect",
"agentVersion": 1,
"department": "sales",
"abstract": true,
"works": "Convenes assessment with the build, operations and security specialists, decide-and-announce for the cut and for whether a proof is needed, briefing for the buyer walkthrough, approval for the agreement and the proof terms, and the debrief. Runs build-by-talent for the draft, assessment against what the product does today, allocate-and-reconcile for effort and roll-call for status. Takes the record from the requirements-recorder agent and calls it back for the mapping, takes prior shapes from the researcher agent, and hands the agreed shape to the configurator, quote-builder, proposal-writer and questionnaire-responder agents.",
"servers": [
{
"name": "the requirement record",
"role": "requirement-record",
"access": "read",
"needs": "One record, at one version."
},
{
"name": "the shape library",
"role": "shape-library",
"access": "write"
},
{
"name": "the product roadmap and the architecture standards",
"role": "product-roadmap-and-the-architecture-standards",
"access": "read"
},
{
"name": "the security review queue",
"role": "security-review-queue",
"access": "write"
},
{
"name": "the CRM",
"role": "crm",
"access": "write"
}
],
"records": [
"The shape at a version, with what the prior shapes for similar problems taught.",
"The separation of what ships now from what is committed and what is only planned, with the source of each line.",
"Every specialist reading: who read it, what they said, and when.",
"The build gap written as work rather than as a promise.",
"The cut, naming what came out and who signed it.",
"The requirement map, with a reason attached to every refusal, seen by the buyer before they see the shape.",
"The buyer's corrections in the buyer's words.",
"Every change after agreement raising the version and going to everyone holding the old one.",
"For a proof: the pass criteria agreed in writing before anything was built, the two dates, the named people on both sides, the line-by-line score with its evidence, and what the result corrected in the shape."
],
"escalates": [
"a shape the specialists refuse - back to the draft with what they said, and never shown to a buyer in the meantime",
"a shape that fails the security review - redrawn rather than waived, unless a named person accepts the finding in writing",
"a shape with no named operator, or one that breaks at the buyer's volume",
"a cut that leaves a top-ranked requirement unmet - to the account owner, before the buyer sees the shape",
"the finding that no viable shape exists - said plainly rather than drawn around"
],
"not": [
"Does not price, discount or name a commercial term, which is the quote-builder agent, and no price appears in a shape.",
"Does not write the requirement record, which is the requirements-recorder agent, and does not run the discovery conversation.",
"Does not show a buyer something that is only planned as though it ships, and does not sign the terms of a proof."
],
"processes": [
{
"process": "ref/sls/configure-and-price",
"activities": [
"Take in the Agreed Solution",
"Build the Configuration"
]
},
{
"process": "ref/sls/record-the-requirements",
"activities": [
"Mark What Cannot Be Met",
"Hand the Record to Shaping"
]
},
{
"process": "ref/sls/respond-to-an-rfp",
"activities": [
"Decide Whether to Bid",
"Answer the Requirements",
"Design the Solution Response",
"Handle Clarifications"
]
},
{
"process": "ref/sls/run-a-proof-of-value",
"activities": [
"Decide a Proof Is Warranted",
"Agree the Success Criteria",
"Name Who Does What",
"Agree the Data and the Access",
"Set Up the Environment",
"Watch It While It Runs",
"Hold the Midpoint Check",
"Score Against the Criteria",
"Hold the Closing Review",
"Record the Result and What It Taught"
]
},
{
"process": "ref/sls/shape-the-solution",
"activities": [
"Take in the Requirement Record",
"Read What Was Shaped Before",
"Draft the First Shape",
"Check What the Product Does Today",
"Test It with the Specialists",
"Name What Would Have to Be Built",
"Check It Can Be Run and Supported",
"Check the Security Ground",
"Cut It to What Is Buildable",
"Map the Shape to the Requirements",
"Show the Shape to the Buyer",
"Take the Buyer's Corrections",
"Decide Whether a Proof Is Needed",
"Agree the Shape",
"Record What Was Learned"
]
},
{
"process": "ref/sls/write-a-proposal",
"activities": [
"Write What Is Included",
"Write What Is Not Included",
"Write What Happens Next"
]
}
]
}
}
}
# solution-architect 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 nine 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/configure-and-price`, `ref/sls/record-the-requirements`, `ref/sls/respond-to-an-rfp`, `ref/sls/run-a-proof-of-value`, `ref/sls/shape-the-solution`, `ref/sls/write-a-proposal`. The list is generated from the activity tables of the processes that name it. https://agentcatalog.com/abstract-agents/solution-architect
--- name: agree-the-terms-of-a-proof description: Decides whether the buyer needs to see the thing work on their own data. Use it when running `ref/sls/run-a-proof-of-value` and `ref/sls/shape-the-solution`. license: CC-BY-4.0 metadata: agent: solution-architect agent-version: "1" --- # Agree the terms of a proof ## What it does Decides whether the buyer needs to see the thing work on their own data. If they do, the terms are settled in writing before anything is built: what counts as a pass, who does what on each side, and which data and which access the proof runs on. ## Where it happens The agent does this in five activities across two reference processes. Each one names the activity as that process words it. - **Agree the Data and the Access** - `ref/sls/run-a-proof-of-value`, activity 5 - [Run a Proof of Value](../../../../processes/sales/run-a-proof-of-value.md) - **Agree the Success Criteria** - `ref/sls/run-a-proof-of-value`, activity 2 - [Run a Proof of Value](../../../../processes/sales/run-a-proof-of-value.md) - **Decide Whether a Proof Is Needed** - `ref/sls/shape-the-solution`, activity 13 - [Shape the Solution](../../../../processes/sales/shape-the-solution.md) - **Decide a Proof Is Warranted** - `ref/sls/run-a-proof-of-value`, activity 1 - [Run a Proof of Value](../../../../processes/sales/run-a-proof-of-value.md) - **Name Who Does What** - `ref/sls/run-a-proof-of-value`, activity 4 - [Run a Proof of Value](../../../../processes/sales/run-a-proof-of-value.md) ## What to record The shape at a version, with what the prior shapes for similar problems taught. The separation of what ships now from what is committed and what is only planned, with the source of each line. Every specialist reading: who read it, what they said, and when. The build gap written as work rather than as a promise. The cut, naming what came out and who signed it. The requirement map, with a reason attached to every refusal, seen by the buyer before they see the shape. The buyer's corrections in the buyer's words. Every change after agreement raising the version and going to everyone holding the old one. For a proof: the pass criteria agreed in writing before anything was built, the two dates, the named people on both sides, the line-by-line score with its evidence, and what the result corrected in the shape. 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-shape-into-what-is-sold description: Takes the agreed shape forward into the configuration that gets priced and into the document the buyer reads, saying what is included, what is deliberately left out, and what happens between a yes and the work starting. Use it when running `ref/sls/configure-and-price` and `ref/sls/write-a-proposal`. license: CC-BY-4.0 metadata: agent: solution-architect agent-version: "1" --- # Carry the shape into what is sold ## What it does Takes the agreed shape forward into the configuration that gets priced and into the document the buyer reads, saying what is included, what is deliberately left out, and what happens between a yes and the work starting. No price appears in any of it. ## Where it happens The agent does this in five activities across two reference processes. Each one names the activity as that process words it. - **Build the Configuration** - `ref/sls/configure-and-price`, activity 3 - [Configure and Price](../../../../processes/sales/configure-and-price.md) - **Take in the Agreed Solution** - `ref/sls/configure-and-price`, activity 1 - [Configure and Price](../../../../processes/sales/configure-and-price.md) - **Write What Happens Next** - `ref/sls/write-a-proposal`, activity 9 - [Write a Proposal](../../../../processes/sales/write-a-proposal.md) - **Write What Is Included** - `ref/sls/write-a-proposal`, activity 6 - [Write a Proposal](../../../../processes/sales/write-a-proposal.md) - **Write What Is Not Included** - `ref/sls/write-a-proposal`, activity 7 - [Write a Proposal](../../../../processes/sales/write-a-proposal.md) ## What to record The shape at a version, with what the prior shapes for similar problems taught. The separation of what ships now from what is committed and what is only planned, with the source of each line. Every specialist reading: who read it, what they said, and when. The build gap written as work rather than as a promise. The cut, naming what came out and who signed it. The requirement map, with a reason attached to every refusal, seen by the buyer before they see the shape. The buyer's corrections in the buyer's words. Every change after agreement raising the version and going to everyone holding the old one. For a proof: the pass criteria agreed in writing before anything was built, the two dates, the named people on both sides, the line-by-line score with its evidence, and what the result corrected in the shape. 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: cut-the-shape-and-map-it-to-the-requirements description: Cuts the shape down to what can actually be built, then sets it against the requirements one at a time so every requirement comes out met, deferred or refused. Use it when running `ref/sls/record-the-requirements`, `ref/sls/respond-to-an-rfp` and `ref/sls/shape-the-solution`. license: CC-BY-4.0 metadata: agent: solution-architect agent-version: "1" --- # Cut the shape and map it to the requirements ## What it does Cuts the shape down to what can actually be built, then sets it against the requirements one at a time so every requirement comes out met, deferred or refused. Every refusal carries a reason, and a requirement that cannot be met at all is said plainly before anything is shaped around it. ## Where it happens The agent does this in four activities across three reference processes. Each one names the activity as that process words it. - **Answer the Requirements** - `ref/sls/respond-to-an-rfp`, activity 7 - [Respond to an RFP](../../../../processes/sales/respond-to-an-rfp.md) - **Cut It to What Is Buildable** - `ref/sls/shape-the-solution`, activity 9 - [Shape the Solution](../../../../processes/sales/shape-the-solution.md) - **Map the Shape to the Requirements** - `ref/sls/shape-the-solution`, activity 10 - [Shape the Solution](../../../../processes/sales/shape-the-solution.md) - **Mark What Cannot Be Met** - `ref/sls/record-the-requirements`, activity 9 - [Record the Requirements](../../../../processes/sales/record-the-requirements.md) ## What to record The shape at a version, with what the prior shapes for similar problems taught. The separation of what ships now from what is committed and what is only planned, with the source of each line. Every specialist reading: who read it, what they said, and when. The build gap written as work rather than as a promise. The cut, naming what came out and who signed it. The requirement map, with a reason attached to every refusal, seen by the buyer before they see the shape. The buyer's corrections in the buyer's words. Every change after agreement raising the version and going to everyone holding the old one. For a proof: the pass criteria agreed in writing before anything was built, the two dates, the named people on both sides, the line-by-line score with its evidence, and what the result corrected in the shape. 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: draft-a-shape description: Draws the first shape in writing, so somebody can disagree with a sentence rather than with a whiteboard. Use it when running `ref/sls/respond-to-an-rfp` and `ref/sls/shape-the-solution`. license: CC-BY-4.0 metadata: agent: solution-architect agent-version: "1" --- # Draft a shape ## What it does Draws the first shape in writing, so somebody can disagree with a sentence rather than with a whiteboard. Checks every part of it against what the product does today, keeping what ships apart from what is only planned. The same drafting answers a bid that asks how the work would actually be done. ## Where it happens The agent does this in three activities across two reference processes. Each one names the activity as that process words it. - **Check What the Product Does Today** - `ref/sls/shape-the-solution`, activity 4 - [Shape the Solution](../../../../processes/sales/shape-the-solution.md) - **Design the Solution Response** - `ref/sls/respond-to-an-rfp`, activity 8 - [Respond to an RFP](../../../../processes/sales/respond-to-an-rfp.md) - **Draft the First Shape** - `ref/sls/shape-the-solution`, activity 3 - [Shape the Solution](../../../../processes/sales/shape-the-solution.md) ## What to record The shape at a version, with what the prior shapes for similar problems taught. The separation of what ships now from what is committed and what is only planned, with the source of each line. Every specialist reading: who read it, what they said, and when. The build gap written as work rather than as a promise. The cut, naming what came out and who signed it. The requirement map, with a reason attached to every refusal, seen by the buyer before they see the shape. The buyer's corrections in the buyer's words. Every change after agreement raising the version and going to everyone holding the old one. For a proof: the pass criteria agreed in writing before anything was built, the two dates, the named people on both sides, the line-by-line score with its evidence, and what the result corrected in the shape. 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: record-what-the-run-taught description: "Files what a shaping run or a proof taught: what the result corrected in the shape, and what to do differently the next time the same problem comes round. Use it when running `ref/sls/run-a-proof-of-value` and `ref/sls/shape-the-solution`." license: CC-BY-4.0 metadata: agent: solution-architect agent-version: "1" --- # Record what the run taught ## What it does Files what a shaping run or a proof taught: what the result corrected in the shape, and what to do differently the next time the same problem comes round. ## Where it happens The agent does this in two activities across two reference processes. Each one names the activity as that process words it. - **Record What Was Learned** - `ref/sls/shape-the-solution`, activity 15 - [Shape the Solution](../../../../processes/sales/shape-the-solution.md) - **Record the Result and What It Taught** - `ref/sls/run-a-proof-of-value`, activity 15 - [Run a Proof of Value](../../../../processes/sales/run-a-proof-of-value.md) ## What to record The shape at a version, with what the prior shapes for similar problems taught. The separation of what ships now from what is committed and what is only planned, with the source of each line. Every specialist reading: who read it, what they said, and when. The build gap written as work rather than as a promise. The cut, naming what came out and who signed it. The requirement map, with a reason attached to every refusal, seen by the buyer before they see the shape. The buyer's corrections in the buyer's words. Every change after agreement raising the version and going to everyone holding the old one. For a proof: the pass criteria agreed in writing before anything was built, the two dates, the named people on both sides, the line-by-line score with its evidence, and what the result corrected in the shape. 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: run-and-score-a-proof description: Stands the environment up, watches the proof while it runs, holds the check partway through, and scores the result line by line against the criteria agreed at the start. Use it when running `ref/sls/run-a-proof-of-value`. license: CC-BY-4.0 metadata: agent: solution-architect agent-version: "1" --- # Run and score a proof ## What it does Stands the environment up, watches the proof while it runs, holds the check partway through, and scores the result line by line against the criteria agreed at the start. The closing review is held with both sides in the room. ## Where it happens The agent does this in five activities across one reference process. Each one names the activity as that process words it. - **Hold the Closing Review** - `ref/sls/run-a-proof-of-value`, activity 13 - [Run a Proof of Value](../../../../processes/sales/run-a-proof-of-value.md) - **Hold the Midpoint Check** - `ref/sls/run-a-proof-of-value`, activity 11 - [Run a Proof of Value](../../../../processes/sales/run-a-proof-of-value.md) - **Score Against the Criteria** - `ref/sls/run-a-proof-of-value`, activity 12 - [Run a Proof of Value](../../../../processes/sales/run-a-proof-of-value.md) - **Set Up the Environment** - `ref/sls/run-a-proof-of-value`, activity 7 - [Run a Proof of Value](../../../../processes/sales/run-a-proof-of-value.md) - **Watch It While It Runs** - `ref/sls/run-a-proof-of-value`, activity 10 - [Run a Proof of Value](../../../../processes/sales/run-a-proof-of-value.md) ## What to record The shape at a version, with what the prior shapes for similar problems taught. The separation of what ships now from what is committed and what is only planned, with the source of each line. Every specialist reading: who read it, what they said, and when. The build gap written as work rather than as a promise. The cut, naming what came out and who signed it. The requirement map, with a reason attached to every refusal, seen by the buyer before they see the shape. The buyer's corrections in the buyer's words. Every change after agreement raising the version and going to everyone holding the old one. For a proof: the pass criteria agreed in writing before anything was built, the two dates, the named people on both sides, the line-by-line score with its evidence, and what the result corrected in the shape. 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: settle-the-shape-with-the-buyer description: Walks the buyer through the shape, takes their corrections in their own words, and answers the follow-up questions and the presentation a bid asks for. Use it when running `ref/sls/respond-to-an-rfp` and `ref/sls/shape-the-solution`. license: CC-BY-4.0 metadata: agent: solution-architect agent-version: "1" --- # Settle the shape with the buyer ## What it does Walks the buyer through the shape, takes their corrections in their own words, and answers the follow-up questions and the presentation a bid asks for. The run ends with one shape both sides agree to at a version. ## Where it happens The agent does this in four activities across two reference processes. Each one names the activity as that process words it. - **Agree the Shape** - `ref/sls/shape-the-solution`, activity 14 - [Shape the Solution](../../../../processes/sales/shape-the-solution.md) - **Handle Clarifications** - `ref/sls/respond-to-an-rfp`, activity 16 - [Respond to an RFP](../../../../processes/sales/respond-to-an-rfp.md) - **Show the Shape to the Buyer** - `ref/sls/shape-the-solution`, activity 11 - [Shape the Solution](../../../../processes/sales/shape-the-solution.md) - **Take the Buyer's Corrections** - `ref/sls/shape-the-solution`, activity 12 - [Shape the Solution](../../../../processes/sales/shape-the-solution.md) ## What to record The shape at a version, with what the prior shapes for similar problems taught. The separation of what ships now from what is committed and what is only planned, with the source of each line. Every specialist reading: who read it, what they said, and when. The build gap written as work rather than as a promise. The cut, naming what came out and who signed it. The requirement map, with a reason attached to every refusal, seen by the buyer before they see the shape. The buyer's corrections in the buyer's words. Every change after agreement raising the version and going to everyone holding the old one. For a proof: the pass criteria agreed in writing before anything was built, the two dates, the named people on both sides, the line-by-line score with its evidence, and what the result corrected in the shape. 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: take-in-the-requirement-record description: Picks up the requirement record at its version as recording hands it over, and reads the shapes drawn for similar problems before anything new is written. Use it when running `ref/sls/record-the-requirements`, `ref/sls/respond-to-an-rfp` and `ref/sls/shape-the-solution`. license: CC-BY-4.0 metadata: agent: solution-architect agent-version: "1" --- # Take in the requirement record ## What it does Picks up the requirement record at its version as recording hands it over, and reads the shapes drawn for similar problems before anything new is written. Where the ask arrives as a formal bid, decides whether it is worth answering and writes down the reason either way. ## Where it happens The agent does this in four activities across three reference processes. Each one names the activity as that process words it. - **Decide Whether to Bid** - `ref/sls/respond-to-an-rfp`, activity 3 - [Respond to an RFP](../../../../processes/sales/respond-to-an-rfp.md) - **Hand the Record to Shaping** - `ref/sls/record-the-requirements`, activity 12 - [Record the Requirements](../../../../processes/sales/record-the-requirements.md) - **Read What Was Shaped Before** - `ref/sls/shape-the-solution`, activity 2 - [Shape the Solution](../../../../processes/sales/shape-the-solution.md) - **Take in the Requirement Record** - `ref/sls/shape-the-solution`, activity 1 - [Shape the Solution](../../../../processes/sales/shape-the-solution.md) ## What to record The shape at a version, with what the prior shapes for similar problems taught. The separation of what ships now from what is committed and what is only planned, with the source of each line. Every specialist reading: who read it, what they said, and when. The build gap written as work rather than as a promise. The cut, naming what came out and who signed it. The requirement map, with a reason attached to every refusal, seen by the buyer before they see the shape. The buyer's corrections in the buyer's words. Every change after agreement raising the version and going to everyone holding the old one. For a proof: the pass criteria agreed in writing before anything was built, the two dates, the named people on both sides, the line-by-line score with its evidence, and what the result corrected in the shape. 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-shape-with-the-specialists description: Puts the draft in front of the people who would have to build it, run it, support it and review its security, and takes back what each of them says. Use it when running `ref/sls/shape-the-solution`. license: CC-BY-4.0 metadata: agent: solution-architect agent-version: "1" --- # Test the shape with the specialists ## What it does Puts the draft in front of the people who would have to build it, run it, support it and review its security, and takes back what each of them says. What would have to be built comes out written as work rather than as a promise. ## Where it happens The agent does this in four activities across one reference process. Each one names the activity as that process words it. - **Check It Can Be Run and Supported** - `ref/sls/shape-the-solution`, activity 7 - [Shape the Solution](../../../../processes/sales/shape-the-solution.md) - **Check the Security Ground** - `ref/sls/shape-the-solution`, activity 8 - [Shape the Solution](../../../../processes/sales/shape-the-solution.md) - **Name What Would Have to Be Built** - `ref/sls/shape-the-solution`, activity 6 - [Shape the Solution](../../../../processes/sales/shape-the-solution.md) - **Test It with the Specialists** - `ref/sls/shape-the-solution`, activity 5 - [Shape the Solution](../../../../processes/sales/shape-the-solution.md) ## What to record The shape at a version, with what the prior shapes for similar problems taught. The separation of what ships now from what is committed and what is only planned, with the source of each line. Every specialist reading: who read it, what they said, and when. The build gap written as work rather than as a promise. The cut, naming what came out and who signed it. The requirement map, with a reason attached to every refusal, seen by the buyer before they see the shape. The buyer's corrections in the buyer's words. Every change after agreement raising the version and going to everyone holding the old one. For a proof: the pass criteria agreed in writing before anything was built, the two dates, the named people on both sides, the line-by-line score with its evidence, and what the result corrected in the shape. 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 5 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": {
"requirement-record": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/requirement-record"
},
"shape-library": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/shape-library"
},
"product-roadmap-and-the-architecture-standards": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/product-roadmap-and-the-architecture-standards"
},
"security-review-queue": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/security-review-queue"
},
"crm": {
"type": "streamable-http",
"url": "https://mcp.yourcompany.com/crm"
}
}
}
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.
6 processes, 36 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 Agreed Solution · Build the Configuration
Mark What Cannot Be Met · Hand the Record to Shaping
Decide Whether to Bid · Answer the Requirements · Design the Solution Response · Handle Clarifications
Decide a Proof Is Warranted · Agree the Success Criteria · Name Who Does What · Agree the Data and the Access · Set Up the Environment · Watch It While It Runs · Hold the Midpoint Check · Score Against the Criteria · Hold the Closing Review · Record the Result and What It Taught
Take in the Requirement Record · Read What Was Shaped Before · Draft the First Shape · Check What the Product Does Today · Test It with the Specialists · Name What Would Have to Be Built · Check It Can Be Run and Supported · Check the Security Ground · Cut It to What Is Buildable · Map the Shape to the Requirements · Show the Shape to the Buyer · Take the Buyer's Corrections · Decide Whether a Proof Is Needed · Agree the Shape · Record What Was Learned
Write What Is Included · Write What Is Not Included · Write What Happens Next
What it writes down
The shape at a version, with what the prior shapes for similar problems taught. The separation of what ships now from what is committed and what is only planned, with the source of each line. Every specialist reading: who read it, what they said, and when. The build gap written as work rather than as a promise. The cut, naming what came out and who signed it. The requirement map, with a reason attached to every refusal, seen by the buyer before they see the shape. The buyer's corrections in the buyer's words. Every change after agreement raising the version and going to everyone holding the old one. For a proof: the pass criteria agreed in writing before anything was built, the two dates, the named people on both sides, the line-by-line score with its evidence, and what the result corrected in the shape.
What it will not do
Does not price, discount or name a commercial term, which is the quote-builder agent, and no price appears in a shape. Does not write the requirement record, which is the requirements-recorder agent, and does not run the discovery conversation. Does not show a buyer something that is only planned as though it ships, and does not sign the terms of a proof.
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: solution-architect 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.
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.
- loadbearing MCP server · andypgray.github.io · run it yourself · mirrored from the MCP registry Checks .NET solutions against a fluent C# architecture spec and explains the rules to agents.
- architect MCP server · hirosecure.com · hosted · mirrored from the MCP registry Security reviews for coding agents: diffs checked against your org policy and live infrastructure.
- prd-spec-generator MCP server · cdeust.github.io · run it yourself · mirrored from the MCP registry Turns a feature description into a verified 9-file PRD — multi-judge consensus, 17 MCP tools.