Context layer for Product teams.

Engineers on my team started shipping 40x faster once they picked up AI coding agents. I'm the PM — I already didn't have enough hours in the day, and once that happened the bottleneck flipped onto me: my job was never writing code, it's making sure they build the right thing, and there was no way I could keep up with that pace by hand. There's a ton of tooling thought through for the engineer side of this shift. Almost nothing built for the PM side — the surface to actually feed an agent what matters just didn't exist.

So I built Atisbo to solve that for myself. I'm a PM and I was tired of the operational work of maintaining a backlog by hand — I built something to do it for me, so my agent could work alongside me instead of me being the thing slowing it down. It turned into a context layer: user feedback, sales calls, support tickets all get synthesized and grouped by actual root problem, not by whoever filed the ticket first. Instead of a doc I have to keep rewriting, it's built to be read directly by coding agents over MCP.

Who it's for: PMs already shipping with AI coding agents (Claude Code, Cursor) who are still doing Product Ops by hand — rebuilding "what's actually going on" from scratch before every decision.

The number that convinced me to keep building it: it cut about 18 hours a week of that reconstruction work off my own plate. And watching teams that pair a PM with a strong product culture, decisions and shipped fixes moved roughly 7x faster than the same PM working alone with Claude Code and no context layer feeding it — same agent, same PM skill, just missing the "why" behind what to build.

Hardest part right now: two things, actually. First, getting the grouping right without a human babysitting it. Clustering similar complaints is easy — not merging two different root causes into one bucket, or splitting one real problem into five duplicates, isn't. Similarity search alone kept silently corrupting the ranking, so we added an LLM-judge pass that has to confirm "same root cause" before any merge is allowed.

Second, making it technically viable, cost-wise. Any expensive model can do this job today — throw a big API call and a good prompt at it and it works. What it won't do is stay sustainable or operable once you're running it against a real customer's volume of evidence, every day, at a price that isn't insane. Finding the actual point where this could run at scale took a while — funny enough, right around the week I landed on it, Fable 5 came out.

Curious if anyone else here has hit that same wall feeding evidence into an agent's context — did embeddings alone hold up for you, or did you also end up needing a judge step?