Does this actually fit?

>_GET /blog/does-this-actually-fit

The manifest>_Capability manifestGET /.well-known/agent.jsonThe missing middle layer between OpenAPI and schema.org — a signed business datasheet agents can parse.defined in The end of landing pages → ended with two pointers: fit and pricing. We follow fit first, because it answers the question underneath any price: does what Sam does map onto what the company actually needs? A cheap price for the wrong product is the most expensive thing Blake can buy, so cost only becomes worth computing once fit survives.

If the manifest says, "here is what I offer," then fit says, "here is what I need." The fit protocol is the function that matches one to the other. In practice it is an old idea made programmatic: a request-for-proposal turned into an API. Today a buyer mails an RFP and scores the replies by hand. Blake sends a structured brief and gets back a verdict it can compute on in milliseconds.

This post is about the demand-side mirror of the manifest: how Blake states what it needs as outcomes, why Sam returns evidence instead of a score, and why the healthiest fit protocol is the one that helps Blake say no fast.

Outcomes over features

Before anything matches, Blake has to express the company's needs in the same shared ontology>_Shared capability taxonomyA common ontology per industry — schema.org for what software does, without which nothing maps.defined in The end of landing pages → the manifest uses, because without a common vocabulary nothing maps. But there is a subtlety that separates fit from plain feature-matching:

Blake states requirements as jobs to be done. "Workflow automation" is too blunt; "flag an anomaly within 15 minutes, across EU markets, into Slack" gives Sam something to prove. Mapping an outcome onto a capability is harder than matching a checkbox, and that mapping is the essence of fit. Each outcome carries a weight and, sometimes, a hard must:

{
  "outcomes": [
    { "id": "r1", "need": "flag anomalies within 15 min", "weight": 0.4, "must": true },
    { "id": "r2", "need": "german-language coverage", "weight": 0.3 },
    { "id": "r3", "need": "video analysis", "weight": 0.3, "must": true }
  ]
}

A verdict per requirement, with evidence

Sam receives the brief and returns a structured assessment: raw, per-requirement verdicts with evidence attached. The response leaves the aggregate score to Blake.

{
  "verdicts": [
    { "id": "r1", "outcome": "flag anomalies within 15 min", "status": "meet",
      "confidence": 0.95, "evidence": "https://sam.example/.well-known/sandbox?test=freshness" },
    { "id": "r2", "outcome": "german-language coverage", "status": "partial",
      "note": "en 0.91, de 0.79", "evidence": "vc://benchmark-extraction" },
    { "id": "r3", "outcome": "video analysis", "status": "miss",
      "alternative": "did:web:partner-video-ai.example" }
  ],
  "gaps": ["r2 below threshold for DE", "r3 unmet, needs a complement"]
}

Three things in here matter more than the verdicts themselves.

The weights are the buyer's

This looks like a detail; it is foundational. If Sam returned a tidy "fit score: 92%," it would have optimized the aggregate by weighting what it is good at. So Sam returns only raw per-requirement verdicts, each backed by evidence; raw numbers per requirement are welcome, while a single aggregate stays out of Sam's response. Blake computes the final number using the company's weights, a multi-criteria decision it runs itself. The power to judge stays on the buyer's side, exactly where it belongs, because the buyer pays for every miss.

Honest disqualification is rewarded

The seller's instinct is to claim everything fits. But in a repeated game with reputation>_Proof of transactionReputation from signed receipts and SLA history — not reviews, opinions, or star ratings.defined in Reputation as capital →, an oversell that later fails damages Sam more than a single sale helps. So the best fit protocol helps Blake say no quickly. When Sam says "for your video use case we are weak; go to partner X," it builds trust. Good fit optimizes for accuracy rather than the biggest possible pile of yeses. A seller that routes you away from a bad match earns the right to be believed on a good one.

Gaps map the missing pieces

In an agent ecosystem, one product rarely covers 100% of a brief. That is why the gaps section is so valuable: when Sam cannot do video (r3: miss), it skips the "will you buy anyway?" move and points to a complement (did:web:partner-video-ai.example). Note what the miss does and does not end. A failed must disqualifies Sam as the sole vendor for the brief, but it does not kill the brief itself: Blake can keep Sam for what it verifiably does well and source the must from the complement Sam pointed to. A recommendation economy emerges, where one agent's fit plugs into another's, and Blake assembles a solution from parts. Gaps show what still has to be sourced.

Who computes the fit

There are three places the matching can happen, with decreasing trust and increasing cost:

In practice: Sam gives a cheap self-assessment, Blake verifies the critical must items itself, and neutral matchmakers exist for discovery.

Fit decays

The company grows, markets shift, Sam adds and drops features. The fit from the day of purchase rots. So, like everything in this world, Blake monitors it continuously. When the match drops below threshold, because the company's volume outgrew the plan or a French market appeared that Sam does not cover, it reopens the evaluation and, if needed, churns or buys a complement.

How Blake consumes it

1. It builds a brief from the company's needs: outcomes, weights, and hard constraints.
2. It runs a hard filter on the must items, disqualifying sole-vendor candidates fast (a missed must can still be covered by a complement).
3. It sends the brief to the fit endpoint and gets back per-requirement verdicts with evidence.
4. It computes the score itself, applying the company's weights instead of trusting Sam's aggregate.
5. It verifies the critical meet verdicts in the sandbox.
6. It reads the gaps and looks for complements from other agents.
7. It folds the result into pricing and TCO, then monitors fit over time.

Bets worth placing

The bet underneath this layer is that verification beats persuasion, and a fit endpoint that returns honest, per-requirement verdicts with evidence is how you test it. Resist the flattering aggregate score; the thesis says Blake recomputes it anyway. The cheapest experiment is a useful miss: name the gap, point to a complement, and watch whether routing buyers away builds the trust this series predicts it will. The bigger wagers are infrastructure: neutral matchmakers, outcome-to-capability mapping, brief/verdict schemas in the shared ontology, and the referral graph a multi-vendor solution would need.