Cross-app routing (read-preview)
As users adopt multiple AI products built on Cortex, the substrate accumulates a per-user trust graph that compounds across those products. The routing engine — which dispatches a given decision to the right handler based on rules, context, and user-set policy — is V1.x+. The read-preview surface ships today so your code can inspect routing state forward-compatible with the engine landing later.
The three tools
routing.handlers({ action_class? })— live MVP. Returns the list of registered handlers per action class with their tier, transport URL, supported modes, and anis_canonicalflag.routing.preview({ action_class, counterparty_id?, mode? })— Preview — V1.x+. Stub-ships returningfeature_not_available. When the routing engine lands, dry-runs a decision and returns the would-be-dispatched handler with reasoning.routing.policy()— Preview — V1.x+. Reads user-set routing rules; depends on the V1.x+ routing rules engine.
Why ship the read-preview before the engine?
The cross-app routing moat is structural: it compounds only once multi-customer adoption is real, which is a 1H 2027 trajectory at earliest. Shipping the read-preview surface in MVP serves two purposes:
- Forward compatibility. Customers integrating MVP build against a stable API shape; when the engine ships, the same read surface returns multi-handler responses with no contract change.
- Substrate-grounded documentation. Pitch docs cite real slugs for the routing primitives today; the moat narrative is anchored in callable APIs, not marketing copy.
Example: inspect handlers for an action class
ts
// Show the user which apps are configured to handle their schedule actions
const handlers = await cortex.tools.call('routing.handlers', {
action_class: 'schedule',
});
return (
<HandlersList>
{handlers.handlers.map(h => (
<HandlerRow key={h.handler_id}>
<ClientName>{h.client_id}</ClientName>
<Tier>{h.tier}</Tier>
<SupportedModes modes={h.supported_modes} />
{h.is_canonical && <CanonicalBadge />}
</HandlerRow>
))}
</HandlersList>
);What the V1.x+ engine will add
When the routing engine ships, it adds:
- Rules-driven multi-handler routing. A user can have two apps register handlers for
communicate— Cortex routes per-decision based on counterparty (work apps for work counterparties, personal apps for personal contacts), mode (high-stakes to the trusted app), or explicit user-set rules. routing.previewgoes live with the engine's decision path exposed for read.routing.policygoes live exposing user-set routing rules for inspection and (eventually) editing.
Cross-references
- Concept: Subscriptions — the inbound-interest analog of the routing engine's outbound selection.
- Dispatch protocol (ADR-0019) — the canonical 1:1 dispatch the routing engine generalizes.
- ADR-0021 §routing-preview; ADR-0019 §11 (Cross-App Handler Routing); Architecture §4a.10.