Customer Agents and Service Agents

1. Introduction

This essay completes the trilogy by moving from internal software production to external digital interaction. The first article reframed the lifecycle around intent-to-verified behavior. The second showed that architecture must support that lifecycle by elevating knowledge, policy, and intent to first-class status. The natural next question is whether these ideas stop at the enterprise boundary. They do not.

Today's digital services are typically enterprise-centric. The enterprise stores customer data, determines how services are invoked, and logs what it believes happened. Consent is often broad, front-loaded, and difficult to audit in practical terms. Even when legal rights exist, they are commonly exercised after the fact rather than used to shape each interaction in real time.

A different model is now conceivable. In that model, customers are represented by agents that hold credentials, data references, and authorization policies. Enterprises are represented by service agents that advertise capabilities and negotiate specific interactions under explicit scope and purpose constraints. This is not science fiction. It is an architectural composition of already-emergent standards and patterns, though those elements have not yet been fused into a single dominant protocol stack.

2. From Enterprise Stewardship to Customer Representation

The core shift is one of control. In the dominant digital-service model, the enterprise acts as steward, orchestrator, and accumulator of customer data. In the agentic model, those functions are partly redistributed. The customer retains stronger control over identifiers, credentials, and authorizations, while the enterprise must ask for narrowly bounded access to perform a service.

That shift has two major consequences. First, consent becomes a runtime primitive rather than a one-time legal formality. Second, the enterprise's own internal lifecycle operates within a scope granted by the customer rather than within an implicit assumption of broad standing authority. The first article's thesis therefore expands outward: not only is software moving toward governed behavior, but some of that governance may be set by the customer at the point of interaction.

The second article's architectural argument also becomes concrete here. Customer-held credentials, policy rules, and intent expressions are not abstractions. They become architectural elements that shape what enterprise systems may retrieve, compute, infer, and return.

3. The Building Blocks

Several technical lineages make this model credible.

3.1 Identity and Credentials

Self-sovereign identity introduced the idea that users should control persistent identifiers and portable credentials rather than relying entirely on centralized identity providers. Decentralized identifiers and verifiable credentials give this idea practical form. They allow a holder to present machine-verifiable claims without requiring every interaction to be mediated by the original issuer.

3.2 Personal Data Stores

Personal data stores and related wallet models support the idea that customer data need not be stored only inside enterprise silos. In practice, this does not require every byte to live in a single customer-owned store. It requires that customer agents can manage authoritative references, retrieval permissions, disclosure scopes, and evidence of consent in a way the customer can inspect and control.

3.3 Purpose-Bound Authorization

Purpose-bound authorization frameworks such as User-Managed Access point toward a world in which access to protected resources is granted according to explicit policies set by the resource owner. This matters because the question is not merely whether an enterprise is authenticated. The question is whether it is authorized to use specific data for a specific purpose, over a specific time horizon, under specific conditions.

3.4 Agent Communication

Multi-agent systems research long ago developed the idea that software agents could exchange structured acts such as requests, proposals, agreements, and refusals. Recent protocols for agent interoperability have revived this concern in web-native form. The important point is not that every modern protocol reproduces the full formalism of older agent theory. It is that the need for discoverable capability descriptions and structured agent-to-agent exchange has clearly re-emerged.

3.5 Choreographed Service Composition

Finally, service choreography provides a coordination model for ecosystems in which no single actor should serve as the universal conductor. This becomes important when a customer agent may need to coordinate among multiple enterprises without surrendering control to any one of them.

4. The Interaction Pattern

In the customer-agent and service-agent model, the customer agent becomes the representative of the customer's identity, preferences, constraints, and approvals. It may request an insurance quote, authorize the disclosure of limited facts, compare proposals, negotiate terms, and preserve an auditable record of what was authorized and why.

On the other side, enterprises expose service agents rather than only conventional endpoints. A service agent does more than publish an API. It advertises capability, required inputs, accepted credentials, policy commitments, and service boundaries in a form that another agent can interpret. The richer this capability description becomes, the less every interaction depends on brittle, custom integration.

The interaction then proceeds as a bounded negotiation.

• The customer agent expresses a goal.
• Enterprise agents advertise or propose ways to satisfy it.
• The customer agent discloses only the minimum necessary information under a declared purpose.
• A selected enterprise agent performs the service within that scope.
• The resulting action is recorded with enough evidence for both recourse and audit.

This pattern is best understood as negotiated service fulfillment, not merely as automated chat.

5. Why Choreography Matters — and Where It Does Not

Earlier versions of this argument can overstate choreography as the only natural coordination pattern. A more careful claim is preferable. Choreography is often the most attractive coordination model when customer agents interact across multiple enterprises because it avoids granting one party universal control over the interaction. However, hybrid models will be common.

Some ecosystems will still use brokers, shared trust exchanges, or regulated intermediaries. Some high-risk interactions will rely on partial orchestration for safety, settlement, or dispute handling. The point is not that orchestration disappears. The point is that enterprise-default orchestration is no longer the only imaginable architecture once customers have portable credentials, policy-bearing agents, and purpose-bound authorization.

This refinement matters because it keeps the thesis disciplined. The claim is not that all digital services will become purely peer-to-peer choreographies. The claim is that the architecture of digital services can now be redesigned around more explicit negotiation over scope, purpose, and trust.

6. Failure Modes and Controls

This model introduces real risks, and any serious case for it must state them plainly.

6.1 Impersonation and Wallet Compromise

If the customer agent or wallet is compromised, the trust chain may collapse for that customer. Key custody, recovery, device trust, and delegated authority become core design concerns, not implementation afterthoughts.

6.2 Consent Drift

An interaction may begin within a narrow purpose and gradually expand in practice. Without re-authorization, visible audit trails, and explicit scope checks, purpose limitation can quietly dissolve into convention.

6.3 Revocation Lag

Credentials and permissions may be revoked after issuance. If revocation information propagates slowly or inconsistently, relying parties may act on stale authority.

6.4 Choreography Deadlock and Dispute Handling

Distributed coordination complicates liveness, rollback, and exception handling. In many real settings, compensating actions, timeout strategies, and dispute pathways will matter as much as the happy path.

6.5 Trust-Framework Fragmentation

The model depends on issuers, registries, policies, and verifiers that recognize one another. Fragmented trust frameworks can make a credential portable in theory yet nonfunctional in practice.

These are not fatal objections. They are the design burden of any architecture that redistributes control. The remedy is not hand-waving about decentralization. The remedy is stronger trust infrastructure, clearer accountability, and careful boundary design.

7. Adoption Path

This architecture should be approached as a target state, not as a universal present-tense reality. Most organizations will operate hybrid environments for years. Some interactions will remain enterprise-orchestrated. Others will become partially customer-mediated through wallets, consent services, verifiable credentials, or sector-specific identity exchanges.

The most practical near-term moves are therefore incremental.

• Treat authorization as a runtime, inspectable capability rather than a one-time legal gesture.
• Design services to publish richer capability descriptions, not only technical endpoints.
• Build for revocation, expiry, and scope checking from the start.
• Accept portable credentials where trust frameworks already exist.
• Separate what the enterprise needs to know from what it has historically preferred to collect.

These investments pay off even if the fully agent-mediated future arrives unevenly. They also align with the trilogy's earlier arguments. They improve the quality of intent, the enforceability of policy, and the traceability of behavior.

8. Conclusion

This third article has taken the trilogy's central thesis beyond the internal mechanics of software delivery. If software is increasingly governed behavior, and if architecture must explicitly organize intent, knowledge, and policy, then digital service interactions themselves can be redesigned around explicit negotiation between customer agents and enterprise service agents.

The result is not a prediction that centralized platforms disappear. It is a claim that a credible alternative architecture now exists. Its building blocks are already visible in identity standards, credential ecosystems, authorization frameworks, agent protocols, and choreography models. What remains immature is their end-to-end composition, governance harmonization, and mass-market usability.

The trilogy's full argument can now be stated succinctly. First, software production is moving from code-centric stages toward intent-to-verified behavior. Second, architecture must elevate knowledge, policy, and intent to first-class status to support that shift. Third, once those changes are taken seriously, the boundary between enterprise system and customer interaction can be redrawn around negotiated, policy-bounded, agent-mediated service fulfillment.

Bibliography

• Allen, Christopher. "The Path to Self-Sovereign Identity." Life With Alacrity, 2016.
• Anthropic. Model Context Protocol Documentation. 2024.
• European Union. Regulation (EU) 2016/679 (General Data Protection Regulation), 2016.
• Foundation for Intelligent Physical Agents. FIPA ACL Message Structure Specification. FIPA, 2002.
• Google. Agent2Agent (A2A) Protocol Documentation. 2025.
• Kantara Initiative. User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization. Kantara Initiative, 2018.
• Object Management Group. Business Process Model and Notation (BPMN) Version 2.0.1. OMG, 2013.
• W3C. Decentralized Identifiers (DIDs) v1.0. W3C Recommendation, 2022.
• W3C. Verifiable Credentials Data Model v2.0. W3C Recommendation, 2025.