Making screens got easier. The hard parts didn't. With agents, the hard parts are trust, control and knowing what the agent actually did. That is the work this page is about.
Where agentic products break
Most teams adding agents to a B2B product get the model working before they get the product working. The agent can draft a contract redline or flag a duplicate vendor, but the people who are meant to rely on it don't. In our experience the failures cluster in a few places.
Trust. A user sees an answer and has no way to tell where it came from. In B2B, an answer without a source is a liability. If a procurement agent says a vendor is already approved, the buyer needs to see which record that came from before they act on it.
Control. Teams give agents broad access because it is easier to configure, then pull back after the first surprise. Users and admins need a clear, readable list of what an agent can read, what tools it can call, and what it is allowed to do on its own.
Visibility. When an agent hands work to other agents, a single request can turn into a chain of runs. Without an audit trail that shows that chain, nobody can explain an outcome to a customer, an auditor or their own manager.
Error recovery. Agents will be wrong. The question is how cheap it is to notice, undo and correct. If changing an agent's instructions breaks something and there is no version to go back to, people stop changing it.
Handoff. Every useful agent eventually reaches a point where a person must decide. If that moment is buried in a chat thread, approvals stall. The handoff needs to show up where the person already works, with the context to decide quickly.
Setup that looks like a developer console. Agent builders often expose every parameter the model supports. The people who know the business rules, such as a procurement lead, are then locked out of configuring the agents that are meant to follow those rules.
Speed that skips the check. Classic UX instincts say fewer clicks and faster flows. Applied to agents, they produce agents that act before the user agrees on what should happen. In procurement, a fast wrong action is an email to the wrong vendor or a purchase order nobody approved.
Chat where a button would do. Not every task should be a conversation. If an approval is one decision, it should be one button, not a chat thread. LCA's handbook on agentic experience lists this as a common failure, along with breaking layouts people already know by heart.
How we approach agentic AI design
We don't start with a chat box. We start with the work the agent is meant to take over and the people who are accountable for it.
If you are starting out, read AX: The Rise of Agentic Experience by LCA (Late Checkout Agency). It is one of the clearest pieces we have found on designing for agents, and it gives the field useful names for patterns many teams are still working out, like the intent handshake and the escape hatch. Several of our principles below line up with it. Ours come from a vertical B2B product, where a wrong action costs a vendor relationship, a contract term or an audit finding.
Start from the domain, not from other AI products
It is tempting to copy patterns from well-known AI assistants. In a vertical product that usually goes wrong, because the vocabulary and the stakes are different. When we designed how a procurement agent is trained on company policy, we did not bring in a generic framework. We read the actual policy documents, listed the kinds of content in them, and grouped those into five buckets: policy source, fields, guidance, escalation and logic. The structure came from the customer's material. Agents in finance, legal and procurement win by going deep on one domain, and that depth is hard for a general tool to copy.
Remove before you add
Our default answer to a new field is no. At Spendflo the first version of agent setup had structured sub-fields for instructions, output types and per-agent permissions. We cut it down to five things an author fills in: name, description, instructions, scope and test cases. Instructions became one free-text field with a worked example as the placeholder. Permissions now come from the roles the company already has, instead of a new layer of settings.
Let the system infer what it can
If the product can work out the output type or how a response should render, the author should not have to choose. Every setting the system infers is one fewer thing a busy expert can get wrong.
Make the agent's limits readable
We split what an agent can do into five plain sections: Domain (what area of the business it covers), Scope (what data it can see), Tools (connected apps such as Slack or Gmail), Actions (what it may do on its own) and Triggers (events that start it without anyone asking). Empty states carry meaning too. "No actions configured" and "Runs on demand only" tell an admin exactly how much freedom the agent has.
Play back the plan before acting
Before an agent sends a vendor email, changes a record or starts an approval, it should say what it is about to do and let the person steer or approve. LCA calls this an intent handshake. In B2B it is cheap insurance: a few seconds of confirmation costs far less than undoing an action a customer or vendor has already seen. Low-stakes steps can run straight through; anything that leaves the building waits for a yes.
Show the source, then step back
We treat agent output as blocks with a type, a display mode, a set of actions, a persistence rule and a source. Every answer can show where it came from, so a buyer can check the contract clause or vendor record before acting on it. Early in a rollout, agents should explain more; as people come to trust them, answers can get shorter, with the reasoning one click away. We grouped the next steps a user can take into four kinds: act on it now, take it somewhere else, save it for later, or keep the conversation going.
Always leave a way out
People use agents more when they know they can undo them. Editing an agent should feel like editing a document: changes save in the background as versions, a clear Publish step makes a new version live, and the version history sits one click away. On the user side, every action an agent takes should be easy to reverse or override.
Hand off on purpose
Good agents know their limits. Escalation is a first-class part of how we structure agent training, not an error state. When an agent calls other agents, the audit trail shows each run as a tree, so you can see which one did what. When a person must decide, the request reaches them where they already work, with the context to decide quickly.
Prototype in working software
Static mockups hide most agent problems, because the problems live in timing, partial results and edge cases. We build working prototypes with AI tools early. At Spendflo we built a working replica of the product that the sales team used to demo features before they were live, and they could change it themselves without waiting on us.
Start with one workflow, then climb
Trust in an agent builds in steps. LCA's handbook describes four: functional trust (does it finish basic tasks reliably), contextual trust (does it understand our history and preferences), judgment trust (does it make good calls when things are unclear) and advocacy trust (will it act in our interest). B2B teams move through the same steps, and many products try to jump to judgment before they have earned the basics.
So we start narrow: one workflow, one agent, a clear review step, and a simple measure of how often people accept, edit or override what the agent does. Once that holds, we add memory across workflows, then more initiative. A Sprint usually covers the first step. Embedded work carries the rest.
Our agentic work at Spendflo
Spendflo is a procure-to-pay platform covering intake, vendor onboarding, third-party risk, purchase orders, contracts, invoices and payments. Its AI layer, Flo, runs agents that handle parts of that process, such as removing duplicate vendors, redlining contracts and supporting negotiations.
turingLabs runs design for Spendflo as a fractional team: a design lead plus an embedded designer working inside their product and engineering rhythm. On the agent side, the work has covered two connected surfaces.
- Agent Studio, where procurement experts write, configure, test and deploy their own agents without engineering help.
- The response system, where end users work with those agents. We mapped about 35 response types across three groups (readable, interactive and actionable) and three ways a response can expand: a side panel, the full screen or a separate view.
Around these sit the pieces that make agents usable in a company: versioning, an audit trail of every run, and permissions that follow the roles the company already has. Alongside the agent work we have also designed the workflow builder, field management with conditional logic, role-based access and the design system.
Read the Spendflo case study for the wider work.
How to work with us
We offer three ways to engage, depending on where your agent product is.
| Engagement | Length | Best for |
|---|---|---|
| Sprint | 4 to 6 weeks | Teams with a working agent that need the product around it: setup, review steps and the first version of the user experience. You get designs your engineers can build from and a working prototype. |
| Embedded | 3 to 12 months | Teams where agents are a core part of the roadmap, not a single feature. Our designers join your team and ship with your engineers week by week. |
| Fractional design leadership | Ongoing, selective | Series A and B teams that need design leadership before they are ready to hire it full time. A senior design lead plus embedded designers own design for the product, as we do at Spendflo. |
FAQ
What is agentic AI product design?
It is the design of products where AI agents take actions on a user's behalf, not just answer questions. The work covers how agents are set up, what they are allowed to do, how they show their work, and how they hand decisions back to people.
What is agentic experience (AX)?
AX is a term from LCA's handbook, AX: The Rise of Agentic Experience, for designing software that remembers, takes initiative and acts on a user's behalf. It builds on UX rather than replacing it. You still need clear flows, and you also need the trust that lets people hand real work to the agent. We recommend the handbook to any team building agents.
How is designing for agents different from designing a chatbot?
A chatbot mostly answers. An agent acts: it updates records, sends messages and starts workflows. That shifts the design focus to permissions, review steps, audit trails and undoing mistakes, which a chat window alone does not handle well.
Do you work with our existing designers and engineers?
Yes. Most of our work is embedded. We join your planning, work in your tools, and hand over specs and prototypes your engineers can build from. If you have designers, we work alongside them and leave the patterns documented in your design system.
Do you only work on procurement products?
No. Spendflo is our deepest agent work, and the same problems show up in finance, risk and analytics products. We have designed for fintech and data-heavy B2B products, including Drivetrain, Effectiv and Hubble Money.
We are based in the US. Does working with a Bangalore studio work?
Yes. Several of our clients are in San Francisco and most are US-incorporated.
How do you use AI in your own process?
Heavily. We use AI tools to research, write specs and build working prototypes, which lets a small senior team test more ideas with real behaviour before engineering starts.
Talk to us
If you are adding agents to a B2B product and want people to actually trust them, we should talk. Tell us what the agent does today and where users get stuck, and book a call with Ankit.