Building a workspace for people and their agents

The first brief for the agent pipeline, dated May 27, 2026, started with this idea: "Expecting AI to shorten 3 months of work to a 2-hour generation is crazy today. You can shorten the time but you can't avoid the work the team needs to do to create the context and understanding to successfully complete the task. AI is the assembly line." Later I put it more simply: "ai is changing the way we work. it is a new and powerful tool that forces us to redesign how we work to produce reliable, quality outcomes."

The first version was Loopsteer, started the same week: an interface for watching and directing agent pipeline runs. By June 12 I was not happy with it: "we have been workkning on loopsteer for a while but it is not the ui i want yet. how do i improve this?" The next repo called itself "One product out of the scattered Loopsteer surfaces." A few days later that became Loopstr, the repo I have worked in since June 16. The numbers are on the project page.

How I worked with the agents

I rarely wrote code. I said what I wanted, read what came back, opened the running app and said what was wrong. Claude Code did most of the building. Codex came in later, as a second reviewer of pull requests and as a builder on its own branches; the shared-product work in September arrived on a Codex branch.

On June 24 Claude offered a definition of Loopstr that I took on: "the production pipeline for the whole org, grounded, gated, and steerable, where a human shapes the work at every decision point instead of approving a black box." I wrote back "i like this specific and all above convo. lets make sure we are capturing these with what is loopstr". A run moved through stations and stopped where a person had to look.

Use your own tool

On July 10 I asked Claude for alternative mocks of the operator desk. Eight mocks came back from agent makers, and every number on them was invented. I wrote "honest fewdback .this is all shit. what are you grounding this with?" and then "why dont you use loopster". Claude agreed it had done by hand "the exact job loopstr exists to do", with fake data, when the real desk was one dev server away. The next day I asked it to "use loopstr to create a few landing marketing page for loopstr". Two weeks later I asked that every session treat Loopstr as a live source, not only as the code being edited.

The direction kept moving

Between August 7 and September 10 the repo got six dated direction documents. On September 2 I asked "i want to understand where the market need is". Claude's answer, after reading recent laws and surveys, was: "The need is not generation and not an approve button. It is the review stage: proving a competent human substantively looked at AI output." Three days later Loopstr was a "verifier", and the belt of stations was retired as the product.

That didn't last. On September 8 the direction changed to the team. The direction note from that day puts it as: "We're asking individuals to compress their expertise into prompts. I want AI to work through the team's expertise." The note from two days later records me saying "but we need one main build that everyone aligns." The direction from September 10 is the one Loopstr follows now: people and their agents contribute to one shared product, each in their own workspace, and every contribution is followed through to its effect on that product.

Looper

In October I started a smaller, new repo. Looper begins with a founder who has an idea and no team. An agent plans backwards from outcome goals and proposes which seats are agents and which are people. Agents open pull requests in your GitHub repo and comment in your Figma file, on your own AI account, and merging a pull request marks the task done. Claude wrote 111 of its first 125 commits, made between October 7 and 13.

What making it taught me

A lot of the work went into rules around the agents: every change starts as a story with a measurable result, more than a hundred CI gate scripts check each change, and an unknown value stays blank instead of becoming a guess. They were needed, because work that looked done but wasn't was the most common failure, and keeping the rules correct became work of its own.

My idea of the product changed as I used it. Opening the app and asking the agents to use it helped me see what needed to change.