A one-month experiment in agent behavior design, and why the most important interface you'll ever design has nothing to do with screens.
I didn't set out to build a lead generation agent. I set out to answer a question that had been bothering me for a while: what actually makes an AI agent experience good?
My instinct, as a product designer, was to go straight to the interface. Redesign the interaction patterns. Make it feel more natural, more human. That's where designers live — in the surface, in what's visible and touchable. But the further I got into this experiment, the more I realized I was asking the wrong question entirely.
Touching the GUI first doesn't solve the problem. It decorates it.
Good agent experience doesn't come from better screens. It comes from better decisions — and the logic that produces them is buried layers deep, far from anything a designer traditionally touches.
That realization sent me on a one-month journey from surface to substrate: from interaction design to behavior design, from frontend thinking to backend architecture, and eventually to a question I'd never had to ask about a product before — what are this agent's values?
This is the story of that journey. Not a tutorial. Not a framework. Just an honest record of how my thinking evolved — iteration by iteration — and what I think it means for designers who want to work seriously in the age of AI.
Why a lead agent? Why this problem?
A lead agent is an AI system that handles the early stages of a sales conversation — qualifying prospects, understanding their needs, building initial rapport, and deciding when to pass them to a human sales rep. It sits at one of the most trust-sensitive touchpoints in any business: the moment a potential customer first reaches out.
I chose this as my experiment ground for a specific reason. Lead generation sits at the intersection of psychology, process, and trust — three things that are genuinely hard for an AI to navigate well. It's not a task where you can just hook up an LLM and call it done. You have to think carefully about how the agent behaves, what it prioritizes, and when it should step back and let a human take over. That made it a good stress test for the design questions I actually cared about.
I also wanted to build something with real stakes. A lead agent that handles trust poorly doesn't just give a bad experience — it damages a relationship before it's even started. That pressure kept the design thinking honest.
The starting point: workflow dressed up as intelligence
Iteration zero was a classic intent-driven bot. User sends a message. System extracts intent. System evaluates fit. System responds. Clean, deterministic, easy to debug.
It was also, I'd later understand, deeply naive. The architecture assumed that customers know what they want and say it clearly — that sales is a transaction with defined inputs and outputs. Anyone who has ever sold anything, or been sold to, knows that's not remotely true.
[Iteration 0] — The intent-response loop
User prompt → intent extraction → fit evaluation → response. Simple, deterministic, and blind to the actual dynamics of human persuasion. The agent could answer questions. It couldn't read a room.
The limitation forced the first real question: how does a professional human sales expert actually think? Not what do they say — but what are they tracking, sensing, responding to, underneath the words?
The first shift: from workflow to behavior
This was the inflection point. Moving from what did the user ask? to what state are they in?
intent → response → signal → emotional state → strategy → response
The insight underneath this shift was simple but profound: people don't buy on logic. They move through emotional states — curiosity, hesitation, skepticism, trust, readiness — and a skilled seller tracks those states and responds accordingly. The words are almost secondary.
So I built a psychological state machine. Awareness, curiosity, evaluation, hesitation, trust-building, decision-readiness, commitment. Each state carried different signals, different strategies, different response patterns.
[Iteration 2] — The buyer psychology state machine
The first real behavior layer. Instead of mapping inputs to outputs, the agent now tracked emotional trajectory. This is much closer to how elite human sellers operate — not script-followers, but state-readers.
This was also the moment where I stopped being a UX designer in the traditional sense and started becoming something harder to name. A behavior architect, maybe. Someone whose job is to define not how the interface looks, but how the agent thinks.
The human handoff: the most mature insight in the project
There's a temptation in AI product design to make the agent do everything. It's autonomous. It's always on. Why would you ever loop in a human?
The answer I landed on: because some moments aren't about information. They're about trust — and trust, at certain depths, still requires a human to compound it.
AI compresses time. Humans compound trust. The handoff isn't failure — it's architecture.
This realization completely changed the product model. Instead of an autonomous agent replacing a sales rep, I was now designing a collaboration system: AI qualifies, AI nurtures, human builds deep trust, human negotiates, AI supports throughout. The agent became a co-pilot, not a replacement — and that made it far more powerful.
[Iteration 3] — The hybrid handoff model
Challenged the assumption that AI should own the full lifecycle. Introduced human touchpoints for trust-critical moments. The product stopped being a bot and became a collaborative system.
Two audiences, two layers
The biggest architectural mistake in iteration two was treating the agent as though it had one audience. It doesn't. It has two — the customer it's engaging, and the human sales rep it's supporting — and those two audiences have almost nothing in common.
A customer needs warmth, pacing, emotional attunement. A sales rep needs signal clarity, efficiency, actionable briefings. Sharing one behavior layer between them was like writing one document for two completely different readers. It served neither well.
[Iteration 4] — Dual behavior layer architecture
Separated customer-facing behavior from rep-facing behavior. Different tone, different action authority, different information hierarchy. This was the shift from "assistant" to "multi-role collaborative agent" — and probably the most significant architecture decision in the project.
What made this insight feel mature was recognizing that the design problem wasn't about features — it was about system boundaries. Who talks to whom, with what authority, and for what purpose. Classic systems thinking, applied to agent behavior.
The orchestration breakthrough: modeling who should act
The final major evolution was a collaboration mode state machine. Instead of only modeling customer psychology, I started modeling something more fundamental: who should be acting right now?
Four modes emerged:
| Mode | What it means |
|---|---|
| Autonomous | Agent handles the customer independently. Standard qualification, early nurture, information delivery. |
| Alert | Agent pauses and briefs the rep. High-value signal detected. Rep gets a clear, contextual handoff. |
| Shadow | Rep is live; agent supports silently. Real-time suggestions, objection handling — invisible to the customer. |
| Relay | Agent drafts; rep approves. The agent does the cognitive work; the human provides judgment and sign-off. |
This was the answer to the 24/7 async trust problem — how do you maintain continuity and responsiveness while still involving a human at the moments that matter? You don't choose between AI speed and human judgment. You design the transition between them.
What I didn't realize I was building
When I look back at the full arc of this project, I'm genuinely surprised by the breadth of it. Not because I was trying to be ambitious — but because each iteration was just the natural response to the limitations of the one before it. I was following the problem, not a plan.
What I thought I was doing: learning how to design a behavior layer for an AI agent.
What I was actually doing: working through the full evolution from feature design to agent systems design — behavior architecture, trust modeling, collaboration orchestration, infrastructure abstraction.
The most important thing I built in six iterations wasn't a system. It was a way of thinking about systems.
The philosophy underneath: defining the soul first
Here's the thing I couldn't have articulated at the start of this experiment but feel certain about now: designing an agent is fundamentally different from designing a traditional product, and the difference isn't technical — it's philosophical.
In traditional UX, you design interactions. You define what happens when a user clicks, swipes, submits, waits. The system is reactive. The designer controls the surface.
In agent design, you design values. Before you can define behavior rules, you have to decide what the agent stands for — what it will and won't do, how it weighs competing priorities, what kind of presence it brings to a conversation. The behavior layer is downstream of the value layer. And the value layer is something designers have never had to think about before, at least not this explicitly.
You have to define the soul of the agent before anything else. And that means asking questions that feel more philosophical than technical: What does this agent believe about the people it serves? What is it unwilling to do, even if instructed? What does a good outcome look like, and for whom?
This is where I think the UX designer's role is genuinely shifting. Not from frontend to backend — though that framing is useful — but from surface designer to value architect. The interface is now the agent's behavior. And the designer's job is to define what drives that behavior, layer by layer, from values all the way down to code.
Where I'm taking this next
This experiment isn't finished. The architecture is stable enough to build on — but the harder work of testing it against real customer interactions, refining the collaboration mode transitions, and stress-testing the dual behavior layers in practice is still ahead.
More importantly, I want to keep pushing on the value design question. What does it mean to specify an agent's values rigorously enough that its behavior is predictable, trustworthy, and improvable? That feels like the open design problem of the next decade.
I'm also thinking about what this means for designers more broadly. If the most important design decisions in an AI product happen in the behavior and value layers — far from any screen — then design education, design processes, and design portfolios all need to change. This project is, in part, an experiment in what that change might look like.
More to come.
Design thinking evolution — at a glance
| Phase | Thinking mode | Core question |
|---|---|---|
| Phase 1 | Workflow thinking | If user asks X, do Y |
| Phase 2 | Behavior thinking | What emotional state are they in? |
| Phase 3 | Trust systems thinking | When should a human intervene? |
| Phase 4 | Multi-role thinking | Customer layer + rep layer + shared memory |
| Phase 5 | Infrastructure thinking | API layer + orchestration + provider abstraction |
This post is part of an ongoing experiment log on AI agent design. The next entry will cover early test findings.
Top comments (0)