Loopy

Agents, Skills & Loops

Loopy started as a set of custom skills and agents to help me design faster. It quickly became my go-to for a client who needs to move quickly from an idea to something people can try. We prototype, test with users, collect qualitative and quantitative feedback, and use what we learn to decide what happens next.

Before Loopy had a name or an interface, I was doing all of this agentically. I had a loose system spread across OpenClaw, Claude Code, and Cursor. It was held together with prompts, skills, plug-ins, and a growing cast of agents I had tuned for different jobs.

It worked, but it lived in my head. I knew which model to use, which agent needed more context, when a critique was useful, and when an answer only sounded convincing. Running the process meant conducting it by hand every time.

Loopy grew out of a simple question: could I turn that personal setup into a repeatable way to make and test ideas without sanding off the judgment that made it useful?

I don't think one model wins

A lot of AI products are built around access to a single model. My experience has pushed me in the other direction.

I think we are heading into a multiple-model world. Different models are good at different things, and that changes quickly. The interesting part is the harness around them: the roles you define, the context each agent receives, the tools it can use, and the way one agent hands work to another.

That is what I had been building for myself. Mia, my designer agent, was there to open up possibilities and make things. Dieter, the critic, was there to be difficult. Other agents handled research, evaluation, implementation, or verification. They were not magic employees. They were parts of a process I had shaped over time.

Loopy makes those relationships visible. The models can change. The working method is the product.

The client need made it real

The client needed a faster way to explore ideas without turning every question into a full product cycle. A clickable prototype is useful, but only if it helps answer something. A user test is useful, but only if the question, method, and evidence hold together.

My improvised agent workflow could already produce work quickly. The weak point was continuity. The original brief, design decisions, critique, prototype, test results, and next iteration could easily end up scattered across sessions and tools.

So I started pulling the whole loop into one place:

1. Write a brief that is specific enough to evaluate.
2. Explore genuinely different ways to solve it.
3. Choose a direction and build it.
4. Critique and score the work before treating it as finished.
5. Put it in front of people.
6. Carry the evidence into the next round.

The loop sounds obvious written down. Keeping every lap connected is the hard part.

Three directions should mean three directions

One of the first problems I ran into was fake variety. Ask one model for three concepts and it will often give you the same layout three times with different styling.

I changed the system so each direction gets its own agent session and the same pinned brief. Before anything is built, Loopy finds a real axis in the problem and places the directions at different points along it. The concepts are rendered and compared. If two collapse into the same idea, one goes back around.

In one working run, a survey brief produced three different interaction models: a focused one-question-at-a-time flow, a scrolling conversation that kept earlier answers in view, and a fixed workspace. Those were choices a designer could actually react to, not three colorways pretending to be strategy.

Mia makes. Dieter pushes back.

Once I choose a direction, Mia builds it. Dieter reviews it.

I named the agents because I wanted their responsibilities to stay clear. Mia is supposed to find a way forward. Dieter is supposed to question whether the work deserves to move forward. If both agents are optimized to be agreeable, the loop becomes theater.

The critique looks at the brief, the design system, accessibility, craft, and whether the direction is still distinct from the alternatives. Some checks are deterministic. Others need visual judgment. I make the call at the gate.

The score is there to provoke a decision

I did not want a scorecard that handed out a tidy grade and congratulated itself. Its job is to make the next decision easier.

A direction can be approved, steered, or rejected. Approve means it is ready to publish and test. Steer sends written direction into another lap. Reject closes it instead of letting a weak idea survive through momentum.

The scorecard keeps the reasoning attached to the work. I can see which brief and design-system version the agents used, what failed, what changed, and why I let it continue.

A prototype is not an outcome

My first version of the system ended when I approved the design. That was neat, and wrong.

The client work made the gap obvious. We were not making prototypes for the pleasure of making prototypes. We were using them to learn. Loopy needed to support the research after the design review, not stop at the handoff.

An approved iteration can now become a stable test link. I can run a qualitative usability study, collect structured feedback, or use a mix of methods depending on the question. For external tests, Loopy publishes a study bundle to Netlify, adds the feedback mechanism, syncs responses back into the project, and closes the deployment when the study is over.

I tested that path with a real client prototype: publish it, collect feedback, bring the evidence back into Loopy, and use the findings to shape the next brief. I call the gap between what we expected and what people actually did “drift to reality.” That gap is usually where the useful stuff is.

What AI changed for me

I am the idea maker and the executor on Loopy. I set the product direction, design the system, write and tune the agents, make the interface decisions, and build the software.

I also would not have been able to do this at the same scope or speed without AI.

That is part of the project, not something I want to hide in a tools list. Loopy is a working product, but it is also a record of what a designer can do now. I can move between product strategy, interaction design, research planning, front-end work, orchestration, testing, and deployment without waiting for a full team to assemble around every idea.

AI does not remove my judgment from the process. It gives that judgment more reach. The quality still depends on the brief I write, the relationships I set up between agents, the examples I provide, the gates I refuse to automate, and whether I notice when the work is drifting.

From Plumbline to Loopy

The project was originally called Plumbline. At the time, I was focused on design-system drift and checking whether an output stayed true to its source.

As I used the system, that framing started to feel small. The useful part was not the final compliance check. It was the movement: make something, question it, test it, learn, and go around again.

That is why it became Loopy. Ideas take laps.

Where it is now

The current beta handles structured briefs, project context, three independently generated directions, concept selection, the Mia and Dieter handoff, scorecards, approve/steer/reject routing, test publishing, feedback collection, outcome evaluation, and a human-approved next brief.

Because other people can use it now, I have also added approval-gated signup and organization-level separation for projects, studies, files, and artifacts. The less glamorous boundaries matter when agents can touch credentials and run jobs on someone else's behalf.

The next phase is less about adding more agents. I want to see whether the process holds up across more client work: whether the scores are trustworthy, whether the research setup produces useful evidence, and whether each lap gets the work closer to what people actually need.

My role

Loopy is my product. I created the idea and lead the strategy, design, research approach, agent system, implementation, and deployment.

I use AI collaborators throughout the work, including research, writing, coding, critique, and verification. I decide how those collaborators are set up, what context they receive, where they are allowed to act, and when a human decision is required. That's simply how I work now.

See Loopy for yourself

Loopy is live. Visit loopy.design and take it for a lap →