Role
Founding designer. Co owned the MVP with a design lead, end to end.
Team
2 designers, 2 directors of PM, engineering, docs.
Timeline
Concept to general availability, about 3 months.
Launched
June 2024, on the Imagine keynote stage.
Overview
Automation Anywhere runs more than 400 million automations a year for enterprises where a wrong answer has a cost. When generative AI arrived, the users who build those automations had never written a prompt.
AI Agent Studio is the part of the platform that connects a model, turns a prompt into a reusable skill, drops it into a process, and records every run for audit. One support email shows the whole thing: it gets scored for tone, angry ones go to a person, calm ones get an article, and every prompt and answer is logged.
My role
Automation Anywhere's claims, Imagine 2024
Pendo
I have heard of generative AI. I just do not know what a model is.
Sue · Citizen DeveloperAutomation Anywhere's software runs 400 million office tasks a year. Most of the builders there are citizen developers, who assemble ready made steps and do not write code.
Adding AI normally means learning what a model is, getting keys from a cloud provider and writing code. Asking that of a citizen developer means changing how they work.
How do we let them build with AI inside the tool they already use, without changing the way they work or what they need to understand?
We looked at some of the top platforms in the industry to learn how they were bringing agents into their workflows.
What we picked for the MVP
An admin sets up the provider, model and version once. Builders pick the connection by name.
Write the prompt once and leave a variable where the data goes. The automation fills it with a real email on every run.
A name and a note on what changed, on every version.
Token count and cost estimate on screen before anything ships.
Every one is an element on the shipped workbench. Click the screen to open it full size.
An admin sets it up once. Builders never choose a provider, a model or a version.
Competitors exposed every dial they had, and most went untouched. We kept the ones that change the answer and put them in front.
You fill the blank with sample text to test it, and the automation drops in the real thing on every run.
Every test run returns accuracy, tone and toxicity, so a weak prompt is caught early.
A builder can mute logs on one skill while testing, and only if an admin allows it.
Three months from the first requirement to general availability. Most of the second half went into review loops.
Design principles
A seamless experience end to end, across every persona involved, was the priority. These six kept us to it.
Match the mental model builders already have from the Control Room.
Everything happens inside the Control Room, so nobody learns a second tool.
You can see what the model did, from setup through every run.
Any builder, from citizen developer to professional, can use it without special training.
Catch mistakes before the model runs, and make them easy to fix.
Every control on the workbench does a job. Nothing is there for looks.
A customer writes in about a late order. That one email passes through four roles before it gets an answer, and each of them works on a different screen.
Automation admin
Owns the Control Room. He sets up the model connections and decides which roles are allowed to use them.
Pro developer
Writes and tunes the prompts, and compares models to find the one that answers best for a use case.
Citizen developer
Builds processes from ready made steps. She does not write code and had never worked with a model.
Governance lead
Audits what the models did, and checks that no sensitive data went into a prompt.
JakeAutomation adminA wizard with four panes, each a decision Jake already knows how to make. The key never leaves the credential vault, the connection tests itself before it can be saved, and sharing is a role.
MarcusPro developerModel at the top, parameters on safe defaults, the prompt with a slot for live data, sample input on the right. Marcus runs it, dislikes the answer, switches to Jake's new connection without touching a key, and saves.
SueCitizen developerThe skill is one action on the canvas, next to the Salesforce step and the email step. The email goes in, a tone score comes out, and a branch on that number does the rest.
RochelleGovernance leadJake turns on data logging. Rochelle opens the prompt log, filters to the last 24 hours, opens a session, reads the prompt, the answer and the parameters, and exports the record or forwards it to the security team’s monitoring system.
The same support email, before the four of them and after.
Every email waited for a person to read it, then for another to fix it.
Calm emails get an answer without a human. Angry ones reach one faster, with the case open.
An automation runs the same way every time. A model does not. It can answer differently on two identical runs, and it can be sent data nobody meant to share with it. Automation Anywhere's customers run regulated work, so every answer needs a record of how it was produced.
Automation Anywhere frames it as a loop of three things, each one feeding the next.
Stop what should not happen. Who is allowed to use a model, and what an answer scores on accuracy, tone and toxicity before it ships.
See what actually happened. Every prompt and every answer written to a log an auditor can filter, open and export.
Check it is still good. Benchmark a prompt against known answers, and compare one model with another.
The first release shipped observability in full, and the part of guardrails that runs while you build. Data masking and model evaluation came in later releases.
Individual runs are one view. The admin also needs the aggregate: which models are actually being used, by which automations, and what they are costing in tokens.
Five models across four vendors were live on day one, and the list was going to keep changing. So a model is a connection an admin sets up, not a choice a builder makes.
Hugging Face, custom model definitions and Enterprise Knowledge followed six months later. The wizard and the log did not change.
Designing a probabilistic system inside a deterministic platform was mostly choosing when to show uncertainty and when to hide it. The scores under an answer and the log behind a run did more than any new component.
Some patterns we picked because they were emerging in 2024 are now defaults. Some I would design differently now that the platform has a reasoning engine.
The flows got clear the moment each screen had a name on it. Jake, Marcus, Sue and Rochelle are why a stranger can follow this page.
This is the high level version. The decisions behind the screens, the dead ends, and the things I would do differently are better in conversation.
