Configuring AI agents in plain language, no engineering required.
Every screen in this case study was created through AI prompt design, using Claude as the design tool rather than building screens by hand. I wanted to see how far I could push AI generated design through prompting alone, treating it as a creative and technical challenge in itself. The design thinking and every decision behind it is entirely my own. This is an exploration of what becomes possible when you pair a designer's way of thinking with AI as the hands.
The people who know the work can't configure the tools.
AI agents are still very new territory. Even now in 2026 many people working in non-technical roles have never set one up and have no real frame of reference for what the process involves. I was curious about the space and decided to try configuring one myself earlier this year to get a proper feel for it.
It was harder than I expected. The interfaces were dense, the terminology assumed a technical background I did not have and I spent more time trying to understand what I was being asked to do than actually doing it. I got there eventually but it took far longer than it should have and I still was not fully confident in what I had built.
If I was finding it this difficult as someone who works in digital products every day, the gap for a customer service lead or operations manager with no product background was going to be significant.
And it was. The same frustration kept showing up in forums and ops communities. People who had been asked to configure AI agents for their teams, tried to do it and hit a wall almost immediately.
"There were too many fields I didn't understand and I didn't want to get it wrong and have it say something weird to a customer."
"In the end our IT guy set it up based on a document I wrote. It kind of works but it doesn't really behave the way I would."
The knowledge was always there. The tools just never asked for it in a way those people could actually answer.
Customer service leads can configure agents themselves without needing engineering support
Teams describe how they work in plain language rather than translating it into something a system can read
Users can preview and correct agent behaviour before anything goes live
What makes configuring an AI agent so difficult?
This frustration shows up everywhere once you start looking for it. Forum threads, product reviews, LinkedIn posts from operations people who tried to automate their workflows and hit a wall. The details change but the shape of the problem is always the same: the person with the knowledge could not get it into the tool without technical help.
Three data points showed this was not a small niche problem.
I audited the tools sitting across different parts of the market to understand what was already out there and where the gaps were.
The gap was the same across all of them. Real configuration depth required technical fluency. Nobody had figured out how to offer both at once. That was the gap worth designing for.
Figuring out who this needed to work for
People managing a single team's process have different frustrations from those juggling multiple workflows across an organisation. Personas are a useful way to keep both groups in mind throughout the design process.
Maya and Jordan are already aware of their problem with existing tools. Once the product matures there would be space to design for a third type of user who is newer to AI agents entirely and needs more guidance and education to get started. For now Maya and Jordan are the focus.
Translating their frustrations into user stories helped me get specific about what the product actually needed to achieve before designing anything.
To define what the product should actually solve for I needed to land on one core problem statement. Based on Maya as the primary persona:
Maya needs a way to configure an AI agent that reflects her team's real process, because every tool available requires a level of technical knowledge she should not need to have.
This is not a minor inconvenience. An agent that does not behave correctly talks to real customers and the consequences of getting it wrong are immediate and visible.
So how do I create a setup experience that is appropriate, genuinely usable for someone like Maya and honest about what AI agents actually are?
To understand what features would serve Maya and Jordan best I mapped out what the product needed to offer against their needs directly. It needed to let users configure an agent in plain language with no logic trees or technical knowledge required, give them a way to review and correct agent behaviour before going live and keep them in control after launch. That gave me a clear feature set to design toward.
I scoped this to the initial agent setup flow on web, from the moment a user starts configuration through to activating their agent for the first time. Post-launch management, team collaboration and template features sit outside this scope but are worth building toward in a future phase.
Imprint will let non-technical users configure an AI agent by describing their process in plain language, without engineering support. I will measure success through usability testing, looking at whether users can complete the full setup flow without assistance and whether they choose to activate their agent at the end rather than going back to edit.
Finding the exact moment things go wrong
Before sketching any solutions I wanted to map how someone actually moves through existing agent builders step by step rather than assume the whole experience needed rethinking. What the user flow mapping showed was that five of the six steps were completely fine. The breakdown was always at step four: configuring logic and triggers. That is the single moment where you have to stop thinking like someone who knows their job and start thinking like someone who understands system architecture.
Finding that the problem was concentrated in one specific step changed the brief considerably. I was not trying to reinvent the entire setup experience. I just needed to replace that one step with something that matched how Maya actually thinks. This led to the central design question:
With a clear problem to solve I started sketching directions loosely before committing to anything, with a no-bad-ideas mindset. Three approaches came out of that exploration worth developing further.
Form-based
The obvious starting point and I explored it properly rather than dismissing it early. The problem is that a friendlier form is still a form. Maya is still being asked to take what she knows and convert it into fields and categories which is exactly the translation problem I was trying to eliminate. The interface looks simpler on the surface but the cognitive work is identical. Not the right direction.
Drag and drop
More promising. A visual node builder feels more intuitive than a spreadsheet of conditions and for users who think spatially it works reasonably well. But the mental model underneath is still technical. You are connecting triggers to actions with a nicer interface over the top. Jordan might get through this but Maya would not. I could see this working as an advanced editing view for a later phase but it was not the right entry point.
Conversational interview
This worked because it flipped the dynamic entirely. Instead of asking Maya to structure her knowledge the interface does it for her. It asks questions, she answers however feels natural and the system interprets it. She never needs to think about how the agent works underneath. It was the only direction where the translation burden sat entirely on the product rather than the person.
Getting the structure right before touching screens
With the conversational interview chosen I mapped the information architecture before designing any detailed screens, because getting the phases wrong here would mean building the right screens in the wrong order. Four phases came out of that mapping, each with a distinct job.
Early on I had a version that went straight from Teach to Live and skipped Trust entirely. The reasoning seemed sound: if the interview went well, a preview step was just adding friction before the finish line.
But one question kept bothering me. How does Maya actually know the interview went well? She answered some questions and the system said it understood but she has not watched the agent handle a real situation yet. Asking her to hand over customer conversations to something she has never seen respond felt like too big a leap, especially given that one of her core frustrations is having no way to verify the agent is behaving correctly until something goes wrong. Trust stayed in and it ended up being the most important part of the whole experience, because it is the moment where confidence either forms or it does not.
I worked through different directions for each core screen through prompting, exploring variations before committing to a final design. The goal was to figure out what each screen actually needed to do before deciding how it should look.
An earlier direction led with product benefits on the welcome screen. Testing the concept with the persona in mind it became obvious quickly that promotional language does nothing for the hesitation Maya brings into a new tool she has already failed to use once before. Switching to three plain facts, ten minutes to complete, five steps and nothing goes live until you say so, answered the things she actually needed to know before clicking anything.
Using step segments rather than a progress bar came out of thinking about progressive disclosure. A progress bar implies an unknown distance. Step segments show Maya the exact shape of what she has signed up for before she starts, which removes one more reason to hesitate.
One question at a time, open text field and no example answers. An earlier exploration included example prompts to help people get started but they consistently produced more generic responses. People pattern-match off an example rather than describe how they actually work and for Maya that means the agent ends up reflecting the example rather than her real process. The blank field got more genuine answers every time so I kept it empty.
The confirmation card is the interaction I felt best about across the whole project. After each answer Maya sees what she wrote and directly below it what the agent understood from it. If the interpretation is off she can edit it on the spot. That moment of comparison is where she starts to build a real mental model of how the agent thinks, directly addressing her frustration of never being able to verify what it actually knows.
Guardrails got their own screen because they are a categorically different kind of decision from the playbook interview. The interview covers typical situations. Guardrails are about edge cases where getting it wrong has real consequences and a dedicated screen signals that difference rather than letting it get lost in the interview.
My first direction for this screen was read-only. Maya could watch the agent respond to scenarios but could not change anything. Going back to her frustrations it became obvious that was exactly the wrong call. A preview you cannot act on does not solve her core problem, it just surfaces it in a more visible way. Making the responses editable inline turned it from a source of anxiety into something genuinely useful.
The scenarios run in a deliberate order too, starting with the most common situations and working toward edge cases. By the time Maya sees the agent mishandle something tricky she has already watched it handle several familiar situations well. That context makes a real difference to how she interprets the mistake and whether she feels ready to fix it rather than abandon the whole setup.
The go-live screen summarises what the agent knows before asking Maya to activate it. It is less of a checklist and more of a deliberate pause before a significant handoff, giving her one last moment to feel genuinely ready rather than just clicking through to the end. The "not ready, keep editing" link gets equal visual weight to the activate button for exactly that reason.
The pause button sits permanently in the top navigation on the dashboard. Early feedback called it visual clutter and honestly that is a fair point. But for Jordan, who needs to move fast and update things as processes change, being able to stop the agent at any point without hunting through settings is what tells him he is still in charge of something now running on his behalf. Tidying it into a menu would have made the screen cleaner and slightly less honest about what it is.
Walk the whole journey, end to end.
Looking back at the original goal, the test was whether non-technical users could complete the full setup independently and feel confident enough to activate their agent rather than going back to edit. Maya has a way to describe her team's process in her own words and see exactly how the agent understood it before anything goes live. Jordan can move through setup quickly and knows he can adjust or pause the agent without needing technical help.
One thing this project made me think about more broadly is how you know when an AI output is wrong. For someone like Maya there is no obvious signal.
It is something I want to keep exploring as AI products mature because I do not think the industry has figured it out yet.
The part I would revisit first is the Teach phase. The conversational interview works well for clear straightforward scenarios but there are situations where someone knows something is important and struggles to articulate it as a direct answer to a question. A follow-up prompt along the lines of "can you give me an example of when that has come up?" might get closer to the nuance a single open question sometimes misses. That would be the first thing to explore in a proper research round with real users.
After all, no product is ever truly finished.