The Relationships Belong to Who?

Businesses have always accumulated relationships alongside assets.

A company may own its customer database, contracts, intellectual property, equipment, domain, and financial accounts, but some of its value exists in places that are harder to put into a folder. Suppliers know the company. Customers recognize it. Payment processors have seen years of legitimate transactions. Partners know what to expect from it. A bank has a history with it. A marketplace may have evidence that it fulfills orders reliably. Other businesses know which representatives are authorized to speak for it.

That history creates standing.

As AI agents become active participants in business operations, some of that standing may begin accumulating around the agents themselves.

An Executive Agent may eventually be the thing another company's agent encounters most often. It may negotiate routine terms, exchange documents, coordinate delivery, make authorized purchases, resolve ordinary problems, present credentials, and prove repeatedly that it is authorized to act for the same business.

After enough interactions, the relationship is no longer simply between two pieces of software.

There is history there.

That creates a question we have not had to ask very often about software:

If the agent moves, does the relationship move with it?

A relationship is more than a contact record.

Suppose DucimusAI has worked with the same production vendor for four years.

The company's Executive Agent communicates regularly with the vendor's agent. It places authorized orders, resolves scheduling issues, supplies the correct business information, follows agreed procedures, and consistently stays within its purchasing authority.

Over time, the vendor's systems may accumulate information about those interactions. Some of that history may be ordinary transaction data. Some may affect fraud controls, account status, pricing, purchasing limits, exception handling, or how much additional verification is required before a request is accepted.

Now DucimusAI moves its Executive Agent from one provider to another.

The business exports the agent's memory. It migrates its operating instructions. Its internal files survive. The new Executive Agent can communicate through the same open protocols.

From the company's perspective, the migration appears successful.

The vendor's system may see something different.

It may see a new identity with no history.

That means the business moved the information but lost the position it had accumulated around that information.

This is why portability eventually has to include more than data.

We need to distinguish identity from standing.

Identity answers a basic question: Who is this?

Credentials help answer another: What claims about this identity can I verify?

Authority answers: What is this entity currently allowed to do?

Standing is different. It reflects what has accumulated through repeated participation in a system or relationship.

For this series, we are using standing as a practical term for the combination of recognition, history, reputation, verified relationships, prior transactions, accepted credentials, and other accumulated signals that affect how an entity is treated by another system.

This is not a standardized agent-identity category. It is a useful way to describe something businesses already experience across digital platforms.

A seller with five years of marketplace history is not in the same practical position as a new seller, even if both possess identical inventory.

A creator with an established audience is not in the same position as someone who uploads the same content to a new account.

A business with a long banking relationship may encounter different friction than a newly opened account.

The information can be duplicated. The standing usually cannot.

Agents may bring that old platform problem into the internal structure of the company.

This is where machine-to-machine relationships become economically important.

A2A is being developed specifically so agents operating across different frameworks and vendor environments can discover one another, describe capabilities, delegate tasks, and collaborate. In August 2026, the protocol joined the Agentic AI Foundation as a Growth Stage project, and its current architecture uses Agent Cards to advertise capabilities and authentication requirements across agent boundaries.

That is an important step toward an agent ecosystem that is not trapped entirely inside one provider.

But A2A deliberately does not turn communication into universal identity or universal trust. Its current specification relies on established authentication mechanisms and handles identity at the surrounding protocol and security layers rather than embedding one portable identity system into every A2A interaction.

That distinction matters.

An agent may be able to find another agent and communicate with it without either side automatically knowing whether the other should be trusted with a $12 purchase, a $120,000 purchase, confidential data, or a binding business decision.

Communication answers whether the door exists.

Identity, authority, credentials, history, and trust determine what happens after someone knocks.

Trust is already starting to separate from identity.

This is one of the more interesting developments to watch.

An emerging 2026 Internet-Draft called the Agent Trust Transport Protocol explicitly separates the question “Who is this agent?” from the question of whether that agent should be permitted to perform a particular action, at a particular magnitude, with a particular counterparty, at that moment. The proposal is early and should not be mistaken for an adopted standard, but the distinction it is trying to formalize is useful.

Knowing an identity is not the same as trusting it.

Trust may depend on the transaction.

An agent could be perfectly acceptable for ordering office supplies and completely unacceptable for signing a seven-year lease.

A vendor may trust an agent up to one spending limit and require additional confirmation above it.

A marketplace may recognize an agent's business identity while still subjecting unusual behavior to additional review.

That means agent relationships are likely to be conditional rather than binary. The relationship may contain layers of recognized identity, verified authority, transaction history, behavioral expectations, limits, and exceptions.

Once those layers exist, the Executive Agent has begun accumulating something the business will care very much about preserving.

Verifiable credentials can help preserve claims. They do not automatically preserve relationships.

The W3C's Verifiable Credentials 2.0 standards give us a strong foundation for carrying certain claims between systems. A credential can express machine-verifiable information issued by one party, held by another, and checked by a verifier. The 2.0 family became formal W3C Recommendations in May 2025.

That could become extremely useful for agents.

An Executive Agent might eventually present credentials proving that it is authorized to represent a business, belongs to an approved supplier program, possesses a particular certification, or has a defined purchasing limit.

Those credentials could be checked without requiring every verifier to depend on the agent's current AI provider.

That helps with portability.

It still does not mean the receiving system has to treat a migrated agent exactly as it treated the previous one.

A credential might prove:

This agent is legitimately authorized to represent DucimusAI.

It may not prove:

This is the same operational relationship your system has been interacting with successfully for four years.

That second statement involves history.

And history usually lives in more than one place.

Relationships are jointly produced.

This may be the most important reason relationship portability is difficult.

The history between two entities does not belong entirely to either participant.

If DucimusAI's Executive Agent has completed 800 transactions with Vendor A, DucimusAI may have records of all 800. Vendor A may have its own records. A payment processor may have another version. An identity provider may hold authentication history. A marketplace may hold reputation signals derived from those transactions.

No single participant necessarily possesses the complete relationship.

That makes the question “Who owns the relationship?” harder than it initially sounds.

The business may own its correspondence, contracts, customer information, and records according to the applicable agreements and law.

The counterparty owns or controls its own records.

The platform may maintain derived information about both.

Some trust signals may be generated from the interaction rather than explicitly supplied by either party.

That means relationship portability probably cannot mean simply:

Give me my relationship file.

There may be no single file.

The more useful question is whether continuity can be proven.

Suppose the old Executive Agent is being retired.

The business creates a new one.

Instead of requiring every counterparty to pretend nothing changed, the business may need a way to make a credible continuity claim:

This new Executive Agent is now authorized to act for the same business. The previous Executive Agent has been retired. The business identity has not changed. These existing credentials remain valid. These prior credentials have been revoked. The new agent is the legitimate successor to the previous operating role.

That is much more realistic than pretending the agent itself never changed.

Humans already understand this form of continuity.

A company's Chief Financial Officer can leave.

A new CFO can take over.

The bank does not assume that the company ceased to exist because a representative changed.

The company proves that the new representative is authorized to occupy that role.

A portable agent ecosystem may need the machine-readable equivalent.

The relationship should attach primarily to the business, while the agent remains a replaceable representative within it.

If the relationship attaches primarily to the agent identity issued by one provider, the company is much more exposed when that identity changes.

This is why the business has to sit above the Executive Agent.

The hierarchy we have been developing throughout this series becomes even more important here.

The business should ideally have a durable identity that survives individual agents.

That business identity authorizes an Executive Agent. The Executive Agent then receives the credentials, permissions, and delegated authority needed to perform its role.

External relationships can recognize both.

The counterparty knows which business it is dealing with and which agent is currently authorized to represent that business.

That gives the system a way to preserve continuity while still allowing operational representatives to change.

Without that separation, the Executive Agent can slowly become indistinguishable from the business itself.

That may work beautifully until the day the agent needs to move.

Then the company discovers that what it thought was its own commercial standing had become attached to a provider-specific identity.

This is the same problem creators have already lived through, one layer deeper.

Creators know what it means to build something valuable inside a platform and discover that some of the value does not travel.

You can own the video and still not own its ranking history.

You can download the post and still not take its distribution position.

You may possess a list of followers while lacking a way to recreate the platform's accumulated understanding of which followers actually respond to your work.

You can move the content without moving the network effects around it.

The agent economy could recreate that problem inside the business itself.

Instead of asking whether your audience travels with you, you may be asking whether your business relationships travel with your Executive Agent.

That is why the issue is bigger than vendor lock-in.

The provider may eventually host not only the agent's memory and tools but some of the identifiers through which the agent participates in economic relationships.

If those identifiers become the basis for accumulated trust, then changing providers may affect the company's position with other entities even when every byte of internal business data survives.

Reputation creates an even harder portability problem.

Relationship history and reputation overlap, but they are not identical.

A history tells us what happened.

Reputation is an interpretation of that history.

One platform may decide that an agent with 10,000 successful low-risk transactions deserves fewer verification steps.

Another may assign no value to that record.

A vendor may internally mark an account as highly reliable.

A payment system may view exactly the same transaction pattern through a fraud-risk lens.

A future agent marketplace might develop its own reliability or trust metrics.

There is no reason to assume all those systems will calculate reputation the same way or agree to import one another's conclusions.

That makes reputation portability much harder than identity portability.

A portable identifier can tell the next system:

This is the same entity.

A portable transaction history can say:

Here is what this entity previously did.

The next system may still say:

Fine. We will decide for ourselves what that means.

That is legitimate.

Portability should preserve evidence where possible. It should not require every system to inherit somebody else's judgment.

That distinction protects agency on both sides.

This matters because portability cannot mean forcing another business to trust an agent.

A vendor has its own agency.

A bank has its own obligations.

A customer should be able to make independent trust decisions.

If DucimusAI moves its Executive Agent to a new provider, the goal should not be to compel every counterparty to preserve every privilege the old agent enjoyed.

The goal should be to prevent the migration itself from unnecessarily destroying the evidence needed for those counterparties to make an informed continuity decision.

That means preserving things such as identity, valid credentials, transaction evidence, succession records, and revocation history.

The other party can then decide how much weight to give them.

That is healthier than either extreme.

The business does not have to start from zero merely because its infrastructure changed, and the counterparty does not have to inherit trust blindly merely because the business says, “same agent, promise.”

This is where provenance becomes bigger than content.

We usually talk about provenance in AI when discussing whether a piece of media was created by a particular person or system.

Agentic businesses add another use.

We need provenance for relationships and authority.

If a new Executive Agent appears, another system may need to know how it connects to the old one. If a credential is presented, the verifier needs to know who issued it and whether it remains valid. If authority was delegated, the chain needs to show where it originated. If a previous identity was revoked, the system needs to know that the replacement is legitimate rather than a clone using copied memory.

NIST's 2026 agent identity work is explicitly concerned with identification, authorization, auditing, and non-repudiation as agents gain access to more systems and operate with greater autonomy.

That infrastructure is not merely about catching bad agents.

It is also about giving legitimate businesses a reliable way to prove continuity.

The customer relationship may become even stranger.

So far, we have mostly imagined business agents dealing with vendor agents.

Now put the customer on the other side.

A customer's shopping agent may learn that DucimusAI's commerce agent consistently provides accurate inventory data, honors stated prices, ships reliably, handles returns properly, and presents verifiable credentials.

Eventually that customer's agent may begin treating DucimusAI differently because of its history.

Perhaps it includes the business more often in product comparisons. Perhaps it is willing to execute purchases with less human intervention. Perhaps it recognizes certain transaction terms as acceptable because previous transactions went well.

The customer's human may never know the details of that machine-to-machine relationship.

They may simply see that their agent “likes” certain suppliers.

Now imagine DucimusAI migrates its agent infrastructure and loses the identifier associated with that history.

The human customer has not changed.

DucimusAI has not changed.

The products have not changed.

But the machine relationship may have reset.

That makes identity continuity part of customer acquisition and retention.

The business may eventually have both a human-facing brand relationship and an agent-facing operational relationship.

Those will overlap, but they will not necessarily be identical.

That has implications for brand consistency too.

A company spends years teaching humans what its name, voice, promises, products, reputation, and visual identity mean.

Agents introduce another audience: systems that encounter the business structurally rather than aesthetically.

Those systems may care about identifiers, credentials, product schemas, transaction reliability, authorization records, policies, availability, service history, and machine-readable claims.

Brand consistency in an agentic economy therefore may include something much deeper than using the same logo and handle everywhere.

The business will need consistency between its human-readable identity and its machine-readable one.

The customer should not encounter one version of the company while their agent encounters an entirely different one.

That does not mean machine systems need a cute brand voice.

It means the business needs a coherent identity across the layers where humans and agents recognize it.

For a one-human company, that becomes especially important because the Executive Agent may represent the business in places the owner never personally visits.

This is why I would not let the Executive Agent own the relationships.

The Executive Agent can manage them.

It can carry context about them.

It can participate in them.

It may become the familiar operational representative to other agents.

But structurally, the relationships should belong as much as possible to the business.

That means the contracts belong to the business.

Customer records belong under business-controlled systems.

Credentials should identify the business as principal where appropriate.

The Executive Agent's authority should derive from the business.

The succession mechanism should allow another authorized agent to take over the role.

Critical relationship history should not exist exclusively inside the Executive Agent's private memory.

The business should preserve its own source of truth.

This is not because the Executive Agent is untrustworthy.

It is because an organization should not make its continuity depend unnecessarily on one replaceable component, human or machine.

Standing portability may never become complete, but that does not make it irrelevant.

There probably will not be a magical export button that carries every relationship, trust score, vendor preference, customer-agent history, and reputation signal from one ecosystem into another.

Human businesses do not have that today.

Switch banks and the new bank does not inherit your entire relationship with the old one. Move marketplaces and your seller reputation may not follow. Change social platforms and your audience relationship does not simply reappear.

The goal should not be perfect portability.

The useful goal is enough independent identity, evidence, and business-controlled history that changing infrastructure does not erase the company unnecessarily.

That is achievable in degrees.

It is also measurable.

The business can ask which relationships depend on provider-specific identifiers, which credentials are independently verifiable, which histories are stored under business control, which counterparties recognize the business rather than only the agent, and what proof would be available if the Executive Agent changed tomorrow.

Those questions reveal where the actual dependency sits.

The relationship test is simple.

Imagine telling every important system your Executive Agent deals with:

That agent is gone. Here is the new one. The company is the same.

What happens next?

If the response is essentially, “Fine. Prove the new agent is authorized and continue,” the relationship belongs substantially to the business.

If the response is, “We have no way to connect this new identity to the history you built before,” some of the relationship was tied to the agent.

If the response is, “That history only exists inside the platform you just left,” some of the relationship was tied to the provider.

That is the map.

The business does not need to eliminate every dependency. It needs to know where they are.

Because an Executive Agent may eventually become very good at building relationships on behalf of the company.

The owner still needs to make sure it is building the company's relationships, rather than quietly building relationships that disappear with the agent.

That distinction becomes unavoidable when the Executive Agent can no longer serve in the role.

Maybe the business owner replaces it.

Maybe the provider disappears.

Maybe the agent fails.

Or maybe the human principal herself is no longer there to make the decision.

At that point, portability is no longer the hardest question.

Succession is.