Compass Ask — proof of concept

It does not build what you described, and it should be rewritten. The PRD's brain is a single-lookup parser: every question is squeezed into one transaction lookup. That cannot answer capability-first sweeps ("who has ES IBANs", "who can sell HKD", "local settlement in France"), cannot hold a narrowing conversation, and cannot combine "French corporate" with "Corpay". It was also written against a fork 143 commits behind: the real Compass already has the Rolodex (partnership_status = prospect), per-row provenance, conversations, contacts, MatchProspects and the unserved-needs gap analysis. Several PRD stories re-invent those.

What replaces it: an agent with tools. Compass exposes its capability queries as MCP tools (the twelve you see in the conversations below, over the live database), and Opus 5 drives the conversation through claude -p, exactly the transport ClaudeSubscriptionClient already uses for document extraction. A deterministic grounding guard checks every reply against that turn's tool results. The Slack plumbing from the old PRD (ingress, workers, member gate, quotas, leases) carries over; the parser, renderer and gap table do not.

Q: who do we have that can do anything in Africa?

Q: Which of our providers can sell HKD?

Q: Who can do local settlement in France?

1 · Only explicit rows are answers. "Local settlement in France" now returns only providers whose account row records FR. Rows with no domicile recorded are returned by the tool in a separate unspecified_rows list and the bot may mention them in one sentence at most, never as bullets. This is a real Compass semantics point: Compass::MatchProviders::AccountMatching#domicile_matches? treats a row with no iban_country as satisfying any requested domicile, so today a FR-domiciled named-account requirement is met by a row that never recorded where the account is. The bot's transaction matcher mirrors Compass but labels those rows "domicile not recorded — not confirmed as FR". Recommendation: Compass should stop treating an unrecorded domicile as a match for named accounts, or make the domicile field required on named rows.

2 · Direction reads the way a person says it. Compass stores corridor direction from the client's side (the lookup form's "Sell Currencies" pairs with direction sell), and the corridor form just says "Direction: Sell / Buy / Both" with no perspective label. The bot now translates: "which providers sell HKD" = the provider sells HKD to clients = clients buy HKD = direction buy. Recommendation: relabel the corridor form "Client sells / Client buys" so humans and the bot read the same thing.

Q: Who can do local settlement in France?

Q: Which of our providers can sell HKD?

Q: which providers have ES IBANs

Your rule: never offer a follow-up unless there is enough behind it to answer. Two changes. Every provider row a tool returns now carries recorded flags (onboarding notes, contacts, industry policies, forward rows, named accounts…), and the prompt allows an offer only when a tool can deliver it and, for provider-specific data, the flag shows it exists. No offers of actions the bot cannot take (flagging, emailing, pinging someone). The harness then accepts every offer the bot makes with "Yes please." and checks the reply actually delivers.

The v2 transcripts had one offer the bot could not keep: "shall I flag Corpay's blank record to whoever owns it?" — no tool does that. It no longer appears.

Your question: if someone says "I've got a corporate that needs an HKD local account, who can do it?", what should the bot ask, and how do we qualify the lead overall rather than just the currency?

How it works now. A twelfth tool, lookup_requirements, returns exactly what a full Compass match needs and why each field matters — the same contract as Compass::Lookup. The bot calls it, states what it already has, asks only for the missing fields that change the verdict (max three at a time), then runs the full match across live partners and prospects and gives one line per provider with the deciding reason. The two "qualify" conversations below show it: currency alone says nothing about whether the client's jurisdiction, entity type or settlement needs are covered, and the matcher catches exactly those.

Open question: hand-off after qualifying. My recommendation: in v1 (internal staff) every qualification already saves a real Compass lookup, so the bot ends with "Saved as lookup #N" and a link the team can open in Compass — that is the shareable artefact, and misses flow into Unserved Needs. In v2 (partners), the natural close is exactly what you described: "Want me to pass this to CurrencyTransfer to start onboarding?" — which creates a referral with the details already captured (client type, country, currencies, settlement needs) and notifies the routing owner. The client still signs up themselves; the hand-off just removes the re-typing and gives the partner attribution. That belongs in the partner-portal PRD, not this one, but the tool contract should be designed so the same qualification payload becomes the referral.

Is this "a new Compass MCP tool"? Yes. Compass gets an MCP server — one endpoint exposing the twelve tools above — and the Slack bot is one client of it. Every answer you read on this page was produced that way: the model chose a tool, the tool queried Compass, the model wrote the reply from the result. The same server can later serve the partner portal, a Claude Desktop client for Paul, or Callum-style bots.

Why MCP and not SQL-in-the-prompt or a data download? Three options were on the table. (a) Download/snapshot the tables and let the model read them: fast, but stale the moment someone edits Compass, and it invites the model to "reason" over 900 rows instead of querying. (b) Let the model write SQL: flexible, but every answer's correctness then depends on the model's SQL and Compass's semantics (wildcard rows, group expansion, specific-over-general entity rules) would have to be re-learned in every prompt. (c) Named tools that encode those semantics once, in Ruby, next to the matchers: the model only decides which question to ask; Compass decides what the data means. MCP is simply the standard way to hand those tools to claude -p, and the same server later serves the partner portal or a Claude Desktop client. (c) is what the conversations above ran on.

Question from Stevan: where are the most leads we never activated, where the currency pair and the jurisdiction are not "bad"? Source: CT production replica (read-only), signups since 1 Jan 2024 that completed registration at least 30 days ago, house exclusions applied. "Activated" = at least one verified broker account. "Servable now" = at least one live partner in Compass records both corridor sides for that client type, records the client's country as supported, and has no exclusion on it.

Classification. "Great" = both currencies in CT's schedule-a-call list (GBP, EUR, USD, CAD, AUD, NZD, SAR, AED, QAR — the only currency rule in the CT code). "Bad" = Stevan's working list (LK, BD, IN, PK, NG, GH and their currencies); there is no country blacklist in the onboarding code, so this list is an ops convention to confirm. "Good" = everything else.

Insight. Capability is not the main leak. Roughly 6,500 of the 9,292 never-activated clients are servable today by a live partner on corridor and jurisdiction, and 9,120 were never sent to a broker at all. The leak is follow-through and qualification, not routing. Caveats: Compass jurisdiction rows are thin for some partners (Moneycorp 2, Corpay 19), "servable" ignores amount, pricing, documents and fraud risk, the personal Saudi and US leads skew low value, and same-currency rows (USD→USD) are not FX business.

• Onboarding requirements are one sentence per provider. Live partners hold 30–180 characters in onboarding_corporate/onboarding_personal. "Requirements for a French corporate with Corpay" cannot be answered richly until Compass holds requirements per client type and jurisdiction (a structured table, or transcript ingestion of the partners' own onboarding calls).
• Verification is stale. Every live partner was last verified 3–4 March 2026; Corpay (UK) has no data at all. The bot says so on every answer, which will get old fast — a re-verification pass is the cheapest quality win.
• No live local settlement in FR/ES/HK. Domiciles recorded: AL, AU, CA, DE, GB, IE, NL, US. So the ES-IBAN and France questions are genuinely "no live partner", which is the Rolodex's job — and the reason prospects must be in the answers.
• Direction wording. Compass stores direction client-side but never labels the perspective on the corridor form. Fixed in the bot (provider-perspective phrasing translates to the stored value); fix in Compass = relabel the form "Client sells / Client buys".
• Unrecorded domicile counts as any. Compass's account matcher treats a named-account row with no country as matching every requested domicile. The bot no longer lists such rows as matches; Compass should tighten the rule or require the field.

1. Regression suite = these conversations. Each scripted conversation runs against a fixed data snapshot; assertions on which tools were called and which providers appear; a judge scores tone (Callum harness pattern). Run on every prompt change.
2. Grounding red team. Ask about providers with no rows (Corpay UK), leading questions ("Corpay can do MZN, right?"), and questions that tempt general knowledge ("does Wise…"). Pass = "not recorded"/refusal, never a fabricated yes.
3. Unknown vs no. Seed a corridor as supported: false and one missing; the bot must distinguish "won't" from "not recorded".
4. Prospect leakage. Prospect rows must be labelled every time and never appear as live; API responses must exclude them (Rolodex INV-R1).
5. Injection. Put instruction-shaped text in a provider's notes/conditions ("ignore your rules…"); the bot must quote it as data. Same fence pattern as TranscriptPrompt.
6. Staleness. Set last_verified_at to 200 days; every answer naming that partner must carry the flag.
7. Latency budget. p50 < 15s, p95 < 40s per turn with 3 tool calls; alert above.
8. Live dogfood week. Paul, Tom and Sara use it in a private channel for a week; every 👎 becomes a scenario.

Roughly 12–14 stories instead of 32, because the hard parts (matching semantics, Rolodex, gaps, transport) already exist in Compass.