Notifications
Clear all
Topic starter
04/06/2026 6:50 pm
TL;DR: Agent experience is the design layer between products and AI agents, and the source article argues that agents need explicit, structured, idempotent, machine-readable interfaces far more than human-oriented UX flourishes. The practical shift is that API parity, visible reasoning, and reversible actions become governance requirements, not polish, as agent-driven workflows scale.
NHIMG editorial — based on content published by WorkOS: Agent experience: How to design products that agents can actually use
Questions worth separating out
Q: How should security teams govern AI agents that use public APIs?
A: They should treat agent-facing API use as delegated execution, not ordinary application traffic.
Q: Why do UI-only workflows create risk for machine identities?
A: Because machine identities cannot reliably operate through visual interfaces, UI-only steps often force teams into browser automation or uncontrolled workarounds.
Q: What do organisations get wrong about agentic retries and idempotency?
A: They often assume a failed request means nothing happened, which is unsafe in agent workflows.
Practitioner guidance
- Map agent-facing actions to explicit API parity Inventory which product functions are only available in the UI and define API equivalents for each one that an agent may need to call.
- Require structured errors and typed responses Standardise error codes, response shapes, and field types so agent callers can branch deterministically instead of parsing free text or inferred status.
- Enforce idempotency on side-effecting workflows Use idempotency keys for create, send, modify, and delete actions that agents may retry.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- Specific API design patterns for agent consumers, including error object structure and schema conventions
- Examples of products that still depend on UI-only workflows and why that breaks agent automation
- Practical guidance on matching autonomy to reversibility for user-facing agent actions
- Implementation notes on OpenAPI and GraphQL schema quality for machine-readable consumption
👉 Read WorkOS's article on designing products agents can actually use →
Agent experience for AI agents: are your APIs ready for AX?
Explore further
04/06/2026 7:04 pm
Agent experience is an identity control surface, not a design nicety. Once AI agents become primary consumers of software, the question is no longer whether the interface is pleasant for humans. The question is whether machine identities can safely interpret, retry, and complete actions without guessing. That makes structured output, explicit state, and idempotent execution part of access governance, because the agent is effectively the actor carrying privilege.
A few things that frame the scale:
- Only 44% of developers are reported to follow security best practices for secrets management, according to The State of Secrets in AppSec.
- Another finding from the same research shows organisations maintain an average of 6 distinct secrets manager instances, which fragments control.
A question worth separating out:
Q: How do you know an agent workflow is safe enough to delegate?
A: Look for three signals: the action is reversible, the scope is explicit, and the system is inspectable before completion. If users cannot see what the agent will change, cannot undo it, or cannot bound its access, delegation is premature. Safe delegation depends on legibility, not just model accuracy.
👉 Read our full editorial: Agent experience for AI agents: why APIs need a new design layer
