Everyone's a director now

For most of my career, the people I designed for were operators. They opened a screen, did a task and closed it. Someone booked an appointment. A coordinator moved it when the customer rang back. The software held the data and the person did the thinking.

That's shifting. More of the work I see now looks like this: an agent pulls data from one tool, checks it, decides what to do, and pushes the result into another. The person's job moves up a level. They set the rules, choose the sources, and decide what the agent can do on its own and what needs a human. They're directing.

People who work in software already think this way. We've been drawing workflows on whiteboards for years: triggers, conditions, hand-offs, exceptions. Most people haven't, and over the next few years a lot of them will be asked to, by their tools, their bosses or their competitors.

That makes this the design problem worth working on: how do you help someone direct a process they've never had to describe?

What a year of conversational AI taught me

For the past year I've worked on conversational AI agents that answer enquiries, book work and help with quotes. Most of the people setting them up have been owners of trades and service businesses. They know their business inside out, and almost none of them had written a prompt before. The lessons go well beyond trades, though. Anyone who runs a team, a clinic, a support desk or an office carries the same kind of knowledge in their head.

The first thing you learn is that the prompt is the smallest part. How the agent talks matters. What it knows matters more. To make a good decision on someone's behalf, it needs:

• what's on offer, including the exceptions, like services only available on certain days
• how pricing flexes, whether that's by location, effort or complexity
• what's already committed and how much capacity is left
• the local knowledge that turns an acceptable answer into a good one, like which slot fits around work already planned

Each of those is a judgement the owner makes in their head dozens of times a day, like adjusting a price for a harder job, or knowing which requests always take twice as long as they sound. Turning that into something an agent can act on is the real setup work. Ask someone to "write instructions for your receptionist" and you get a blank box and a closed tab.

So the design work is about getting knowledge out of someone's head and into a shape the agent can use. That means asking the questions they'd never think to answer, giving them examples to edit in place of an empty page, connecting to the tools that already hold their data, and letting them write rules in plain language ("we don't take new clients on Fridays") that the system turns into structure.

The balance nobody talks about

The second lesson was about confirming. An agent taking a request needs accurate details: who, what, where and when. The obvious way to get accuracy is to read everything back. "Just to confirm, that's 14 Smith Street, a service call, Thursday morning, is that right?" By the third confirmation, people are frustrated.

Confirm too little and you send someone to the wrong address. Confirm too much and the customer feels processed. Where the line sits depends on the business and on the detail. A wrong address costs a wasted trip. A slightly wrong description usually costs nothing, because the person doing the work sorts it out when they get there. That's human judgement too, and the owner is the one who has it. The tool's job is to ask for it in a way they can answer: which details would cost you money if we got them wrong?

A new layer of design

Put those together and you get a different kind of design work. We're designing for people who are themselves designing. Someone setting up an agent, whether they run a business, a team or a department, is building a small system with data sources, rules, a voice and hand-offs. They just don't call it that. In the industry we'd call it orchestration. For the person doing it, it's just getting their work done.

That changes what's worth building. Most of the energy in AI products right now goes into what the agent can do. Far less goes into the layer that lets an ordinary person tell it what to do, check it's doing it, and fix it when it isn't. That layer includes starter templates, previews before anything goes live, a review step where a human checks the first few conversations, and defaults that stay safe when someone skips a question, because they will.

It's also a systems problem, which is where this gets interesting for product people. The same person might set up how the agent talks, an automation that follows up with the customer afterwards, and a connection to the system they already run their work from. If each of those has its own concepts and its own language, they're learning three products. If all three share one model (here's what the agent knows, here's what it can do, here's when it checks with you), they learn it once. Getting that shared model right matters more than any single feature on the backlog.

Try this

If you build software, find someone who knows their own job well and has never configured an automation, and watch them set up yours. Where do they stall? What do they know that your setup never asks for?

A lot of the next few years' design work sits in that gap. Building is cheap now. The hard part, and the part worth building, is helping people direct what gets built.