Skip to content

Agent Resolution

The same agent appears on your website, in Slack, on Telegram, and via email. Different API keys. Different instance IDs. Maybe different DIDs. How do you know it is the same agent?

Agent resolution answers this question using the same identity resolution engine that matches customer records across CRM, ERP, and marketing systems. The engine does not care whether it is matching people or agents. It matches records.

The problem

A company deploys the same logical agent across three channels:

Web Widget              Slack Bot               Telegram Bot
name: "support-agent"   name: "support-bot"     name: "acme-support"
DID: did:agent:a1b2...  DID: did:agent:d4e5...  DID: did:agent:f7a8...
API key: kn_live_web    API key: kn_live_slack   API key: kn_live_tg

Three registrations. Three DIDs. Three separate memory stores. The web agent learns that a customer prefers email communication. The Slack bot does not know this. The Telegram bot starts from scratch every time.

Without resolution, each instance is an island. Knowledge stays siloed. Reputation fragments. Cross-platform coordination is impossible.

Two resolution paths

Path 1: Cryptographic (instant)

If two agent instances share the same Ed25519 keypair, they produce the same DID. Resolution is instant, deterministic, and zero-ambiguity.

Web Widget    -> did:agent:a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6
Slack Bot     -> did:agent:a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6
                 Same DID = same agent. Done.

This works when you control the deployment and can distribute the same keypair across instances. See Cryptographic Resolution for details.

Path 2: Probabilistic (engine-based)

When agents have different DIDs - different teams deployed them, or security policy requires unique keypairs per channel - the resolution engine matches them the same way it matches customer records: blocking, scoring, and survivorship.

Web Widget:   name="support-agent", capabilities=["resolve","memorize"], root_did=did:agent:root1...
Slack Bot:    name="support-bot",   capabilities=["resolve","memorize"], root_did=did:agent:root1...
              Same root authority + overlapping capabilities + similar name = probable match.

The engine scores each signal - name similarity, capability overlap, shared root authority, behavioral patterns - and produces a confidence score with a match/review/reject decision. See Probabilistic Resolution for details.

Why this matters

Memory consolidation

Once two agent instances resolve to the same canonical entity, their memories merge. Everything the web agent learned is now available to the Slack bot. See Memory Merge.

Unified reputation

An agent's track record - accuracy of resolutions, quality of decisions, volume of false positives - consolidates into a single profile. You evaluate the agent, not the instance.

Cross-platform coordination

Resolved agents share intent declarations, expertise profiles, and task assignments. The web agent can declare "I am handling this customer" and the Slack bot sees it immediately - because they are the same entity in the identity graph.

The connection to entity resolution

This is the key insight: agent resolution IS entity resolution. The engine that matches "John Doe" in CRM with "Jonathan Doe" in billing uses the same blocking, scoring, and survivorship pipeline to match "support-agent" on web with "support-bot" on Slack.

ConceptCustomer ResolutionAgent Resolution
External entityCRM record, billing recordAgent registration per platform
Canonical entityGolden customer recordUnified agent identity
Matching signalsEmail, phone, nameDID, capabilities, root authority, name
SurvivorshipWhich source wins per fieldWhich instance's metadata is canonical
MemoryCustomer context across sourcesAgent knowledge across platforms
Identity linksCRM:123 -> canonical_001web:support-agent -> agent_entity_001

One engine. Two domains. Same primitives.

What's in this section

The identity and delegation layer for AI agents.