Every AI system being built right now is a service. The people who know how to design services and are systems thinkers have a skill set almost every company working with AI needs.
That was the main point of the closing keynote I gave at the Service Design Global Conference in Wiesbaden last week. The room was full of service designers, people who already do this work, but my argument is for a broader audience.
Whether it’s a product team putting an agent in front of customers or a founder setting up an assistant to run the back office, anyone building an AI system is designing a service, even if nobody on the team would call it that.
When service designers explain what a service is, we almost always start with the restaurant example. The diner sits in the dining room, which is the frontstage (the host, the server, the menu, and the plate arriving at the table, ideally still hot).
Behind the swinging door is the backstage, the kitchen, where most of the work happens out of the diner’s sight. An order travels from the table into the kitchen and comes back out as a meal. Every part of a service is there, which is why the example has lasted, and why it maps so neatly onto the service blueprint Lynn Shostack introduced in Harvard Business Review in 1984.
In my keynote, I used that same (metaphorical) restaurant to show where AI agents are starting to appear. Some agents work in the kitchen alongside the team, doing the prep the diner never sees. Some carry the plate out and deliver the service to the customer directly (think AI support bots, like Cursor’s Sam). And some wait at the door like a delivery courier, working for the diner rather than the restaurant and picking up an order on someone else’s behalf (think Meta’s Muse or Instinct AI).
Kate Moran and I run Gibbons & Moran on a system built this way. Kate and I are the diners. Each of us has an assistant who works with us directly, Fern for Kate and Iris for me. They are waiters who can also work in the kitchen. Behind them is Rosemary, a shared agent who works almost entirely in the kitchen: she files the notes from our calls, writes a call sheet before the next one, and brings the company record up to date every morning before either of us is awake.
Work passes between them the way an order passes through the kitchen door. For example, take a single client call. Rosemary preps a call sheet from our calendar, email, and past notes, files what we promised afterward, and by seven the next morning Iris or Fern is picking up the next step with each of us.
All three read from one company record, and we wrote down rules about who may read it, who may change it, and who may send anything on our behalf, the same way a restaurant decides who handles the money and who talks to the guests.
Those are the parts of a service. Getting them right is system design work, regardless of who does it.
Who does the customer actually work with?
Who works out of sight, and what do they need from other actors or systems?
What context and responsibility passes from one to the next, and what could get lost on the way?
Which record does everyone trust, and who is allowed to change it?
When does an agent need to stop and bring in a person for approval?
When does an agent find someone who knows something it doesn’t?
Service designers and system designers have been asking these questions for their whole careers. Many teams building with AI are answering them for the first time.
Ethan Mollick recently wrote that he was wrong to think people would need to organize agents, because the agents turned out to be good at organizing themselves. I think he’s mostly right.
However the harder decisions are at the metaphorical kitchen door, where agents hand work to humans, act on someone’s behalf, or change a single source of truth. Deciding what happens at that door is a separate job, and in a lot of companies right now nobody owns it.
I think this is where service and system designers come in. Most AI systems in use today are still fairly simple, with a few agents and a few handoffs between them. They won’t stay that way.
Before long, a client’s own agent will be engaging with products and services on that client’s behalf. Every new agent adds interactions and every new tool adds rules about who may do what. Soon the hardest part of the system will be managing everything that passes between agents and people in a single day.
Service designers have been practicing two skills that matter here for decades: mapping handoffs and mapping context.
When work passes from one actor to another, so does responsibility. The goal is when something breaks, you know where it broke and whose responsibility it was. When we first set up our system, Rosemary booked client calls without telling Iris and Fern, who run our personal calendars, and I ended up double-booked. This was one problem for one person (me) and easy to troubleshoot. The same gap is a bigger deal at scale and within more complex systems, where a dropped handoff has serious repercussions.
Context is what each actor needs to do its job well, and it’s one of the biggest factors in how good an AI system’s work is. AI engineers call this context engineering, and it’s the same problem service designers have been mapping for years.
Teams building AI systems need both, and service designers already know how to do them. I’m looking forward to seeing what happens as those two groups find each other. Helping businesses with the strategy and talent at this intersection is part of what we’re doing at Gibbons & Moran.
References
G. Lynn Shostack, “Designing Services That Deliver,” Harvard Business Review, January 1984.
Anthropic, “Effective context engineering for AI agents,” September 29, 2025.
Ethan Mollick, “The Dot and the Swarm: Benefitting from the Bitter Lesson,” One Useful Thing, October 1, 2026.
Benj Edwards, “Company apologizes after AI support agent invents policy that causes user uproar,” Ars Technica, April 17, 2025.
Meta, “Introducing Muse: The World’s First Personal AI Agent Built for Everyone,” September 8, 2026.
Instinct, personal AI agent.
The restaurant analogy is the right frame, and the backstage row is where most agent deployments quietly fail. Teams ship the frontstage (chat UI) and never blueprint the handoffs: who catches an agent's failure, what the human sees, how it gets logged. Have you seen teams actually adopt blueprints, or does it only stick when a service designer is in the room?
Sarah: Nice paper. I have long argued that every product is a service. Did you buy a camera? The service part is the wonderful photos and memories it provides, and for businesses, all the secondary services they can offer for making the photos more permanant.