AI Agent

By 2025 the platform had a library large enough that clients described it as working against them. A canvas redesign was already in flight, and clients knew it — one told me plainly that they weren't willing to wait for it, and weren't confident it would fix their problem when it landed. I benchmarked how automation and integration platforms handle assisted building — n8n, AWS, Digibee, where I previously led the monitoring domain, alongside Copilot, OpenAI, Claude and Manus for interaction patterns around transparency, control and trust. That told me what was possible. It didn't tell me what our clients needed, so I went and asked them.

While engineering focuses on implementation, my role is to define the product experience and interaction model — translating technical capabilities into a coherent, scalable, user-centred design vision that will be fully realised once the engine is finalised.

To ensure strategic alignment and market relevance, I ran benchmarking and comparative analysis across leading automation and integration platforms such as n8n, AWS and Digibee — where, as a former team member, I led initiatives in the monitoring domain — as well as best-in-class AI products including Copilot, OpenAI, Claude and Manus. Those references informed expectations around interaction patterns, transparency, user control and trust in AI-assisted workflows.

Main reference: Microsoft Copilot Studio

Copilot Studio became our primary reference. It solves the same problem we face — letting people build, customise and publish agents on top of company data — and it does it with a vocabulary our users already recognise from enterprise tooling. Three things we deliberately borrowed: agents described in natural language, a library of ready-made agents and templates as the default entry point, and an explicit split between conversational and autonomous behaviour.

“Copilot Studio is a platform for creating and managing agents. Connect those agents to your company data, build your own with natural language, and publish everywhere your teams and customers are.”

Microsoft Copilot Studio

The feature narrative is organised around a lifecycle — create, customise, deploy, manage — rather than around screens. Two of its four pillars shaped how we framed our own pilot: “build conversational capabilities”, where agents answer questions, guide workflows and complete tasks using company data; and “add autonomous capabilities”, where agents plan, learn and escalate work items when needed. That distinction gave us a way to scope the pilot conversation-first while keeping autonomy on the roadmap.

What we did not adopt: the Microsoft 365 surface area and its licensing-driven navigation. APIPASS has one product to integrate against, so the agent lives inside the platform rather than across a suite of channels.

The study

Six client teams told me the canvas asked them to know too much — over 500 components, no guidance, and no way to tell whether a pipeline was any good until it ran. Every one of them asked to build less, not to learn more. I designed an agent that suggests the right components as clients build, step by step. The first version — one that built pipelines outright — failed, and what shipped is narrower.

“I can't always rely on APIPASS to build all my integrations.”

The sentence that came up more than any other

Taken at face value that's a usability complaint, and the usability fixes were obvious — better onboarding, inline hints, clearer docs, a curated component library.

“Every client asked to build less, not learn more.”

Research finding

Methods: screening, then interviews, then usability testing with six client teams. Client names are withheld under NDA; the research board is anonymised by column.

What surprised me

What surprised me was the direction of every request. Not one client asked to learn the canvas better. They asked to do less of the work: "I want to say 'I want a pipeline to do X' and the canvas builds it FOR ME."

We built the thing they asked for. It didn't work.

The first direction was the one clients asked for literally: an agent that builds the pipeline for you. It failed on its own terms. Memory consumption ran far past what we could support. The output stayed generic. On anything complex, it froze. That result reset the scope. We kept the half that worked — guidance at the moment of choosing — and used templates to cover the cases where clients genuinely wanted assembly rather than advice. Templates are a compromise and I'd describe them as one: they handle the common shapes and leave the hard ones to the client, with the agent alongside.

The failure clarified something the research hadn't. Clients said build it for me, but what actually removed the cost was knowing which component fit and which didn't. The literal request and the useful one weren't the same thing.

The agent space

Users interact directly with the agent to learn about the platform and request the creation of features or assets, and can ask for guidance on how to build specific solutions or workflows. Conversations can be exported and reopened at any time, and chat interactions can be turned into reusable prompts — supporting continuity and scale.

Creating an agent

This section lets users define an agent's capabilities by configuring parameters, writing custom prompts or importing existing ones. Once created, agents can be shared, edited and reused across teams. By default users start from a library of templates — either as-is or customised into a new agent. Advanced users can also build an agent from scratch with code when they need deeper technical control.

Clients asked to build less. What shipped lets them decide less. That gap is the honest summary.

What I'd do differently

I'd test the engine's ceiling before designing for the ambitious version. We spent design effort on an interaction the system couldn't hold, and found out late.

I'd also change how I took the request. Six teams asked for an agent that builds pipelines. Building exactly that failed; building the reasoning behind it worked. Next time I'd treat a unanimous feature request as a symptom to interrogate, not a spec to deliver.