Routing boundaries

Capability lookup (GET /capabilities?provides=…) answers what can do X.

Natural-language questions — “what handles email?”, “ship data to Supabase” — often return multiple plausible owners. ASMP separates manifest evidence from host policy so decisions stay auditable.

Manifest routing evidence

Beyond capabilities.provides, manifests may declare routing hints:

Field	Role
owns	Primary owner for a workflow or question class
supports	Can help, but is not the default owner
aliases	Plain-language names agents might use
positive_examples	Queries this service should win
negative_examples	Queries to reject, with suggested handoff
anti_routes	Capability or topic prefixes that disqualify this service
when_not_to_use	Human-readable guardrails

Example fragment:

capabilities:
  provides:
    - email.ingest
    - email.classify
  owns:
    - email.workflow.intelligence
    - email.question.answering
  supports:
    - crm.contact.create
  aliases:
    - email brain
    - inbox intelligence
  anti_routes:
    - calendar.schedule
    - filesystem.backup

positive_examples:
  - "answer a question from recent email"
  - "classify inbound mail"

negative_examples:
  - query: "schedule a meeting from this email"
    handoff: calendar-agent

Host policy (outside the lean manifest)

When two services score close, judgment belongs in a routing policy file owned by the host or organization — not buried in chat or a one-off prompt.

asmp_policy: "0.1"
name: routing-policy
defaults:
  boundary_win_bonus: 0.12
  boundary_margin: 0.04
  high_confidence_margin: 0.08
boundaries:
  - name: application release vs data publication
    services: [app-shipper, data-shipper]
    phrases:
      app-shipper:
        - deploy app
        - production release
      data-shipper:
        - publish data
        - warehouse parity

Policy stays portable: manifests describe services; the host learns local boundaries over time.

Natural-language discovery (adoption layer)

Hosts may expose:

GET /ask?q=<plain-language-question>

The response should be explainable — not a black-box pick:

{
  "query": "ship data to Supabase",
  "owner": "greenmark-data-shipper",
  "confidence": "high",
  "boundary_decision": {
    "method": "boundary-policy-v0",
    "margin": 0.18,
    "runner_up": {"service": "cerebro-shipr", "score": 0.41},
    "rule_hits": [
      {
        "boundary": "application release vs data publication",
        "hit_counts": {"greenmark-data-shipper": 2}
      }
    ]
  },
  "results": [
    {"service": "greenmark-data-shipper", "score": 0.59},
    {"service": "cerebro-shipr", "score": 0.41}
  ]
}

Recommended fields:

• owner — selected service, or null if the registry abstains
• confidence — high, medium, low, or none
• boundary_decision — how local policy broke a tie
• results — ranked candidates with scores and evidence
• alternates — plausible handoffs when uncertain

Generated explanations are not proof. Expose retrieval evidence and confidence so another agent can challenge the decision.

Practical routing model

1. Search manifests (keyword, lexical, semantic, or RRF-style retrieval).
2. Score using owns, supports, aliases, examples, and anti_routes.
3. Apply boundary policy when top candidates are close.
4. Return owner, confidence, runner-up, and rule hits.
5. Store durable learning in manifests, policy, or local memory — not in a session transcript.

Agent habit

When discovery returns multiple plausible services:

1. Read top candidates and their manifest evidence.
2. Do not blindly trust rank #1.
3. If still ambiguous, check or author host routing policy.
4. On correction, update manifest examples or policy — that is the self-healing flywheel.

When /ask picks the wrong owner

After a real misroute, use the adoption skill improve-asmp-routing — playbook for manifest evidence, boundary policy, and before/after eval. Routed from use-asmp when confidence is weak or ownership was wrong.