There is a question that every autonomous agent must answer before it can do anything useful in the world, and it is not the question most people expect. It is not "what should I do?" or "what does my principal want?" or even "can I be trusted?" The question is simpler, more fundamental, and far harder than it appears: who am I looking at?
When a machine customer arrives at a financial services API to execute a transaction on behalf of its human principal, it encounters data. Lots of data. A name in one system, an address in another, a transaction history in a third, a credit profile in a fourth. The name is spelled differently across two of those systems. The address was updated in one but not the others. The transaction history contains records from an account that was merged three years ago. The credit profile references an entity that may or may not be the same person. Before the agent can assess risk, verify authority, negotiate terms, or execute a single transaction, it must answer the foundational question: do these records refer to the same real-world entity?
This is entity resolution. And in the age of agentic commerce, it is not a data management problem. It is the identity infrastructure upon which every other capability depends. Without it, trust architecture has no subject. Delegation design has no principal. Know Your Agent has no agent to know. Entity resolution is the layer beneath the layer - the foundation that makes the entire edifice of agentic experience design possible. It is the prerequisite for agent legibility and a critical infrastructure challenge in B2B agentic commerce.
The Stranger Problem
Consider a scenario that is already occurring in financial services. A personal finance agent - deployed by a consumer to optimise their banking relationships - contacts three different institutions to compare mortgage rates. At Institution A, the consumer is recorded as "J. Smith, 14 Oak Lane, Manchester." At Institution B, the same person appears as "James A. Smith, 14 Oak Ln, M14 5TQ." At Institution C, the records show "Jim Smith" at an address that was current two years ago. The agent must determine, with high confidence, that these three records represent the same human principal - its delegator - before it can aggregate the data, compare the offers, and act on the consumer's behalf.
This is not a trivial matching exercise. The variations are not errors - they are the natural consequence of data being created independently across multiple systems over time. Every enterprise, every institution, every government department faces the same problem: their data about real-world entities is fragmented, inconsistent, and incomplete. Jeff Jonas, the pioneer of entity resolution technology, frames the core challenge with two deceptively simple questions: who is who, and who is related to whom? For most organisations, the honest answer is: we do not reliably know.
When humans navigate these systems, they compensate. A bank clerk recognises that "J. Smith" and "James Smith" at similar addresses are probably the same person. A customer service representative can ask clarifying questions. A fraud analyst can apply contextual judgement. But autonomous agents do not have the luxury of "probably." They operate at computational speed, across multiple systems simultaneously, making decisions that have real financial and legal consequences. An agent that misresolves an entity - treating two different people as one, or one person as two - does not make a minor data quality error. It makes a trust-destroying, potentially liability-creating mistake.
"Entity resolution is not a data hygiene exercise. It is the identity substrate upon which every act of agentic trust, delegation, and commerce depends."
The stranger problem - the state in which every record is a stranger until proven otherwise - is the default condition of enterprise data. And it is the condition that agentic systems must overcome before they can function. This essay argues that entity resolution is not merely a technical prerequisite for agentic commerce but a design discipline in its own right - one that sits at the intersection of trust architecture, signal clarity, and agent identity verification, and that demands the attention of every organisation preparing for the agentic economy.
What Entity Resolution Means
Entity resolution - also known as entity matching, record linkage, or identity resolution - is the process of determining when different data records refer to the same real-world entity. That entity might be a person, an organisation, a product, a location, or, increasingly, an autonomous agent. The discipline answers two fundamental questions: given a set of records, which ones describe the same entity? And given two entities, what is the relationship between them?
Traditional entity resolution emerged from the practical needs of census bureaus, intelligence agencies, and healthcare systems - domains where the consequences of misidentification range from wasted resources to existential risk. The techniques evolved from simple deterministic matching (exact string comparison) through probabilistic matching (statistical likelihood of sameness) to modern machine-learning approaches that can handle fuzzy, incomplete, and contradictory data at scale.
But the agentic era demands something fundamentally different from entity resolution. Legacy systems were designed for batch processing - periodic reconciliation of data warehouses, overnight deduplication runs, quarterly data quality audits. Agentic systems operate in real time. A machine customer arriving at a commerce API needs identity intelligence now - not after an overnight batch process. An agent negotiating a contract needs to know whether the counterparty entity in System A is the same entity it evaluated in System B during the negotiation, not after it concludes.
This temporal shift - from batch to real-time, from periodic to perpetual - is what transforms entity resolution from a data management function into an identity infrastructure requirement. In the agentic economy, entity resolution is not something you do to your data periodically. It is something your systems must do continuously, at the speed of autonomous action, with consequences that compound with every millisecond of latency.
The Three Domains of Agentic ER
Agentic entity resolution operates across three distinct domains, each with its own challenges, stakes, and design implications. Understanding these domains is essential for any organisation building infrastructure for the agentic economy.
The first domain is Agent-to-Entity Resolution - how autonomous agents determine the identity of the real-world entities they encounter. When an agent queries a product catalogue, a customer database, or a regulatory registry, it must resolve the records it receives into coherent entities. This is the domain most closely aligned with traditional entity resolution, but operating under the new constraints of real-time speed and autonomous decision-making.
The second domain is Entity-to-Agent Resolution - how businesses and institutions determine the identity of the agents that interact with them. When a machine customer arrives at a commerce API, the receiving system must resolve: which agent is this? Which principal does it represent? Is this the same agent that interacted with us yesterday, or a different agent representing the same principal? This domain intersects directly with Know Your Agent (KYA) - but where KYA focuses on verification and authorisation, entity resolution focuses on the prior question of identification.
The third domain is Cross-Agent Entity Consensus - how multiple agents operating in the same ecosystem agree on entity identity. When Agent A and Agent B are both acting on behalf of the same principal, or when they are negotiating with the same counterparty, they need a shared understanding of entity identity. Without consensus, the same person might be treated as two different entities by two different agents, leading to contradictory actions, duplicated transactions, and trust failures that cascade through the entire trust triangle.
Agent-to-Entity Resolution
When an autonomous agent operates in the world - comparing insurance providers, evaluating suppliers, or managing a portfolio - it encounters entities represented as data. The quality of every subsequent decision depends on the agent's ability to resolve that data into accurate, coherent entity representations. This is agent-to-entity resolution, and it is the most computationally demanding of the three domains.
Consider a procurement agent tasked with finding the optimal supplier for a manufacturing component. It queries five different supplier databases, three industry registries, and two compliance platforms. The same supplier appears under slightly different names - "Precision Components Ltd," "Precision Components Limited," "PrecisionComp Ltd" - with different registration numbers across jurisdictions, different addresses reflecting office moves over the past decade, and different contact details reflecting staff turnover. The agent must resolve these records into a single, coherent entity profile before it can evaluate the supplier's reliability, compare pricing, or initiate a negotiation.
The stakes of misresolution in this domain are significant. A false positive - incorrectly merging two different entities into one - could lead an agent to attribute one company's poor compliance record to another. A false negative - failing to recognise that two records represent the same entity - could cause an agent to evaluate the same supplier twice under different names, wasting computational resources and potentially creating contradictory recommendations. In financial services, where the AXD readiness challenge is most acute, misresolution can trigger regulatory violations, duplicate KYC processes, or - in the worst case - enable fraud by allowing bad actors to present fragmented identities that individually pass verification but collectively reveal suspicious patterns.
"An agent that cannot resolve entities cannot build trust. It is operating in a world of strangers - and strangers do not get delegated authority."
The design implication for AXD practice is clear: agent-to-entity resolution must be treated as a first-class capability in any agentic system design. It is not a preprocessing step that happens before the "real" work begins. It is the continuous, real-time identity intelligence that enables every other capability - from trust assessment to operational envelope enforcement to consent verification. An agent without entity resolution capability is an agent operating blind.
Entity-to-Agent Resolution
The second domain reverses the direction. When a business receives an interaction from an autonomous agent, it faces its own resolution challenge: identifying the agent. This is not the same as authentication - which verifies that an agent is who it claims to be - but the prior question of determining which entity this agent represents in the business's own systems.
A retail bank receives an API call from an agent requesting mortgage rate information on behalf of a customer. The agent presents credentials - a mandate token, a principal identifier, perhaps a Verifiable Digital Credential. But the bank must still resolve: does this principal match an existing customer? If so, which customer record? The principal identifier in the agent's credential may not match the customer ID in the bank's CRM. The name may be formatted differently. The address may have changed since the customer last interacted directly with the bank.
Entity-to-agent resolution becomes even more complex when multiple agents represent the same principal. A consumer might deploy a personal finance agent from one provider, a shopping agent from another, and an insurance comparison agent from a third. Each agent presents different credentials, uses different protocols, and identifies the principal in different ways. The business must resolve all three interactions to the same customer entity - not because the agents coordinate (they may not), but because the business needs a unified view of the customer relationship regardless of which agent is acting on the customer's behalf.
This is where entity resolution intersects with the trust triangle. In the triadic relationship between human, agent, and business, the business must resolve the identity of both the agent and the principal. A failure to resolve the principal means the business cannot apply the correct customer context - pricing tiers, loyalty benefits, risk profiles, regulatory obligations. A failure to resolve the agent means the business cannot apply the correct KYA verification level or track agent behaviour over time.
"In the agentic economy, your customer does not arrive with a face. They arrive as a data payload. Entity resolution is how you recognise them."
The design challenge is substantial. Businesses must build entity resolution capabilities that can match incoming agent interactions to existing customer records in real time, handle multiple agent representations of the same principal, and do so without creating friction that drives agents to competitors. The institution that resolves entity identity in milliseconds earns the agent's continued engagement. The institution that requires manual reconciliation loses the interaction entirely - because agents, unlike humans, have zero tolerance for waiting.
Cross-Agent Entity Consensus
The third domain is the most novel and, in many ways, the most consequential. As multi-agent architectures become the norm - with specialised agents collaborating to complete complex tasks - the question of shared entity identity becomes critical. If a research agent identifies a supplier and passes that information to a procurement agent, both agents must agree on which entity they are discussing. Without consensus, the procurement agent might negotiate with a different entity than the one the research agent evaluated.
The agentic protocols - MCP, A2A, and ACP - provide the communication infrastructure for multi-agent collaboration. But communication infrastructure without shared identity resolution is like a telephone network where every caller uses a different name for the same person. The protocols can transmit information, but they cannot guarantee that the information refers to the same real-world entity unless there is a shared resolution layer.
Cross-agent entity consensus requires what might be called an entity resolution graph - a shared, continuously updated representation of resolved entities that multiple agents can reference. This is not a centralised database (which would create a single point of failure and a privacy nightmare) but a distributed resolution protocol that allows agents to query: "Is the entity I am calling X the same entity you are calling Y?" The answer must be probabilistic, explainable, and auditable - because in regulated domains, the chain of reasoning that led to an entity resolution decision must be as traceable as the chain of delegation that authorised the agent's actions.
The implications for agent observability are significant. When an agent makes a decision based on resolved entity data, the resolution itself becomes part of the audit trail. A regulator asking "why did this agent execute this transaction?" needs to see not only the agent's reasoning but the entity resolution that informed it. "We believed Entity A and Entity B were the same organisation because of these matching attributes, with this confidence level, resolved at this timestamp" becomes a required component of the observability record.
The Resolution Cascade
Entity resolution in agentic systems does not happen in a single step. It follows what we might call a resolution cascade - a layered process that moves from raw data matching through identity verification to trust establishment. Each layer depends on the one beneath it, and a failure at any layer propagates upward through the entire stack.
The first layer is data matching - the computational process of comparing attributes across records to determine potential matches. This is where traditional entity resolution techniques apply: string similarity algorithms, phonetic matching, address normalisation, and probabilistic scoring. The output is a set of candidate matches with confidence scores.
The second layer is identity verification - confirming that a candidate match represents a genuine identity correspondence rather than a coincidental similarity. Two people can share a name and a postcode without being the same person. Identity verification applies additional signals - behavioural patterns, transaction histories, credential verification, biometric data where available - to elevate a statistical match into a verified identity assertion.
The third layer is trust establishment - the point at which a resolved entity becomes a trusted participant in an agentic interaction. This is where entity resolution connects to trust architecture. A resolved entity is not automatically a trusted entity. Trust requires additional context: is this entity authorised to participate in this transaction? Does its history warrant the level of trust being extended? Are there risk signals that should modulate the trust level?
The resolution cascade makes explicit what is often implicit in discussions of agentic commerce: you cannot trust what you cannot identify, and you cannot identify what you cannot match. Every act of trust in an agentic system rests on a chain of resolution decisions, each of which carries its own confidence level, its own error rate, and its own implications for the decisions that follow. Designing for the resolution cascade means designing for the propagation of uncertainty - ensuring that confidence levels flow upward through the stack and that downstream decisions are calibrated to the resolution quality of the data they depend on.
Why Legacy ER Fails the Agentic Test
Most enterprise entity resolution systems were built for a world that no longer exists - a world of periodic batch processing, human-mediated exceptions, and tolerance for latency measured in hours or days. These systems fail the agentic test on at least four dimensions.
Speed. Legacy ER systems process records in batch cycles - nightly, weekly, or on-demand. Agentic systems need resolution in milliseconds. A machine customer querying a product catalogue cannot wait for an overnight deduplication run to determine whether two supplier records represent the same entity. The resolution must happen within the transaction window, which for autonomous agents is measured in sub-second intervals.
Adaptability. Legacy systems require extensive configuration for each new data source - weeks of expert tuning to define matching rules, thresholds, and exception handling. Agentic systems encounter new data sources dynamically. An agent exploring a new market or evaluating a new category of suppliers cannot wait for a data engineering team to configure the ER system for each new source. The resolution engine must be self-configuring - capable of profiling, mapping, and resolving new data formats without human intervention.
Explainability. Legacy ER systems produce match scores but rarely explain their reasoning in ways that are useful for downstream decision-making. In agentic systems, where resolution decisions feed into trust calculations, delegation authorisations, and regulatory compliance, the reasoning must be transparent. An agent - or the human auditing the agent's decisions - must be able to ask: "Why do you believe these two records represent the same entity?" and receive a structured, verifiable answer.
Continuity. Legacy ER systems treat resolution as a point-in-time activity. But entities change - people move, companies merge, names are updated, relationships evolve. Agentic entity resolution must be continuous and self-correcting. When new information arrives that contradicts a previous resolution - a change of address, a corporate restructuring, a corrected spelling - the resolution must update in real time, and every downstream decision that depended on the previous resolution must be re-evaluated. This is what Senzing's Jeff Jonas calls "perpetual resolution" - entity resolution that never stops learning, never stops correcting, and never stops updating.
The Trust Implications
Entity resolution is not merely a technical capability. It is a trust architecture requirement. Every principle of AXD - from delegation design to trust calibration to consent horizons - assumes that the identities of the participants are known. When entity resolution fails, trust does not degrade gracefully. It collapses.
Consider the trust implications of each failure mode. A false positive - incorrectly merging two different entities - means that trust earned by one entity is incorrectly attributed to another. A fraudulent actor could exploit this by creating records that are similar enough to a trusted entity to trigger a false merge, inheriting the trusted entity's reputation and access privileges. This is the entity resolution equivalent of identity theft, and in the agentic economy - where trust decisions are made computationally and at speed - it is potentially more dangerous than its human-world counterpart.
A false negative - failing to recognise that two records represent the same entity - means that trust is fragmented. An entity that has earned trust through years of reliable interaction might be treated as a stranger because its records were not properly resolved. In the context of reputation via reliability, this means that verifiable performance data is scattered across unlinked records, making the entity appear less trustworthy than it actually is. For businesses preparing for the agentic economy, false negatives in entity resolution directly undermine their AXD readiness.
"Trust is not a feeling in agentic systems. It is a calculation. And every calculation begins with identification. Get the identity wrong, and every trust decision that follows is built on sand."
The concept of trust debt applies directly to entity resolution. Every unresolved entity, every fragmented record, every mismatched identity is a form of trust debt - a deficit that accumulates silently until it triggers a failure. Organisations that defer investment in entity resolution are not saving money. They are accumulating trust debt that will compound as agentic interactions scale, and that will eventually manifest as fraud losses, regulatory penalties, customer attrition, or - in the worst case - systemic failures in the trust infrastructure that the entire agentic economy depends upon.
Design Principles for AXD
Agentic entity resolution is not a problem that can be solved by better algorithms alone. It requires design thinking - the same design thinking that AXD applies to trust, delegation, and observability, but directed at the foundational question of identity. The following principles should guide the design of entity resolution in agentic systems.
Resolution must be real-time and perpetual. Entity resolution in agentic systems cannot be a batch process. It must operate continuously, resolving new records as they arrive, updating existing resolutions as new information emerges, and propagating changes to every downstream system that depends on the resolved identity. The design pattern is not "resolve then act" but "resolve while acting" - entity resolution as a continuous background process that keeps pace with autonomous action.
Confidence must be explicit and propagated. Every entity resolution carries a confidence level, and that confidence level must flow through every downstream decision. An agent making a high-stakes financial decision based on a low-confidence entity resolution should behave differently than one operating on a high-confidence resolution. The consent horizon concept applies: the scope of autonomous action should be calibrated to the confidence of the underlying identity resolution. Low confidence should trigger narrower operational envelopes and higher interrupt frequencies.
Resolution must be explainable and auditable. In regulated industries - which is to say, in most industries where agentic commerce will have its greatest impact - entity resolution decisions must be explainable. The system must be able to articulate why it believes two records represent the same entity, what evidence supports that conclusion, and what the confidence level is. This explainability requirement connects directly to agent observability: the entity resolution decision is part of the agent's decision trail and must be as legible as any other component of that trail.
Resolution must be relationship-aware. Entities do not exist in isolation. They exist in networks of relationships - corporate hierarchies, family connections, business partnerships, supply chain dependencies. Agentic entity resolution must resolve not only individual entities but the relationships between them. An agent evaluating a supplier needs to know not only that "Precision Components Ltd" and "PrecisionComp Ltd" are the same entity, but that this entity is a subsidiary of a larger corporation, shares directors with another company, and has a supply chain relationship with a known risk entity. Relationship resolution is entity resolution's second dimension - and it is the dimension that transforms raw identity data into actionable intelligence.
"Entity resolution is the discipline that answers the question every other discipline assumes has already been answered: who are we dealing with?"
Resolution must be privacy-preserving. Entity resolution inherently involves the comparison and linking of personal data across systems. In the agentic economy, where agents operate across multiple jurisdictions and data regimes, the privacy implications are significant. The design must incorporate privacy-by-design principles: data minimisation (resolving with the minimum attributes necessary), purpose limitation (using resolved identities only for the stated purpose), and consent alignment (ensuring that entity resolution activities fall within the consent horizon granted by the data subjects). The tension between resolution accuracy and privacy protection is a design challenge that cannot be resolved by technology alone - it requires the kind of principled design thinking that AXD was created to provide.
The organisations that master agentic entity resolution will not be the ones with the most data or the fastest algorithms. They will be the ones that treat entity resolution as a design discipline - one that balances accuracy with privacy, speed with explainability, and automation with human oversight. Entity resolution is the foundation that nobody wants to build, because it is invisible when it works and catastrophic when it fails. But in the agentic economy, it is the foundation upon which everything else - trust, delegation, commerce, and accountability - must stand. The stranger problem is the first problem. And it is the problem that, if left unsolved, makes every other problem unsolvable.