Make AI Agents: from confusion to trust and adoption.
Agents do not follow the path you draw. They choose one. We had to make that choice visible enough for people to trust the agent.
The short version
Challenge
Introduce agentic decisions without breaking the mental model of a deterministic automation product.
My role
I led product design end to end and took on product-definition work during a PM transition, from discovery and technical framing through launch and adoption.
Outcome
A canvas-native agent experience with visible reasoning, practical debugging, and a clear path from first try to useful automation.
Impact
Tools per agent more than doubled and ratings rose ~20%. The Library drove 61% of new agents, but only 7.5% reached a first run.
Make had taught people to expect certainty.
Make is a visual automation platform for connecting apps and building workflows. Its logic is visible: you place modules on a canvas, connect them, and inspect what moves between them. Run the same scenario twice and you expect it to follow the same path.
That predictability is why people trust the product with real work.
Agents broke that expectation.
As AI agents moved from experiments into real products, we were looking for the right way to bring them into Make. The first version proved that an agent could use Make's tools and act on a goal, but it still felt closer to a promising concept than a product people could confidently build with.
That is where my work began. Our goal was to make agents understandable, trustworthy, and useful for real work without losing what made Make feel like Make.
We started with people already trying to make agents work.
I combined in-product feedback and limited behavioral data with discovery calls: eight people who struggled to reach production and eight power users who had made agents work. I shaped the study with our UX researcher; she led operations, and we synthesized the evidence together.
Across all three sources, agents averaged only around 0.3 connected tools. Some people did not know tools could be added, and even successful users described execution as a black box.
Three blockers kept coming back:
- The experience was fragmented. Setup lived partly outside the canvas.
- Decisions were invisible. People could not see how the agent interpreted instructions or chose its next step.
- Use cases were unclear. Many did not know when an agent was the right tool.
A good demo can make an agent look clever. A useful product has to show people what it is doing and give them a way to fix it.
Before refining the interface, we had to decide where the agent belonged.
The research left us with a basic question: where should an autonomous system live inside a product built around deterministic workflows? The category was still new, and there was no settled model to borrow.
I led a broad exploration with product and engineering across a guided setup, a nested canvas you could zoom into, and a flat canvas-native model. Each direction solved part of the problem. But every step away from the main scenario also removed the context people needed to understand and troubleshoot the agent.
The canvas won. Then it had to survive reality.
The canvas gave us the right model. Now it had to fit Make's actual constraints. I worked through the agent API, tool calls, and legacy canvas with engineering, then designed a complete flow the platform could support.
This was also when my scope expanded. During a PM transition, I temporarily took on more product-definition work. I turned the research into the V2 model, shaped scope and success signals, and kept setup, testing, execution, and adoption connected while a new PM onboarded.
Tools needed a different visual weight.
After exploring connector styles, shapes, and levels of emphasis, we landed on smaller circular tool nodes with lighter connections. They read as capabilities available to the agent, not as ordinary steps in the scenario.
Details appeared when they became useful.
Names had to work for both people and the agent deciding when to call a tool. We kept names visible, revealed descriptions on hover, and made both easy to edit without filling the canvas with text.
The boundary of control had to be explicit.
At field level, builders could set a value themselves or let the agent fill it from context, with optional instructions. The interface made that handoff visible instead of hiding it inside a prompt.
Testing made the product less technical.
Once the pieces worked together on the canvas, we put the concept back in front of users. The tests supported the canvas model and changed several details.
People still stumbled over labels such as System prompt, User message, Thread ID, and Context. With our UX writer, we changed them to Instructions, Input, Conversation ID, and Knowledge. The underlying model stayed the same; the interface stopped asking people to speak like the API.
From the start, I treated inspectability as a launch requirement.
Moving the agent onto the canvas solved where it lived. The harder trust problem remained: after pressing Run, people could see the result without knowing why the agent chose a tool, what information it used, or where something went wrong. Without that trace, the product could produce answers. It could not earn trust.
The Reasoning panel was part of my first complete concept. It made decisions, tool calls, inputs, outputs, states, and errors readable instead of treating debugging as something to add later. A live context bubble showed what the agent was doing on the canvas and opened the same trace when clicked.
Believing in it was not enough. I had to make it buildable and hard to cut.
A readable execution trace was expensive to render inside the legacy canvas, and stakeholders questioned whether it belonged in scope. I worked directly with engineers to trace what the API exposed, identify what the canvas needed to render, and shape a version we could credibly ship.
I then put the prototype in front of advanced users. Four of five preferred the Reasoning view. For them, it made the difference between trying an agent and trusting it with real work.
The reaction to the prototype was immediate.
This is exactly what I need.
That is awesome!
I brought the interaction proof, research evidence, and feasibility work together to get the panel through the scope discussion. One final validation with an automation expert changed the stakeholder response from “too expensive” to “we have to build this.”
Inspecting a run was useless if fixing it was slow.
A workflow-level chat sounded simpler, but Make could not reuse pinned upstream outputs. Every message would rerun the surrounding scenario, including modules unrelated to the agent, and consume more credits and operations. So I designed a dedicated chat that could test and improve the agent in isolation.
I designed an in-canvas testing chat where people could send sample inputs, watch decisions and tool calls unfold, change the agent or its tools, and retry the same input without leaving the scenario.
Build, configure, test, inspect, and improve. The full loop now lived on the canvas.
The chat needed its own interaction system.
The agent chat was being designed alongside Make's AI Assistant. I used the opportunity to define shared foundations both products could build on: how a response is structured, how tool activity appears, which details stay quiet by default, and how execution feels while it is happening.
01
Anatomy
Thinking, content, tool calls, and the action toolbar became explicit blocks with clear relationships.
02
States
Collapsed, expanded, running, successful, and error states covered the whole execution cycle, including the moments before a finished response.
03
Progressive detail
Timing, file actions, inputs, and outputs appeared when relevant instead of competing with the main answer.
For engineering handoff, I documented the component anatomy and interaction rules, then moved toward small coded motion prototypes. Two seconds of behavior often explained the intended transition better than another page of Figma annotations.
A great product was only half the story.
I put as much design effort into adoption as I did into the product. If people could not see where an agent would help them or how to get one working, the experience inside the canvas would not matter.
I pushed for the Library of Agents and worked with our team, community members, and external experts to fill it with examples drawn from real work. It gave people something useful to start from instead of an empty canvas. Launch data later showed that people were finding agents more easily than they were getting them working.
Designing adoption meant following the whole journey.
I mapped every route from ads, banners, and articles to the right product destination and next useful action. The path changed with product state: someone with no agent needed different help from someone who had built one but never run it.
The map connected those conditions to the banners, walkthroughs, Help Center content, and launch materials other teams needed to create. Teams could see what each user needed next and who had to provide it.
The launch had to speak with one voice.
I used the journey to coordinate work across product marketing, customer support, the Help Center, and content. I created and reviewed visual materials, and helped shape the launch video's structure, story, and message.
Shipping the agent was not the finish line. Getting someone to a useful first agent was.
Launch motion piece
The campaign film introduced the product promise and visual language rather than walking through the interface.
Product walkthrough
A deeper explanation of how agents work in Make and how the pieces come together in practice.
More tools, better ratings, and one stubborn drop-off.
People connected more tools and rated the experience more positively. The Library also made the weak point obvious: people were finding agents, but too few reached a first run.
- Tools per agent
- >2×
- Feedback rating
- ~20%
- Library → first run
- 61→7.5%
An early signal that more people understood tools as central to the agent model.
Higher average in-product rating than the previous version.
The Library drove most new-agent creation, but only a small share reached execution.
These are early launch signals. They do not show mature retention or long-term production outcomes.
The takeaway: trust is part of the product.
The canvas gave the agent a home. People still needed to know what it could do, understand why it made a decision, and correct it when something went wrong.
Every layer had to tell the same story: the agent could choose what to do, but its decisions would stay visible and correctable.
An agent can make its own decisions without hiding them.
Design principle
Trust is structural.
Setup, execution, debugging, and recovery have to use the same mental model. If one becomes opaque, the product feels unreliable again.
Launch feedback
The weak point moved to setup.
People understood tools better and rated V2 more positively. The drop from the Library to a first run showed where the product still lost them.
Next focus
Get more agents to a useful first run.
I would start with better setup guidance and reusable agent definitions, then strengthen human approval and recovery and give V1 users a clear migration path.