The discovery loop: your product already knows what to build next

Last week Yotam, one of our engineers at Stencil, came to me with a gnarly bug: builders were losing conversation context mid-project. The agent would just... forget. Real frustration, the churn-inducing kind. He congratulated me for catching it.

I didn't catch it. Discovery caught it. An agent that reads our chat history fished the pattern out of roughly 600 messages, matched it across eight different users, and filed the ticket with the evidence attached.

None of those eight users reported it. It never hit Slack. Nobody complained. They just quietly had a worse day, eight separate times, and the only thing in the building that noticed was a cron job.

That's the moment this piece is about.

"What's next" was always the game

Stencil is a vibe-coding platform — domain experts describe a micro SaaS, and an agent builds it. So I think about self-improving products for a living, and here's my claim: the discovery layer is the most critical layer of a self-improving product. Not the coding agent. Not the merge gate. Discovery.

The reasoning is almost embarrassingly simple. Implementation is solved — I've written before about loops that ship code and the merge gate that reviews it. Point a coding loop at a well-specified problem and it grinds it into dust. But who points it?

The hardest part of getting any product to maturity was never writing the code. It's deciding what deserves to be built next. And the raw material for that decision is all there, piling up: analytics, session recordings, error tracking, support tickets, chat history, feedback widgets, competitor moves. The problem isn't that you're working on the wrong things. The problem is capacity. Processing all of that signal is a full-time job for a team you don't have, so almost all of it goes unprocessed — and your backlog fills with whatever happened to be loudest, instead of high-quality work items backed by evidence.

Your agents aren't limited by what they can build. They're limited by what you can feed them.

That's the gap nobody warns you about: coding agents multiplied your build capacity overnight, and your signal-processing capacity stayed human-sized. The memory-loss bug sits in message 412 of the chat history — not ignored, just never read.

You can hold six threads. Maybe.

The deeper reason discovery is the critical layer isn't about products at all. It's about your head.

It's not that I can't investigate a bug — I do, daily, with Claude. But a chat with Claude is synchronous. I'm holding the thread. And a human holds three of those at once, maybe six on a great day. That's the real ceiling on how fast a small team improves a product: not typing speed, not agent quality — the number of open threads a brain can carry.

Discovery inverts the ownership. The loop asks the questions. The loop holds the memory. The loop connects yesterday's weak signal to today's. My involvement compresses to reading a finished report — and when I've reviewed it, I'm done. Feedback goes back into the loop, the loop carries it, and it leaves my head entirely.

I call this file and forget, and I've come to believe it's the actual mechanism behind agentic leverage. True parallelism isn't running ten agents at once. It's being able to close a thread the moment you've applied judgment, knowing something with perfect memory is holding it. Continuity lives in the loop, not in your cognitive load. That's what lets three people operate like thirty.

The machine

What actually runs at Stencil today: the agents, the bar their output has to clear, and the loop they run around the clock.

Meet the Rangers

At Stencil we call our discovery agents Rangers — rangers protect the park. Always on guard, gathering intel, proactive. Special forces for your product. (PostHog calls the same pattern scouts, and their write-up is excellent; I run the same architecture in my other product, 1mn.ai, where the name comes from. Credit where due — this pattern is being convergently evolved all over right now.)

A Ranger is a scheduled agent with one signal source and a skill — a markdown file that tells it what matters in that source, what's noise, and how hard to squint. Here's the roster running today, every one of them live:

• Session replay — where users rage-click and stall
• AI chat history — what people ask the agent for, and what frustrates them (this one caught the memory bug)
• Error tracking — exceptions, bursts, regressions
• Support tickets — the highest-value words a user ever writes
• Meeting notes — decisions and complaints that never make it to a tracker
• Feedback widget — the in-app suggestion box
• Product changelog — recent PRs, so Rangers know what just shipped
• Competitor radar — feature parity, docs, positioning
• Dogfooding Rangers — synthetic users that drive fresh features and file what confuses them
• Generated-app signals — errors, logs, and security findings from the apps our users built
• Code review — quality passes over generated apps

Read that last pair again. Stencil's users vibe-code their own products — so we run Rangers over their apps too. When a generated app throws errors or fails a security check, that's not just their bug. It's a signal about what our builder should do better. Our users' products' problems become our roadmap. Discovery all the way down.

A signal is not a finding

Here's what the memory-loss ticket taught me, though. Catching the signal felt like magic — and then the magic ran out, because the ticket was just the signal. Eight users, solid evidence, and no idea why it was happening or what to do about it. The investigation still landed on a human. High-steering, context-heavy human work. We'd automated the noticing and kept the grind.

So the bar moved. A Ranger's job doesn't end at "something's wrong here." The finished output is a report a human can act on in one read: the validated signal, cross-linked against what other Rangers have seen, the root cause, the impact, and a proposed fix.

That changes what the human gate looks like. You open the dashboard in the morning. You read evidence, root cause, proposed solution. You apply judgment for two, maybe three minutes. Then you do one of three things: dismiss it, promote it to a PR, or promote it to an initiative. That's the whole job. There are exactly two human gates in the loop — that ticket decision, and the PR merge. Everything between them is machinery.

Automating the noticing while keeping the grind is not discovery. Signal → root cause → proposed fix, or it doesn't count.

The loop, step by step

Now the scar tissue, because the architecture took a wrong turn first.

V1 was a pipeline: each Ranger read its source and emitted findings, and a central Triage agent cross-linked everything, deduped, prioritized, and decided what became a ticket. Clean on the whiteboard. In practice it was too artificial. Results were mediocre. It missed real tickets. And it had a structural flaw I only saw later: triage was an ending. Signals flowed to a judgment point, got compressed once, and whatever didn't clear the bar that day just died there. A weak signal — one confused user, one odd error — got dropped at the gate. Every time.

But weak signals are where the good stuff hides. One user losing context is an anecdote. Eight is a bug. If your architecture discards anecdotes, it never gets to eight.

So V2 deleted the triage agent and replaced it with a shared scratchpad — one working memory all Rangers read and write. Now a Ranger that spots something first searches: has another Ranger seen this? Is there already a ticket? If yes, it strengthens the existing ticket with new evidence instead of filing a duplicate. If the signal's too weak to act on, it goes on a watchlist in the scratchpad with a note about what would promote it — and it waits there, accumulating.

The pipeline became a loop. Nothing ends at a triage meeting anymore, because there is no meeting; signals keep arriving tomorrow and the memory keeps compounding.

Here is the loop, step by step, as it runs today:

1. Trigger — the Ranger wakes on its own schedule: hourly, daily, weekly. No synchronized "discovery cycle"; nobody waits for anybody.
2. Adapter — a deterministic adapter pulls the source raw: bounded time windows, pagination, counts, stable evidence references. No AI here — just clean, verifiable input.
3. Investigate — the Ranger reads the window through its skill: extract signals, group evidence, weigh the source's credibility.
4. Scratchpad — it checks the shared memory. Has another Ranger seen this? Is it already on a watchlist, accumulating?
5. Search — it searches the existing tickets before authoring anything.
6. Decide — one of three dispositions: remember (park weak evidence with an explicit promotion condition), strengthen (add evidence to a live ticket and update its thesis), or create (author a new evidence-backed ticket).
7. Deepen — on create or strengthen: root cause, impact, proposed fix, priority. Every contribution lands on the ticket's timeline, signed by the Ranger that made it.
8. Human gate — you read the finished report for two or three minutes: dismiss, promote to a PR, or promote to an initiative.
9. Ship — the PR merges (the second and last gate), and tomorrow's signals judge the fix.

Then it runs again. That's the whole anatomy — the diagram below is this list drawn as the circle it actually is.

Weak signals don't die in a loop. They accumulate.

The skill is where the product lives

If you build one of these, here's where your hours actually go. Not the harness, not the scheduler, not the sandbox plumbing — those are a weekend. The work is the skill: each Ranger's steering layer, the instructions that tell it how to read its source. What frustration looks like in a chat transcript. When five session recordings are a pattern and when they're one bored user. Which support phrasing means "annoyed" and which means "about to churn." The instructions you give a Ranger for processing its signal are what make or break the entire layer. Everything else is commodity; the skill is the product.

And an embarrassing share of that skill is writing lessons. We had to teach Rangers exactly how to write a report — structure, length, what leads, what gets cut. The language is critical: a report that's technically correct but takes three reads to parse is a failed report, because the whole system exists to buy back your attention, and an unreadable report spends it. Optimize the prose for readability or you won't understand anything you're reviewing — and the three-minute gate quietly becomes a twenty-minute gate, which is to say, no gate at all.

A Ranger's report is user interface. The user is you, before coffee.

The noise problem, unsolved

Honesty section: the noise problem is real and I'm still in it. A Ranger that files a ticket on every wobble is worse than no Ranger at all — it burns the exact resource this whole system exists to protect, your attention. PostHog says it plainly: a scout that emits on every wobble trains you to ignore them.

Two things are holding the line so far. The scratchpad — Rangers must check memory and existing tickets before authoring, and park weak evidence on the watchlist instead of firing. And per-Ranger skills that encode source credibility: a support ticket is high-signal almost by definition; a single session recording is gossip until corroborated. The skill teaches each Ranger how much to trust its own eyes.

Is that enough? Ask me in three months. But I'd rather tune a noisy discovery layer than operate blind with a quiet one.

"What's next?" is a cron job now

Zoom all the way out. For twenty years, "what should we build next?" was answered by the loudest customer, the most recent anecdote, and the founder's gut. Not because we were lazy — because the signal volume was superhuman and our thread count is six.

It isn't superhuman anymore. The most valuable thing my product does now isn't in the product. It's the layer watching it — a dozen Rangers reading everything, remembering everything, and handing me three-minute decisions with the investigation already done.

Somewhere in your product right now there's a bug eight users have hit and zero have reported.

Nothing in your building knows.