i build the whole thing.
pipeline, model, agent, ui.

the interesting problem wasn't retrieval. it was staying the same thing on four surfaces. people ask it from slack, from linear, from an mcp client, and from the docs site. each one has different affordances — threading, mentions, streaming, message length, auth, who's allowed to see what. the easy version is four bots that drift apart in a month.

so the agent is one core with surface adapters, and the hard questions live in the core. two mcp endpoints — one that walks a structured detective workflow, one that exposes raw tools — behind plex.tv token auth with role gating, so the same question from slack and from an ide gets the same answer and the same permissions. the piece i'm proudest of is the extension contract: a CONTRIBUTING.md plus a claude code skill that walks another engineer through adding a capability, so it grows without me.

same problem as bott weston, one surface further. a coding agent has to be a first-class citizen of github — not a bot that comments, but an identity you can request review from, that shows up in the reviewers list, that linear can track as an assignee. keeping one agent coherent across "a linear issue", "a github pr" and "an mcp call" is most of the work.

and it has a write token, so the threat model is the design. it drops webhook events it authored itself — otherwise it reviews its own review and never stops. it only acts on same-repo prs from org members, never forks, because the reviewer runs with elevated permissions. webhooks are hmac-sha256 verified. the loop is plan → approve → implement → pr, with the human at the one step where being wrong is expensive.