Notes on designing agents

Everyone assumes an agent should be fast. For enterprise purchasing, it already is. Next to email threads, Slack pings, and a form someone filled in wrong, almost anything is fast.

The real bar is accuracy. Can the agent get it as right as a human buyer would? If it can, the parts after that, like generating the PO and placing the order, can just happen. That's where the value is.

So I stopped designing for the fewest turns and started designing for enough context.

"I need a laptop" sounds like a complete request. It isn't. Which brand? By when? What budget? A human buyer would ask. An agent that guesses will confidently recommend the wrong thing.

That doesn't mean the agent interrogates everyone. Admins already set up rules, and Workday already knows your cost center, department, and shipping address. The agent fills those in, and only asks when it really doesn't know.

Some people get asked more than they expected. I think that's the right trade.

Most agent experiences are linear. A general agent figures out what you want and passes you to a domain agent. If that handoff is wrong, people don't argue. They leave.

The instinct is to make the agent smart enough to catch its own mistake and reroute. We're working on that. In the meantime, I'd rather make it visible: show which agent is handling the request right now. If it's the wrong one, the person can redirect, and we get a real number for how often routing fails.

We keep Intake mostly conversational. It's tempting to drop cards and widgets into every reply, but most of the time they're noise.

The exception is anything people already have a strong picture of. A catalog, a cart, a product comparison: people know what those look like, so use the pattern they expect. Chat is the default. A familiar UI pattern beats chat when one exists.