AI Agent Builder and API Index

DcentraLab builds tools for developers and marketers in web3. As a PM intern reporting to the Head of Product, I owned two distinct workstreams over three months: building the AI Agent Builder from concept to UX-ready flows, and defining the pricing strategy, pricing page and go-to-market plan for a new API product on the existing platform.

Challenge

The Agent Builder was a product concept with nothing behind it: no structure, no flows, no UX decisions made. I had to define what the product was before it could be designed, with no budget for user testing.

The API Index was the opposite shape of problem. An existing web data platform expanding into API access, with no pricing model, no pricing page and no go-to-market strategy. Both needed to reach handoff-ready.

What I did

With no testing budget, I grounded the work in competitive research across every accessible AI agent builder platform, comparing features, flows and UX patterns so the structural decisions rested on something other than my own assumptions. To be exact about what that was and was not: secondary and competitive research only. I did not interview users or stakeholders here.

I then defined the Agent Builder from scratch, product structure, UX architecture and flow decisions, co-authored the V1 PRD with the Head of Product, and delivered lo-fi wireframes to the design team plus full end-to-end flows for development handoff. The significant call was layout: I weighed a multi-step wizard against a single page and chose the single page, keeping the full configuration visible and cutting navigation overhead.

Figma flows for the AI Agent Builder, showing the single-page configuration layout with all options visible at once. — Agent Builder flows in Figma. The single-page layout won over a multi-step wizard: configuring an agent is a task people iterate on, and hiding half the settings behind steps meant re-navigating to change one value.

On the API side I co-authored the technical specifications and PRD with the Head of Product. I owned product concepts, use cases and UX decisions; he translated them into technical scope and architecture.

The pricing model was the part I cared most about getting right, and it was settled cross-functionally. I proposed one fully customisable plan, priced by the data categories a customer selects, with a declining rate per additional category. Tiered plans were eliminated deliberately: they force the user to work out which package they fall into, which is a decision they should not have to make. Complex enterprise needs route straight to sales.

The API Index pricing page, showing the single customisable plan priced by selected data category with a declining per-category rate. — The API Index pricing page, which I designed end to end to reflect the model. One plan, priced by what you actually select, with the volume discount visible as you add categories rather than buried in a comparison table.

I wrote the GTM plan, then pressure-tested it with the Head of Product and the marketing team to align on business goals, tone and execution before handoff.

Outcome

Both workstreams were delivered to handoff: the Agent Builder as end-to-end flows ready for development, the API Index as a PRD, a pricing model, a pricing page design and a GTM plan. I left the company before execution, so what the team ran with was the strategy as handed over. What happened after that is not mine to claim.

2 workstreamsBoth taken from zero to handoff-ready

Learning and reflection

Competitive research is a legitimate design input when user testing is not possible, but you have to be honest about what it can and cannot validate. It told me what conventions existed. It could not tell me whether they worked.

Pricing is a UX decision. One flexible plan with a volume discount is not just a business model; it removes a decision the user should never have been asked to make.

A deliverable you will not execute yourself has to be self-sufficient. Knowing I would hand the GTM plan over forced the same discipline as writing a good PRD: no ambiguity, no assumptions left unstated.