Aviator Studio Composer | OpenText | 2025.07 - present
Rethinking Agent Creation: What if we could build AI agents
without the help of engineering?
Team: 1 Product Designer,
4 PMs, 25+ Engineers
My Role: End-to-End
Product Design
Before Aviator Studio, building an AI agent at OpenText meant filing a request and waiting on an engineering team. A business analyst who knew exactly what they needed couldn't act on it. Every change, every test, every "what if we tried it this way" went through a developer queue. Agents took weeks to ship and longer to adjust. The people closest to the work had the least ability to build for it.
Aviator Studio is a platform being built at OpenText that helps teams create, test, and manage AI agents without needing to write code. The goal is simple: make AI automation easier to use while giving advanced users the flexibility they need.
I've been part of the project from the beginning, through changing requirements, new ideas, and multiple phases of development. Working alongside product and engineering teams, I helped shape how users create, test, and manage AI agents while keeping the experience approachable for people who aren't AI experts.
— Key metrics post launch
Agents created
1,200+
Agent Simulations Run
10,400+
Active Organizations
40+
User Satisfaction rating
4.3/5
— How it started
A POC. A summit. And then everything changed.
It started with a single screen. I built a proof of concept that brought AI agents into one place, making them easier to discover and manage. The idea was simple, and so was the brief. We presented it at an internal summit. The reaction caught us by surprise.
What started as a small concept suddenly became something much bigger. Our CTO at the time, Savinay, challenged us with a new question: What if business users could build their own AI agents, without writing a single line of code? That question changed the direction of the project overnight.
The scope expanded. Expectations grew. What had started as a simple concept was now becoming a product. And I had six months to help figure out what that product should be.
I was excited. I was also overwhelmed. The deadline was tight, the direction was new, and nobody had a clear picture of what the final thing should look like. But I knew that was exactly the kind of problem worth solving.
— The conditions
Three phases. Three teams. And me in the middle of all of it.
This project never sat still. It moved through three phases, and each one came with a different team, a different set of priorities, and a slightly different idea of what we were even building.
June 2025
Small team, early exploration
Building toward a POC
Wasn't even called Aviator Studio yet
August 2025
BU forming fast
Product in the spotlight
New people every week
No PM in place
December 2025
Stable team, finally
Release plans taking shape
Finally some velocity
Different teams, different visions, and through all of it I was the person who stayed. Nobody handed me that role. I held it by being the one who still knew why we'd made the decisions we'd made, every time the people around me turned over.
A few things never changed, no matter which team I was working with:
Speed
Users switch between 3 or more tools to complete single task involving documents.
Ambiguity
The requirements kept moving. The direction shifted more than once, and some work I'd already done had to be unwound when it did.
Context switching
Each new team showed up with its own picture of the product, so I kept rebuilding shared understanding from zero.
— Before I touched Figma
I figured out who does the work before I tried to map the work.
I didn't start with wireframes. I started with people.
The use case I built everything around was insurance claims. That wasn't random. The POC had already been poking at financial and insurance scenarios, and claims processing is about as tangled as enterprise workflows get. My logic was that if the design held up there, it would hold up almost anywhere.
But I didn't draw a single flow until I'd mapped the humans first. Who actually touches an insurance claim? A Claim Adjuster, a Loss Adjuster, a Claim Underwriter, and a handful of others, each with their own goal, their own data, and their own authority to decide things. You can't sensibly map the work until you know who is doing it and what they're allowed to do.
— Mapping the work
With the people clear, I mapped the whole claims process end to end. That's where it got useful: the map showed where an agent could just take the task off a person's hands, where it could help but not decide, and where it had no business being involved at all.
I also did the unglamorous homework. I read up on how agents actually get built, spending time with LangChain, Google ADK, and Crew AI. I wasn't trying to become an engineer. I just wanted to understand the moving parts: the instructions, the tools an agent can reach for, the knowledge it pulls from, how it works through a task. Knowing that genuinely changed the decisions I made on screen.
All of it pointed to two users the product had to serve:
Primary user
Business user
The person who builds and tests the agents. They know their workflow inside out but have little patience for complexity when they're just getting started. They need room to try things and refine, not just a form to fill in.
Supporting user
Developer / Admin
The person who keeps the whole thing running. They decide which tools, models, and knowledge sources are available, and they watch how every deployed agent is performing.
— The core design question
You don't build a good agent in one go. So how do you let anyone keep trying?
Reading those frameworks taught me one thing fast: nobody builds a working agent on the first attempt. The whole model is build, test, see what breaks, adjust, go again. Iteration isn't a nice-to-have, it's the actual job.
So the question I kept circling was how to make that loop feel easy for someone who isn't technical.
One creation flow was never going to cut it. Some people show up knowing exactly what they want. Others are still working out what the agent should even do. If you force everyone through the same door, you lose most of them. So we gave people four ways in, depending on where they're starting from.
The Orchestrator
Visual flow builder
Flow builder Wire several agents into one workflow on a visual canvas, so you can see exactly how work passes from one to the next.
The Expert
Build from scratch
Build from scratch Set the instructions, tools, and knowledge sources by hand. Full control for people who arrive knowing exactly what they want to build.
The Adaptor
Ready-made templates
Templates Start from an agent that already works and shape it to your needs. Editing something real is far less daunting than facing a blank screen.
The Explorer
Prompt-based building
Describe what you want in plain language and Studio drafts the agent for you. Built for people who know the problem but not yet the instructions.
Here's the part I'm proud of: none of these four were in the brief. They came out of the research, and they ended up on the actual product roadmap. That was the point where my work stopped being "make the screens" and started being "decide what we build."
— The bigger picture
Creating an agent was only the front door.
It's easy to think of Aviator Studio as "the thing that builds agents," but building is just the first step. An agent has a whole life after that. It needs to be tested, evaluated, deployed somewhere, watched while it runs, and eventually retired. And around all of that sits the unglamorous but essential stuff: who's allowed to use which tools, how agents reach external systems, how a long-running job tells you it's done.
I designed that entire surface. The lifecycle below is the spine of the product, and each stage was its own set of screens and decisions.
Build & test
The four entry points, plus an in-product way to test an agent from a chat or a form and watch its reasoning trace before trusting it.
Deploy & monitor
Pre-deployment checks, version management, an admin monitoring view, and analytics on how each agent is actually performing.
Invoke
Once live, an agent can be called from MyAviator, dropped into a content workflow, or hit directly through an API.
And then there were all the things that make it real.
A platform that companies will actually trust needs more than a nice builder. A lot of my work went into the parts you only notice when they're missing.
Agent Teams
Multiple agents working one job, passing context down the line. The challenge was making a multi-agent system easy to follow.
Tools, MCP & knowledge
Connecting agents to external tools, MCP servers, and knowledge sources, plus RAG for files uploaded straight to an agent.
Scheduler triggers
Letting an agent run on a schedule, on its own. Designing for work that happens while nobody's watching.
Org groups & sharing
Who in a company can use which agents, tools, and models. Dry, but it's what makes a rollout safe.
Notification center
Once agents ran in the background, people needed to know when a job finished or needed them.
Admin setup
Wiring up models, tools, and secrets before anyone builds. A quieter experience for a different user.
The hard part was never any single screen. It was keeping all of this surface speaking the same language, so it read as one product rather than fifteen features stitched together. Consistency across that much scope was the real design work.
— A closer look
The part I'm most proud of: four ways to build.
Of the four ways in, here's how each one actually works, from the fastest start to the most control.
— The Adaptor start from a template
Not everyone wants to start cold. The gallery has ready-made agents for common jobs, like summarizing documents or scanning for security gaps. Each one is a working agent you can adapt rather than build. It's the fastest way in when your need is close to something the platform already solves.
— The Explorer describe it, let the system draft it
For anyone staring at a blank page, this writes the first draft for you. Describe the job in plain words, and the system proposes the instructions, picks the tools and knowledge, and sets up the variables. You step in to adjust instead of starting from nothing. It turns an intimidating setup into something closer to a conversation.
— The Expert build from scratch
This was the hardest screen to get right. An agent has a lot of moving parts, and the easy mistake is to throw all of them onto one page. I split it into a plain description, the instructions in normal language, and a side panel for the technical pieces, so someone can read it top to bottom and still follow what their agent will actually do. Full control, for people who arrive knowing exactly what they want.
— The Orchestrator wire agents together
For the most complex cases, the flow builder lets advanced users connect several agents on a canvas, so you can see exactly how work passes from one to the next. The goal is to make a multi-agent system something you can look at and understand, not just something that runs quietly in the background.
Pulling all of this into one coherent product, with the same language across every entry point and a layout that worked for both the business user and the admin, was most of the four months. The screens above are the visible result.
The proof it works is what people have built with it. The insurance claims case I designed around became a real multi-agent demo, with three agents handling different stages of the claim and passing context between them. Teams have also built agents for loan evaluation, document extraction, and enhanced due diligence. Someone even built a sarcasm detection agent and started using it internally before we'd officially shipped that piece. That's the moment a tool stops being yours and starts being theirs.
The reason all of it holds together is something less visible, and that's what I want to talk about next.
— What held it all together
Design intent, the thing I leaned on when nothing else held still.
Carrying the product through three phases of constant change taught me to rely on something I eventually started calling design intent.
It isn't a file or a template. It's the whole pile of understanding you build up over time: the research, the domain knowledge, the reasoning behind every choice you made. It lives in your head and your notes, not in a deliverable.
When AI tools can spit out a plausible screen in seconds, intent is the thing that lets you judge whether the screen is actually any good. It's what separates designing something from just generating something.
I had to write mine down constantly, especially in the stretch when there was no PM and nobody else holding the full picture. Those notes became the project's memory every time the team turned over.
— A test of that approach
It paid off most when a newly formed team needed the wider product vision pulled together for VPs and architects. The input was a pile of conflicting ideas from different people, and the real work was deciding what to cut. Because I already knew the users and the calls we'd made, I could tell what mattered from what didn't and shape it into a direction the room could get behind.
— Where it landed
From a single screen to a product people are using.
Aviator Studio is in early access today, with 142 monthly active users, a growing list of early-adopter customers and live demos at summits in Australia, Singapore, and the EU. Teams have built real agents on it, from multi-agent insurance claims to loan evaluation and document extraction.
Along the way, the design work shaped the product itself, not just its surface:
On the roadmap
Research became product strategy
Clarified complex document workflows early, reducing scope debates and stakeholder misalignment
In production
The whole lifecycle shipped
Build, test, deploy, monitor, and invoke, plus Agent Teams, tools, triggers, and governance, all in users' hands in early access.
In the process
Design earned a seat earlier
UX moved from receiving decisions to helping make them, with design now in the room before direction is set.
Studio is the clearest version of our agent strategy we've had. I show it to other leads and barely have to explain it.
CTO, in our stakeholder review
You kept surfacing problems we hadn't thought to ask about. A few of them reshaped what actually shipped.
Evgen, PM on Aviator Studio
First agent tool that didn't make me feel like I needed to be a developer. I described what I wanted and it worked.
Operations lead, early adopter customer