How I brought familiar marketplace patterns into a platform for agentic team building and testing

AI Refinery Studio's Library is where people browse, evaluate, and “hire” autonomous AI agents and pre-built agent teams to do real work. When the catalog jumped from a handful of agents to more than a thousand, the discovery experience that worked for sixteen fell apart completely, and the whole thing had to be rethought. I contributed to that redesign in my first months ever working in AI, learning how agentic systems actually work fast enough to make real senior level design contributions almost immediately.

Client: Accenture
Deliverable: Agentic team building platform
Duration: 3 months
AI Refinery Studio Library

Overview

The experience layer for enterprise AI

AI Refinery Studio is the place where users create, customize, and test teams of AI agents. It sits on top of AI Refinery, the platform's agentic foundation and SDK. The foundation could already produce powerful agentic technology; what it lacked was a surface where a human could actually reach in, assemble a team of agents, and try it out. Studio is that surface.

AI Refinery Studio experience layer

Where the Library fits in the bigger picture

Before anyone can build an agent team, they have to find the right agents. That's the Library. Only a small fraction of organizations get durable value out of AI, and the platform's bet is that a well-designed experience layer, not another SDK, is what closes that gap. The Library is the front door to that layer. Get discovery right and everything downstream (evaluating, assembling, deploying agent teams) has a foundation to stand on.

Where the Library fits in the platform

Two very different users, one catalog

The platform serves two audiences with almost opposite instincts. Experienced developers want fine-grained control, speed, and the ability to skip boilerplate. Low-code and no-code business users want guided, visual tools and the confidence to act without writing code. The Library has to be legible to both from the same shelf: a developer scanning for a specific MCP server and a business analyst browsing for “something that can summarize customer feedback” both have to leave with the right agent.

Two very different users, one catalog
Pain points & goals

When a shelf of sixteen became a warehouse of a thousand

The Library began as a short list you could read top to bottom. As the catalog grew past a thousand agents and teams, that approach collapsed, and a harder problem surfaced underneath the scale: an agent isn't a product, so people had no established way to judge one. The work was to design discovery and the vocabulary people would use to evaluate an unfamiliar kind of thing. These are the goals that framed it.

Scale discovery to 1,000+

Make a catalog that grew from sixteen agents to more than a thousand agents and teams navigable, without burying anyone in noise.

One place, two search instincts

Support open-ended browsing and targeted search in the same experience, so both the person exploring and the person hunting for one specific agent find their footing.

A vocabulary for evaluating agents

Surface the signals people need to judge an unfamiliar kind of thing: what an agent does, how well it does it, and whether it fits the task at hand.

Trust through transparency

Show how an agent performs, how secure it is, and who built it, because people are handing real work to something that acts on its own.

Flex for developers and business users

Serve fine-grained control for engineers and guided, visual discovery for non-technical users, from the same shelf.

Groundwork for a marketplace

Lay a foundation that can grow into a true agentic marketplace as the catalog and the audience keep expanding.

Solutions

Getting fluent fast enough to lead

I joined this as my first project in AI, on a team already moving at speed, and I came in senior, which meant the expectation wasn't to observe and catch up. I was to make real design decisions almost immediately, in a domain where I was, at week one, a novice. Agentic systems were genuinely new to me: orchestrators, super agents, utility agents, MCP, the whole architecture of how autonomous agents get composed into teams. There was no established design playbook to lean on either, because very few people had designed discovery for agents at all. So the work was two things at once: ramp up on a complex, fast-moving domain, and contribute at a level that justified my seat while I was still learning it.

I went straight at the concepts I'd be designing around: what distinguishes a super agent from a utility agent, how agents call tools, what an MCP server exposes, why security grading matters for something that can act autonomously. I learned it not to become an engineer, but to know exactly which signals a user needs to evaluate an agent, and which are noise.

With no agentic-discovery precedent to copy, I studied the marketplaces people already trust, the ones that make finding one thing among thousands feel effortless, and used that familiar grammar as a starting point I could ship against on day one, then bent it to fit agents. Borrowing a proven pattern is what let me contribute at pace before I was fully fluent.

Discovery is the first thing every user touches, so getting it right early mattered to the whole team. I focused my contributions on that surface, working closely with product and engineering to pin down what was actually possible at 1,000+ agents, and helping make the discovery experience something the rest of Studio could build on.

Solutions

Design solutions

The Library had to feel as easy as any marketplace people already know, while carrying information for a new, pioneering domain. Here are my designs and process to bring this vision to life.

Library discovery homepage

My Library designs borrow proven marketplace patterns, each one reshaped for the job of building agentic teams.

Comparative research across marketplaces

Comparative research

I studied how search and marketplace homepages work across wildly different products, from game stores and streaming to template galleries. Then I pulled the patterns that fit our use case into the discovery process for the Library.

Search behavior comparison

Search

I compared several search behaviors to find the right fit for browsing agents, weighing speed, precision, and how much guidance each one offered. That comparison set the MVP and pointed toward a richer future state.

Filter set for agents

Filter

I went deep enough into the domain to understand how someone would actually filter agents and which groupings would help. The result was a filter set built around the real questions people ask: what type of agent, who made it, and how safe it is.

Homepage grouping explorations

Groupings

I explored different ways to group agents on the homepage, mapping each layout to how our two user types actually browse. The goal was a page that feels organized to a developer and a business user alike.

Bookmarks feature

Bookmarks

Bookmarks let people carve a library of thousands down to the handful they care about. It turns an overwhelming catalog into a personal, curated shortlist they can return to.

Viewing agent details in layers

Viewing agents

Agent details unfold in layers: a surface view to quickly spot what you're looking for, and a deeper view, with in-library testing, when you need to evaluate or compare performance. People spend attention in proportion to how close they are to choosing.

Insights

Designing for agentic

The Library was one instance of a much bigger question the whole team kept running into: what changes about design when the thing you're designing for is autonomous? I helped shape the themes we landed on. These are the ones the marketplace work taught me most directly.

Agent card showing performance, security and provenance

Transparency

Autonomous systems only get trusted when people can see how they perform, what they consume, and what they're doing. The agent card exists because trust in an agent has to be shown (performance, security, provenance) not assumed. Like accessibility, this visibility work is often the first thing to get cut, and advocating for it is part of the job.

Guided and granular entry points

Adaptability

Users vary enormously in fluency and intent, so the same experience has to offer different entry points, guided for the non-technical, fast and granular for the developer, without dumbing anything down for either.

Curated collections and pre-built teams

Guidance

Faced with a thousand options, people freeze. Curated collections and pre-built teams are guidance: they turn an overwhelming catalog into an approachable starting point and accelerate the leap from idea to something real.

Non-linear discovery paths

Fluidity

Agentic work is iterative and rarely linear. People wander, revisit, and compare, so discovery has to preserve context and support multiple paths rather than forcing one route.

First-party, partner, community and MCP agents unified

Interoperability

An agent marketplace has to hold first-party, partner, community, and MCP agents together, each with its own conventions, in one coherent experience. Unifying those patterns was as much service design as screen design.

Inventing and validating new patterns

Experimentation

There was no existing pattern for most of this, so part of the work was inventing patterns that could survive a rapidly moving space, and validating them with real users instead of assuming.

Conclusion

Understanding the AI era

I was on this project for about two and a half months, and the Library was my focus. It shipped as part of the Studio MVP and became the discovery foundation the rest of the experience assumes. I contributed to specific pieces of the discovery experience rather than owning the whole redesign, and the platform-level results belong to the broader Studio and Refinery team, which I was one contributor to. What I take from it is less a metric than a capability. I can ramp into an unfamiliar, complex AI domain and make senior-level contributions fast, and I now think fluently about designing for agentic systems.