Will AI agents help consumers save time? We’re on our way to finding out.
Introducing OpenAI Operator
Last week, OpenAI shipped Operator, a new $200 / month AI agent that can accomplish tasks in a browser.
Operator works pretty well – Kevin Roose at the New York Times successfully had the agent
- Order a new ice cream scoop on Amazon.
- [Buy] a new domain name and configured its settings.
- [Purchase] a Valentine’s Day date for [him] and [his] wife.
He summarized
In all, I found that using Operator was usually more trouble than it was worth. Most of what it did for me I could have done faster myself, with fewer headaches. Even when it worked, it asked for so many confirmations and reassurances before acting that I felt less like I had a virtual assistant and more like I was supervising the world’s most insecure intern.
While it’s still early for AI agents and the trajectory of AI improvement is clear (we’re AI bulls), we think it’s worth unpacking how, exactly, AI is poised to actually save users time. It seems like there are two core mechanics:
- Bypassing software with poor UX
- Translating or activating (likely) preferences
Today, Operator appears squarely focused on (1). If you can describe exactly what you want in words, and there’s no room for misinterpretation, Operator allows you to trade typing or dictation for its automated clicks.
But the canonical motivating example for consumer agents usually involves (2). Princeton CS’ Aravind Narayanan explains
Compare this to the usual motivating example for AI agents — automating shopping or flight booking. This is actually the worst-case scenario. If the wrong product shows up at your door even 10% of the time, the agent is useless. And don't forget that online commerce is an adversarial environment — comparison shopping is hard because companies deliberately make it hard. If agents make it easier, brands will fight back. As for flight booking, the time consuming part is preference elicitation. The reason it is frustrating is that search interfaces don't know all your preferences and constraints (e.g. how to trade off time and money, preferred airlines, constraints on when you want to depart and arrive, and really dozens of other little things). But guess what, the agent doesn't know this either. I really don't think shopping and travel booking agents are going to work, and it's not a matter of improving capabilities.
Agents can’t save you time in (2) because they don’t know your preferences. If they decide for you and guess wrong, they could end up creating a costly error you'll have to clean up yourself.
Memory layers purpose-built for AI won’t help either for the same reason Consumer Data Platforms (CDPs) have failed – recordings of our preferences are fragmented across applications, and most memory layers, whether AI native or otherwise, are sparse and quickly become stale.
Even (1) is in question, with Upfront’s Peter Zakin wondering (in the context of AI agents replacing customer support)
What if the end-state of customer support software isn't replacing humans with agents? What if instead, the future of customer support is just more powerful, more malleable software? Yes, I could call Delta or email Delta for some request (from simple tasks like flight changes to complex tasks like PNR splitting, bereavement fares etc...)... but I could also just get what I need from a more powerful version of the Delta app.
Applying this to consumer – what if the future of consumer experiences isn’t an AI agent automating clicks but rather businesses using AI to just make more powerful and adaptive software that doesn’t require excess clicks?
Not to mention the incentives problem of browser agents, with Thick Apps (sites with private aggregated supply) like Reddit and YouTube already blocking Operator in the first week of its launch.
This is to be expected, per Ben Evans newsletter
A lot of companies will block [Operator]: they didn't make an API (or only made a limited one) on purpose, because they want to steer the flow and manage your interactions (and upsell you), and because they themselves want to be the place where you do the whole thing: no one in tech wants to be someone else's dumb API call.
Putting this all together, what the new user experiences of the future look like is still emerging. It sure appears that they will be more adaptive and conformative with, per Scott Belsky,
Context-based purchase decisions. Imagine every purchase decision - from food items and vitamins to wardrobe and accessories - being framed in the context of your diet, what you’ve purchased before, or what is recommended based on a deep analysis of your life and preferences
On-the-fly UI & text-based-commerce: experiences akin to a personal shopper that has worked with you for years, remembers your preferences (whether your wardrobe or otherwise), and can really engage with you personally
What’s core in this is the translation and portability of your preferences.
Traditional first party data via Customer Data Platforms CDPs or memory layers for AI are insufficient for this future. The data are too stale and too sparse.
We’ve explored other phrases to refer to this portable data layer – the one that contains your past purchases, preferences, etc., – as an AI cookie, a Personal MCP server – but for the death of the CDP (and adtech’s love of acronyms) perhaps what we need is a MeDP.
Introducing the MeDP
Crosshatch is a MeDP – a Me Data Platform.
In this special category defining moment, let us take the rare opportunity to declare what a MeDP is.
Definition. A MeDP is a personal data platform with complete user context, able to be privately activated and permissioned to any client under fine-grained access controls on purpose, context and time dimensions.
The MeDP improves on the CDP by aggregating and unifying context from across applications, to create a single timeline of all actions a user has taken in the world, not just those in a first-party context. The MeDP is the platform for recording and activating (revealed) preferences.
This phrasing is useful particularly because its data structure follows canonical CDPs.
Like CDPs Crosshatch’s Context Layer uses the same event data naming convention best practices of CDPs. The only difference is that the MeDP unifies events from across applications to a single context layer: a single view into all actions you take in the world.
This means that we say a like action on Instagram is the same as a like action on Spotify. They both involve ‘liking’ something – whether it’s a song or a photo. Of course, like CDPs, we record the object that received the like, as well as relevant metadata about the object. Here’s how Segment describes metadata assignment best practices
In our case, objects carry metadata like
- Object_style: a LM-generated description of the object, based on data we were able to find about that object through search-based RAG
- Object_unstructured: unstructured data we might have about the object, for instance in the case of events derived from email, where we assign object_unstructured to be the contents of this email
This MeDP representation is helpful further in that it enables intuitive fine-grained access controls over the events observed across applications, which isn’t available or easy to modulate in native application scopes. [For more, see our past blog Authorized Agents.]
Fundamentally, we believe this MeDP is critical to AI-mediated interactions, as it solves the core problem of AI. Not automating clicks, per se, which may readily be resolved through superior software, but rather in preference elicitation.
MeDPs save us from AI as "world’s most insecure intern" and give us a personal assistant who actually know us intimately.
If AI is truly going to save us time, it’ll do it by translating our preferences and past behaviors into new contexts. So that the things we already do magically help us save time in the future, without any extra work from us.
This isn’t magical AI – it’s just practical application of context, in a secure and privacy-compliant way.
Bring on the MeDP.
