Here at CR we’re starting to envision AI systems that advise and represent the interests of consumers. In this post, we’ll propose two levels of agentic communication between consumers and businesses, and how they might work in practice.
As we build Agentic Systems for consumers, we know we can have a lot more impact picking a small number of tasks and excelling at them. A domain we’re particularly interested in is customer service requests – they’re an inevitable part of consumer life, yet involve so much friction and frustration. How should an AI system act when advocating for consumers in a customer service context? And how can we actually build a system that acts like that?
Inspired by principles from fiduciary law, there are a number of properties a pro-consumer agentic system should have:
- Agency with Consent (Duty of Loyalty): Ensuring that systems act in the best interest of their users, respecting their goals and preferences.
- Transparency (Duty of Full Disclosure): Providing clear and comprehensible insights into how decisions are made and data is utilized.
- Safety (Duty of Care): Ensuring systems are designed to minimize harm, prioritize user safety, and operate reliably under varying conditions.
Achieving these ideals is far from straightforward, particularly when non-deterministic and unpredictable components like Large Language Models (LLMs) are involved in the system.
The Actors in Our System
- Principal: The user.
- Agent: The system acting on behalf of the user to get to a customer service resolution.
- Counterparty: The business or company that the principal is interacting with through the agent.
We outlined these actors in-depth in a previous blog post; each actor connects to the other two. In our system, CR acts as the agent and users interact with CR instead of business directly to get customer services requests fulfilled.
Sometimes principals might need to directly interact with counterparties without passing through the agent. This presents a difficulty because, unless the agent is informed that these out-of-band interactions are taking place, it won’t know about them and won’t be able to use that information to act effectively.
Models of Communication
Agents need some conceptual structure that defines how they communicate with each other.
- Transactional Model: In this model, an interaction is a simple transaction that is either fulfilled or rejected. This is simple and easy to understand for all parties but limited in functionality.
- For example: User wants a refund on airport WiFi that didn’t work. The WiFi provider company either gives them the refund, or denies it.
- Negotiation Model: Another way to model the interaction is as a negotiation, where each party can ask for certain conditions until both agree. This more complex approach allows for interactions like a customer pushing back on a response or a company attempting to upsell. It requires more user input, which some users may prefer while others may not.
- For example: User wants a refund on airport WiFi that didn’t work. The WiFi provider offers them a generous coupon for future purposes. The user takes the deal, getting the credit on future purchases but no refund.
Both models may be useful, depending on the request type and the user’s interaction preferences. Ideally our agent would be able to use the one best suited to the request at hand.
But what types of things should the agent be able to communicate with this model? There’s a range available between totally free-form text to be interpreted on the other side, to rigidly-defined machine protocol with no room for interpretation. Ideally we find a middle-ground of a semi-structured protocol that allows free text comments or annotations attached to structured requests to get the best of both.
This protocol needs to handle communication between the agent and the user, and between the agent and the company. Here’s an example set of actions that might make sense as part of such a protocol.
These verbs are signals representing the intent and position of the different involved actors – they’ll likely get passed around between agents, but don’t necessarily perform all the heavy lifting like verbs in HTTP or other web protocols. Companies and startups like LangChain, Skyfire, FIPA, and others are building the lower-layer protocols, while we here are talking about a higher level ontology for shared semantic understanding between parties involved in customer service exchanges.
We rooted this example in a transactional request for refunding a purchase:
- REFUND – ask for a product to be refunded, given an order number or other identifier
- ACCEPT – accept a refund request
- DENY – deny a refund request
- EXPLAIN – request extra information about a decision
- ASK PERMISSION – ask the user permission to use some PII to accomplish a task, or to consent to a decision made by the agent
- COMPLAIN – file a complaint with the company
This is of course just a strawman. Defining a general protocol that accommodates customer service requests for various scenarios will require many iterations and experiments.
Collaborating with Companies: One-Sided and Two-Sided Approaches
At first, the CR agent may be interacting with an existing customer service system through channels like email, chat, or phone. The company may not yet have designated flows established for agents, however the agent should be able to operate with the company regardless. We’ll call these interactions One-Sided.
One-Sided interaction – a consumer’s agent interacts with existing channels
By working with companies, we can establish a new channel for agents to communicate with directly, instead of going through channels designed for humans. We’ll call these Two-Sided interactions.
Two-Sided interaction – a consumer’s agent interacts with an interface designed for it
There are many reasons that companies will need to find the right set of policies for two-sided agentic interaction including safety, scalability, customer trust. Also if designed right, these policies can still allow companies to negotiate and create sales opportunities. Making these interactions two-sided is a feature, not a bug – our perspective is that your agent should be an intelligent advocate for you, not an unstoppable Terminator-style bot.
Companies that buy-in to this could choose to adopt standard protocols for managing agent transactions. This would open the door to a safer and customer-friendlier landscape, through adoption of advanced authentication protocols like GNAP or patterns from Doc Searls’ VRM concept like intentcasting. If we can make these systems traceable, repeatable, and auditable, customers come out ahead.
Next Up: Building Blocks of Agentic Systems
In Part 2 of this post, we’ll look at some potential building blocks that might be useful and challenges to overcome in making a system like this a reality.
