An Agent Is Not the Customer's Twin

In Part One, I wrote that in Agentic Commerce, a store may retain the order while losing ownership of the decision. Now I want to go one layer deeper, to where I think the damage happens sooner and more quietly: the customer database.

Let me start with a simple example and stay with it throughout this article.

A user asks their agent to find a birthday gift for a friend's child. The agent examines dozens of toys, compares several age groups, reads reviews, and eventually buys a product.

What does the retail platform know about this user the next day?

If it adds all the agent's behavior to the customer profile as though it were direct human behavior, it reaches these conclusions: the user is interested in children's toys, probably has a child in that age group, and is a good prospect for similar purchases. It then adds the user to a target audience, sends personalized messages, and feeds the same data into its predictive models.

None of those conclusions is correct. The user has no children. They are not interested in toys. And they probably will not return to the category until the same time next year.

This simple example captures one of the hardest customer data problems of the coming years: when the actual actor behind an interaction is an agent, which parts of its behavior belong in the human's profile?

My basic answer: the agent should be connected to the customer, but it should not be treated as the customer.

An Agent Is Different from a Digital Twin

A Digital Twin is a representation. Its purpose is to describe or simulate a person's state and preferences.

An agent acts. It may use a model resembling a digital twin, but it is not itself that twin. It has tools, interacts with the outside world, and makes decisions within the authority it has been given.

This is an architectural distinction, not a philosophical one. A digital twin is part of how we model our understanding of the customer. An agent is an independent actor with an identity, provider, capabilities, permissions, and action history.

Return to the gift purchase. Consider a few facts:

• The agent may have been created for a single ten-minute mission and may no longer exist afterward.
• It may be shared by several family members or employees of a company.
• The same user may have entirely different agents for travel, finances, and work.
• The purchase may be for someone else, as it is in our example.
• Some of the agent's decisions reflect the constraints of its provider, model, and tools rather than the user's preferences.
• No human ever saw many of the dozens of products the agent examined.

At best, the agent is a mission-specific representative of the user's intent: limited, temporary, and tied to a purpose.

Four Entities That Must Remain Distinct

Identity models in traditional commerce were built around one question: which person do this cookie, device ID, phone number, and customer ID belong to?

In commerce where both humans and machines act, that question is not enough. Every interaction must distinguish at least four things.

• Actor: Which entity performed the action, a human, an agent, a search crawler, an automation tool, or an enterprise system?
• Principal: Which person or organization authorized the action?
• Beneficiary: Who is the outcome for, the account holder, another family member, a gift recipient, or an organizational unit?
• Mission: What specific goal is the agent pursuing?

In our example, the actor is an agent, the principal is the user, the beneficiary is someone else's child, and the mission is a one-off gift purchase. If the system records only the principal, the other three disappear, and the profile immediately tells a false story.

The enterprise equivalent follows the same pattern: a purchasing manager authorizes the company's agent to order goods for a branch, payment comes from the company account, and the branch's employees use the goods. Three distinct entities and one transaction.

The right relationship model is:

Agent -- acts_for [scope, purpose, expiry] --> Principal

The agent retains its own identity, and its relationship with the principal is recorded in a mandate: a specific delegation of authority with a scope, purpose, budget, constraints, and expiration date.

Why Is Full Merging Dangerous?

Customer data platforms use a process called Identity Resolution to connect scattered identifiers belonging to the same person to a single profile with sufficient confidence. This makes sense for phone numbers, email addresses, and customer IDs. For agents, it has the opposite effect.

If the agent and the human are fully merged:

• Temporary interests become permanent attributes, such as "this person has a child."
• The behavior of multiple principals gets mixed into one profile.
• Ad frequency caps and suppression lists operate incorrectly.
• Advertising audiences are populated with mission-specific data.
• Sales attribution loses the distinction between a human decision and an agent's independent exploration.
• One user's consent may spill over to another agent, mission, or person.
• Predictive models learn the agent provider's policies instead of the customer's behavior.

Take that last point seriously. Your model thinks it is learning the customer's preferences when it is actually learning another company's ranking algorithm.

Worse, this contamination is not easily reversible. Once thousands of misclassified interactions have flowed into attributes, segments, and communication journeys, removing the agent's ID does not solve the problem. You need to trace every inference built from that data, and usually no one knows where all those inferences have gone.

But Do Not Discard All Agent Behavior Either

The solution is not to ignore agent behavior. An agent can provide a powerful signal of intent. What matters is storing each signal with the right weight, provenance, and lifespan.

My rule is simple: the closer a signal is to a human decision or approval, the greater its weight and persistence. The closer it is to the agent's independent exploration, the more temporary and constrained it should remain.

In practice, that means the following.

A completed, delivered purchase can enter the principal's transaction history, provided the record identifies the agent as the actual actor and preserves the beneficiary if it is someone else. In our example, the order is recorded with a label indicating "gift purchase, different beneficiary."

Explicit human approval, a specific selection, a saved product, or an approved cart, is a strong signal that can enter the profile with high confidence.

A shortlist created by the agent is retained as temporary intent, provided its provider, mission, confidence level, and expiration date are known.

Initial browsing and comparison, the dozens of toys the agent opened, stay in the mission profile and never become long-term human attributes.

A sponsored offer seen by the agent is not human exposure and should not, on its own, trigger remarketing to the person.

An agent-generated inference should not become a permanent customer attribute without provenance, a purpose, and an expiration date.

The Future Profile Is Not a Flat Record

A traditional customer profile is usually a collection of identifiers, attributes, segments, and a behavioral timeline. In an environment where humans and machines act alongside each other, this model needs layers:

• Principal profile: the identity, consent, attributes, and history of the person or organization.
• Agent profile: provider, version, capabilities, permissions, verification status, and action history.
• Delegated authority: scope, purpose, budget, approval policy, and expiration date.
• Mission profile: intent, constraints, category, beneficiary, and mission lifespan.
• Event provenance: which actor generated the event, from which source, and in what context.
• Outcome: order, payment, delivery, cancellation, and return.

These layers can be connected in an identity graph, but they must not collapse into one undifferentiated record.

Three Permissions That Are Not the Same

The most dangerous simplification is to treat an agent's permission to buy as the user's consent to data use.

Consent specifies the purposes for which data may be processed: service delivery, personalized advertising, analytics, or sharing with a business partner.

Delegation specifies what the agent may do on behalf of the principal: search, compare, build a cart, pay, or manage an order.

Transaction Authorization specifies which particular transaction has been authorized, for what amount, and with which seller.

The user in our example authorized the purchase of a gift. They did not authorize profile enrichment, inclusion in a toy-shopping audience, or the transfer of their intent to an advertiser. These are entirely separate matters and must be recorded separately.

Standards are moving in this direction. Google's AP2 protocol uses signed mandates to record the user's instructions and constraints. OpenAI's Delegated Payment models payment authorization as single-use, amount-limited, and expiring. Visa Trusted Agent Protocol distinguishes between a trusted agent, an authenticated user, and purchasing authority, although Visa explicitly says it is still under development.

All three share the same principle: an agent's authority must be limited, provable, and revocable. Consent must remain separate and purpose-specific.

The Minimum Information Every Event Should Retain

If I had to summarize the most practical part of this article in one table, this would be it. Every interaction involving an agent should carry the following information:

The goal is not to collect as much data as possible. It is to retain enough provenance to avoid misinterpreting it later.

One point is often forgotten: every decision to link an entity or transfer a signal must be reversible. You must be able to ask, "Where did this attribute come from?" and remove it without rebuilding the entire profile. The W3C Verifiable Credentials Data Model, a standard for claims whose validity can be independently verified, is one possible foundation. But credential technology alone is not enough. The data system must know for what purpose, and until when, a claim may be used.

Why Is This Problem More Acute in Iran?

The Iranian market has several characteristics that make it more exposed to incorrect identity merging than mature markets. These have nothing to do with agents. They were already there.

Shared family accounts are common. A single Digikala or SnappMarket account used by parents and children is entirely ordinary. The resulting profile already combines several people.

The phone number is the dominant identifier. In other markets, email addresses, cookies, and device IDs provide multiple, sometimes contradictory signals that force a system to be cautious. In Iran, the phone number is a strong, deterministic key. Anything attached to it is merged with high confidence, whether correctly or not.

There is no shared standard for delegated authority. No protocol, no agreement, and not even a common language for describing the authority under which a purchase was made.

Now add agents to this mix. A store that attributes every activity to the phone number's owner combines the user's own behavior, other family members' behavior, the agent's independent searches, and purchases made for someone else in a single profile.

It then builds audiences from that profile and spends advertising budgets against them.

Before this is a technical problem, it is a problem of definition. We have not yet properly defined who "the customer" is.

Identity in the Future of Commerce Is a Relationship, Not a Record

Return to the gift purchase. The agent knew the user's preferences, searched on their behalf, and bought within its authority. None of that makes the agent the user.

The future profile should not be a repository for every interaction somehow attached to a customer account. It must distinguish direct human behavior, mission-specific agent behavior, delegated authority, valid consent, and confirmed outcomes.

In human-centered commerce, identity was largely about unifying scattered identifiers. From here on, identity maturity will depend on the ability to preserve distinctions.

In the final part of this series, I turn to money: if an agent clicks an ad, what should be paid for, and who should be paid?