AI Agents Builder. The story behind the screen

Victoria Apakidze
Aug 9
4 min read

Updated: Aug 10

How we went from “Why can’t the tool do this for me?” to a 5‑minute agent‑creation flow.

Where the Project Came from

November  2024, Tel Aviv. SysAid was entering a bold new phase - aiming to infuse AI into the product in ways that would genuinely simplify daily work for IT teams.

The goal? Help users stop wasting time on repetitive tickets like “Add Azure AD user” or “Run WLAN diagnostics” and start solving higher‑value problems.

Product Management kicked off the initiative with a clear direction: make it possible for anyone, not just developers, to build their own automation agents.

My role as the product designer was to take this ambitious idea and help to turn it into something intuitive, efficient, usable and innovative-looking from day one.

My Role & Team

Role: Product Designer (embedded with 1 PM, 4 developers, 1 tech writer)

Scope: UX strategy → wireframes → hi-fi UI → spec hand-off → design QA

Timeline: 1 month for a quick rollout, 5 months for enhancements; 4 major iterations

Challenges

No playbook. There was no references for this. No playbook. No best practices. AI-agent builders were brand new.
Widget overload. Initial concepts concentrated too much content and functionality into a single screen, which felt overwhelming and it complicated the overall experience.
Complex ≠ Complicated. We needed enterprise‑grade power that still felt simple and looked as modern as the tech behind it.

"How might we let non‑technical IT staff create and test their own AI agents without drowning them in configuration screens?"

Laying the Foundation for Flow

From day one, I anchored the interface around three essentials: an agent list, a floating widget (Building Block) and a conversational AI-powered chatbot. I made the decision to shape them into a clear, three-lane structure to support how users naturally move through the experience:

Left · The Directory

I kept every agent in a scrollable sidebar (later options to search, filter or switch without opening a modal were added)

Center · The Building Block

The floating widget surfaces the must-knows: name, description, permissions, parameters and versions, so you stay oriented while you work.

Right · The Chatbot

Here the real building happens. You tell the bot: “Create an Azure AD user agent” and it assembles the logic step by step, asking clarifying questions when needed.

Pick, review, build - one clean rhythm that lets users move forward without losing context.

This wasn’t just visual balance, it was a cognitive structure. Everything that came next built on this layout.

When One Widget Wasn’t Enough

My first draft lived inside a tidy floating panel. It demoed well until the requirements list began to snowball. Audit logs, schedulers, parameter presets, version history… every new must-have squeezed the widget tighter. Within two sprints it felt less like a tool and more like trying to write a novel on a sticky note.

To keep pace, I set up twice-weekly design huddles with the PM and tech writer. We opened the live Figma, walked through a scripted task and asked one blunt question: “Could a brand-new admin still finish this in under a minute?” These micro-critiques stood in for formal usability tests and gave us rapid, actionable feedback.

The sessions pushed the design outward:

Full-width workbench replaced the cramped widget, giving every field breathing room.
Sticky footer anchored essential controls: Publish, Test, Version, no matter how far you scrolled or expand.
Smart accordions folded away advanced settings until they were actually needed.

By the fourth iteration, internal reviewers could complete the flow unprompted - a signal that the layout finally matched the ambition.

If I Had Another Sprint

If I had more time, I would focus on deepening the experience post-launch, turning the tool from functional into truly intelligent.

First, I’d introduce data-powered guidance. Many new admins still guess when it comes to schedules and triggers. I’d use real ticket data to suggest smart defaults like showing that most agents run weekly at 17:00 and asking: “Want to try that?”

Second, I’d build visibility into what happens after publishing. Right now, once agents go live, there’s no easy way to know if they’re working as expected. A simple “Agent Health” view could surface run success rates, errors and overall performance over time.

Finally, I’d refine onboarding. While the chatbot and layout help, some first-time users still rely on help docs. A lightweight, progressive onboarding experience with in-product nudges that appear only during a user's first few builds would smooth the ramp-up even more.

What This Project Taught Me

Tight deadlines sharpen thinking. There wasn’t time for overthinking. From day one, we had a live demo deadline breathing down our necks, so I learned to design with urgency and clarity. No extra screens, no speculative features, just what absolutely needed to be there to prove the idea worked. Working under that kind of pressure forced me to prioritize not just what to design, but what not to.
When there’s no map, look sideways. There were no real design patterns for building AI agents, so instead of searching for perfect references, I started looking at the structure behind tools people already trusted. How do they introduce complexity gradually? What makes them feel calm even when they’re powerful and complex?

AI Agents Builder stretched every part of my process: rapid iteration, systems thinking and decision-making under pressure. It reminded me that the most interesting problems often start with no clear path forward. In a very limited period of time, we went from an idea to a working product that teams could actually use. And that’s the kind of challenge I’d take on again any day.