How To Adapt Your Product for AI Agent Users

_{Guest contributor: Till Döhmen is the AI Lead at MotherDuck, building AI-native data products and advancing agentic workflows, developer tools, and intelligent analytics.}

For most of the history of software, the user was a human. What we call user experience was optimized for someone with eyes, intuition, and the ability to navigate ambiguity.

That's changing fast. AI agents are becoming a real user persona for software products. Today, MotherDuck’s internal logs show that agents run more queries through agent-facing interfaces than humans run through the web UI, which shows how quickly this shift is happening. 

That means we now have to think not just about user experience, but about agent experience too. Agents read documentation, operate through model-context protocol (MCP) or command-line interfaces (CLIs), and can even sign up for services on their own. But they do not behave like humans, and products built around human behavior are often hard for agents to use effectively.

Most products are held together, more than we'd like to admit, by human perception and intuition. A human can click through a UI, infer next steps from visual context or memory, and navigate around most rough edges without getting stuck. 

In rethinking our product design for agent-native workflows, we’ve discovered three major challenges:

The friction between human-first product design and agents' needs became apparent gradually, and it pushed us to rethink not just how to make the product technically usable by agents, but also which additional context needs to be shared with agents so they can use the product effectively.

Agents need a way to interface with the external world and execute actions, and MCP works well for that because it combines authentication, tools, and the context needed to use those tools correctly. If your only front door is a visual flow designed for humans, agents get stuck. And while APIs and CLIs are important, agents often struggle with them when they lack clear task-level guidance on what to call and in what order.

Agents are also faster and more exploratory than humans. In data exploration, a human analyst runs one query, reviews results, and follows up. An agent may fire many queries, including in parallel, as it searches for the answer. Infrastructure designed for sequential, human-paced usage will show contention and unpredictable latency when being used by agents.

Once you accept that agents are a distinct kind of user, the fix is not one change but a set of decisions across your product: the interface agents use to connect, the documentation and web presence they rely on to act correctly, the product knowledge they need to accumulate across sessions, and the infrastructure that absorbs how they generate load. These are the adaptations that worked best for us.

Your interface layer: The highest-leverage decision we made to make MotherDuck agent-native was adopting MCP as a standard interface. It gave agents a consistent pathway that worked across various agents without requiring model-specific integrations. Now, AI agents can read databases and column names, translate plain English questions into SQL that’s compatible with the database, and then convert results into visualizations. 

Where MCP isn't the right fit, we provide Agent Skills (markdown guides) that explain how to use our existing APIs and CLI for specific tasks. For local coding agents and workflows that benefit from having access to the local filesystem, we invested in CLI workflows rather than forcing every task through a hosted path. We also added agentic signup, so an agent can create an account that a human claims later, removing a major handoff point. The goal is to lower the barrier for agents to use the product successfully, and to keep evaluating and improving those interfaces as the agent ecosystem evolves.

Your documentation and website: Documentation that works for humans does not work as well for agents. We restructured our information architecture so technical details are easier for models to retrieve and act on: markdown for agent crawlers, HTML for human browsing, and content shaped for GEO so generative systems can extract the right detail, trust the product, and suggest it for the right task at the right time.

Externalize the user's learnings: Human users learn over time how to use a product effectively. For agents to improve over time, that knowledge has to be externalized. We think about this in two buckets. First, how to get complex things done: we publish Agent Skills and Markdown guides bundled for concrete workflows like database migrations that are hard to infer from the docs. Users can customize those further to their needs, and in the way persist and evolve best practices. Second, domain-specific knowledge management. In our case: business context about data, naming conventions, data caveats, and preferences — the things that typically only live in the user's head. Formalizing and bringing this knowledge into the product as a first-class citizen is essential for agents to unfold their true potential. 

Your infrastructure assumptions: We built a hypertenancy model, where each user gets dedicated compute that can scale from zero to hundreds of machines, before we fully understood why it mattered for agents. That architecture turned out to be well-suited to agentic workloads because agent-driven query patterns are bursty, exploratory, and often concurrent in ways human usage is not. Teams starting now do not have to get lucky. Design for that load pattern from the start.

Get a stable, documented agent-native interface in place, and make sure agents can discover it precisely enough to make the right call when a model decides which tool to use for a task. Then run your own product through an LLM-based agent and watch where it stalls, guesses, or hands off to a human. You will find issues in twenty minutes that never surface in human testing. We did, and it changed the order in which we prioritized engineering work.

Agents aren't a new user segment to accommodate around the edges of your existing product. They're a fundamentally different kind of user, and building for agents requires knowing, precisely, where the differences lie.