A weekly report told me I was wrong about a feature I had already decided was fine. In Fiuto you could share a study, the test you send out to respondents, and you could share a launch, one run of that study with the results it came back with. You could not share the insight, the analysis the AI writes from those results. Then I looked at the competition, and that gap stopped being fine.
This is the first article of arc three, research in automated design: the earlier arcs built features end to end, and this one asks what gets built at all. Research does two jobs here. It runs inside the pipeline when I deliver a feature, and outside it when I decide what to work on next.
Where research sits in the pipeline
I work through two skills, /build and /ux. A skill is a named set of instructions I hand to a fresh agent, so it starts with the process already in its head. /build delivers a feature, /ux designs one. Those two are the creative ones, the ones with a clear output. Both have a research agent inside their pipeline, and in /build it runs before planning.
The rule that agent carries is one line: every finding must change a plan decision. Anything that changes nothing gets dropped, however interesting it is.
The market lens has an order too. Comparable tools first, with table stakes separated from differentiators. Cross-sector analogues only when no close competitor exposes a similar pattern. Without that order an agent will reach for an analogue from another sector before it has checked the tool sitting next to mine.
How the research is briefed
The research is briefed at a named audience. I have two targets. People like me: designers, user experience managers, researchers, product owners. And small teams without the budget to hire a specialised researcher, or a designer who can also run the research process.
That audience is familiar with coding agent tools like Lovable and Replit. They live in Notion and Linear, very modern tools with a specific feel to them, so I have to be careful about how the designs are shaped.
I do not brief against usability practice, UX practice, or accessibility requirements. Those are floors. I brief against what my audience already opens every day, because that is what they expect out of the box. I can improve on it. I cannot go under it. In my experience that makes the designs better and it takes fewer iterations.
The weekly report
Research inside the pipeline is per feature. Separately there is a routine that runs in the background every week. I call it best practices.
It goes through the competitive landscape and the trends in the sector I was going to attack once the app was out, then writes a report into the repo as markdown. Each section ends with what the finding means for Fiuto, and carries its sources. One week it also generated a fancy presentation, which is not required. The markdown is the part that matters, because an agent can read it later.
The job of the report is to discover things I did not know, which is why it needs checking.
Checking the report against the product
One entry that week was about UserTesting, and it read like marketing speech to me. So I opened the product. It is not too bad. Maze has a little bit of marketing speech as well, and it pitches the full loop, which is what I want too. I think I am going to get there more aggressively than they will. Sprig is very good, and it targets the enterprise market, completely different from what I am doing. That is great for me.
The report points. You verify.
From a report finding to two projects and an initiative
I read the report and come out with one idea. Normally one.
That week it was half formed already. The insight feature was quite complete on its own, but not being able to share it limited what one user could do with another. Initially I thought that was okay. Looking at the competition, I decided we needed to complete the loop.
So I shared the markdown file with an agent and asked what was missing. It said a public toggle. That is not 100% correct. There are a few other things, and the toggle is the smallest of them. But the same reply listed things I had missed in the data, which is worth the imprecision.
The reply surfaced more than the toggle.
- The sharing options. That is what I had gone in asking about, and more was missing than the toggle.
- MCP parity. Fiuto’s MCP server is the interface other people’s coding agents use to drive the product. It is quite complete, but I had not updated it in a while, so I was fairly sure several tools that exist in the app were missing from it. Good reminder.
- Continuous discovery, which to me is two projects rather than one. I did not investigate the second one.
- Three more that read to me as placeholders for things I could deliver later.
The main things were the sharing options and the MCP, and I wanted both delivered before release.
Then I asked the agent to write that into Linear as two projects and one initiative. First project: sharing and collaboration, so insights would reach full parity with studies and launches. Second: MCP parity plus improvements, because I had been thinking about improving the MCP before release anyway. The initiative covers the last four items, which I can pick up later with a separate agent and break into several projects. I think they need further investigation.
Neither project had started when I recorded this. The sharing one has been built and running since, and the app has soft launched.
Handing it back to the pipeline
I opened a fresh agent, gave it the link to the new project, and asked /build for the full pipeline, including research. Research had been done. I thought it was worth having some more done anyway.
From there it runs research, plan, implement, and on. It is a very long pipeline. It is worth it, because what comes out at the end is shippable. That is not the same as finished. I review it again after it lands, and in practice that is every time.
Running this with your own agent
None of this depends on my repo.
- Write your audience down once, in the file your agent reads before anything else, usually
CLAUDE.mdorAGENTS.md. Name where they already work and what they use daily. Be specific enough that it rules people out. - Say what the floor is, in the same file. Usability practice and accessibility requirements are it. The target is the standard set by the tools already in your audience’s stack.
- Put a research step before your planning step, with one rule attached: every finding must change a plan decision, drop the rest.
- Fix the market lens order. Comparable tools first, table stakes separated from differentiators. Cross-sector analogues only when no close competitor does the thing you are designing.
- Schedule a weekly landscape report. Have it write markdown into your repo, not into a chat window. Ask each section to end with what the finding means for your product, and to keep its sources. Ignore the prettier formats it offers.
- Verify before you plan. Open the real product behind anything that reads as a threat, and behind anything you are about to concede.
- Hand the report back to an agent and ask what you are missing. Expect the verdict to be partly wrong, and read the reply for the things you had not noticed rather than for its conclusion.
- Turn what survives into projects and tickets in your tracker, then hand one of them to your build pipeline and let it research again.
The next article takes that sharing project from research outcome through to delivery.
