All work

Strivelabs · Design engineer · 2025 → now

Pluggable UI for agents

Plug and play UI for agents: one command scaffolds a minimal, working agent UI on our platform framework and UX guidelines, with the internals out of sight. Builders write the core logic, and the agent is ready. The concept was our CTO’s; I built the framework, so the team, and later coding agents, could ship agent UIs fast.

Role
Design engineer · frontend tooling
Team
Concept by our CTO · framework by me · agents by the team
Status
~13+ agents, still growing · now slots in chat
Link
strivelabs.ai

At a glance

The problem

We were prototyping agents for early clients and friends, to validate ideas and find product-market fit. The backend already let builders plug a workflow together in no time. The UI had to plug in the same way.

My part

  • The scaffold. pnpm clone-agent-template, which writes a working agent: a form, live progress and an output view.
  • The abstractions. Our CTO’s concept of screens, formulated into a framework in React: three hooks for an agent’s whole run, so builders never touch the underlying details.
  • Consistent by default. Only components from our registry and one icon set, so new agents look like ours from the first run.
  • The doc and the rails. The handover guide, the route-based pattern, a shared layout and skills for coding agents.

Our CTO proposed the concept of screens. The rest of the team used the framework to build their agents.

Shipped

~13+ agents built on it, and still growing. Its patterns now live on in chat, where agent views open as slots beside the thread.

Agents SEO audit pnpm clone-agent-template

Backstory

Plug and play, for the UI too

  • In June 2025 we were prototyping agents for early clients and friends. Our backend let builders plug components into a DAG and have a workflow ready in no time.
  • Our CTO proposed screens: one standard set every agent shares, like configure, install and review. I formulated the framework around it, in React.
If the backend is plug and play, the UI should be too.

Design call · scope

A builder for us, not for everyone

  • One day, we pictured it as a lightweight agent-builder framework, where anyone could build agents the way we did. But the agent-builder space was already crowded.
  • So we kept the DX internal, and put our effort into reliable agents that do the job, with no slop.
Compete on the agents, not on the builder.

Foundations

One command to a working agent

  • pnpm clone-agent-template writes an agent that already triggers a workflow, shows progress and renders output.
  • Builders only wire the backend’s data to the screens. No new components, no padding or colours, no React Router or Zustand to learn.
One command, a working agent. The builder edits three files and keeps the rest.

Design call · abstractions

The platform handles the complexity

Builders write above the line. The platform owns everything below it.

Design call · consistency

Consistent by default

  • The template uses only our component registry (ui-core) and lucide-react icons, so a new agent looks like the rest of the platform from its first run.
  • Every agent moves through the same screens, from an empty state to the result. I designed the first ones as rapid prototypes, straight in code.
Rapid prototypes, designed in code, on the same parts. The Google Ads campaign analyser, from an empty state to a full audit.

Design call · routes

Relax the rails

  • Screens kept every agent inside one narrow UI model. Within a month it felt too restrictive: content agents needed rich, multi-view flows, while a sales agent needed far less.
  • So I relaxed it. With path-based routing, and a team now building with coding agents, each agent gets the interface its use case needs, instead of fitting into one model.
One content agent, four views, one shared layout. If a view matters, it deserves a URL.

Coding agents

Rails a coding agent can follow

  • By then the team was writing frontend code heavily with coding agents. Rough prototypes needed only the design system and standard React guidelines.
  • So in July 2025 I added skills, one more layer of abstraction. Builders didn’t need the platform’s UI concepts in their heads, or in their coding agent’s context.
Good rails work for any builder. The guide, the design system and one good example were enough to keep a coding agent on them.

The turn

Agents can’t work in silos

  • Tasks stopped being siloed, and agents needed to work together. Chat was emerging as the natural way in.
  • So we moved to generated UI in Strive AI right away. Nothing was thrown away: big, dedicated tasks became agent slots, like refreshing content or writing a draft.
The content refresher on its own page: a count of blog posts ready for refresh, an add new blog post button, and a table of blog post URLs with their keywords, status, date and a view or review action. The same content refresher inside Strive AI: the chat on the left starts the blog refresh agent, and the same table of blog posts, keywords, status and review actions opens in a panel beside the thread.
Drag to compare. Same agent, same UI. Now it opens beside the conversation that asked for it.

Today

Hand the UI to the agent

  • Chat answers with our components, where consistency matters. Reports went further: in Strive Studio, the agent writes its own HTML.
  • Next, people build their own apps, not just reports, with agents working together as a team: a multiplayer agentic Marketing OS.
From writing screens to writing the rails.

Misses & lessons

What thirteen agents taught us

  • MissFit every agent into one template of screens.

    LessonRelax the rails before they break. A content agent and a sales agent don’t need the same shape.

  • MissMoved new agents to routes, but left the scaffold on the old screen tree.

    LessonThe template is the real doc. Move it the day the pattern moves.

  • MissLet the guide live in three places, with hook names drifting apart.

    LessonOne source of truth, for people and coding agents alike. Both follow a stale guide faithfully.

  • MissKept making it cheaper to build one UI per agent.

    LessonAbstractions buy speed, not scale. Once agents had to work together, the answer was one surface.

We started by making agent UIs cheap to build. We ended up letting the agent build them.
Agents SEO audit pnpm clone-agent-template Deep dive · ~12 min read Who writes the UI? How agent interfaces evolved in Strive From a scaffold and three hooks, to rails for coding agents, to one chat, to agents writing their own UI. Read the full story

Back to all work