Hi, I'm Ryan, CTO at airCloset.
Over my last few posts, I've introduced internal MCP servers we've been building: DB Graph MCP, the full picture o...
For further actions, you may consider blocking this person and/or reporting abuse
17 internal MCPs - what does routing look like when multiple graphs have overlapping context?
All 18 aren't loaded together (was 17 at the time of the post, grew by one since). Each MCP is scoped to a role or workflow. The CS-facing or operational ones are only active during specific scenarios like bug investigation, not in engineering review. Which subset activates is decided upfront by scenario / persona, not at query time.
This pushes the "overlapping context" problem upstream: in any given scenario you've narrowed down to a few MCPs that don't conceptually overlap by construction. The dedupe question only shows up if you fan everything out at once, which the architecture avoids.
When overlap does happen within a scenario, it's intentional lens difference. For code review you'd have Code Graph + Service Product Graph + DB Graph in play: the same "users" table shows up as schema in DB Graph, as call paths touching it in Code Graph, as service ownership in Service Product Graph. Same entity, three layers. The agent treats them as complementary.
For cross-scenario pivots (jumping from a stacktrace mid-investigation to operational context for the affected user_id), canonical IDs flow across graphs (user_id, sku_id, initiative_id). No central registry or dedupe layer; the agent picks via tool descriptions.
persona/scenario gate as the routing mechanism is cleaner than I'd expect - deterministic beats query-time disambiguation every time. the edge I'd watch: when a bug investigation IS the engineering review. does your incident workflow stay single-persona, or have you needed an explicit rule for threads that span both?
Two entry points, persona set by where the thread starts.
CS entry: investigation runs inside a CS-facing MCP. When something looks technical (real bug vs user error), an engineer makes the verdict. The persona bridge is a human handoff, not a routing rule.
Engineer entry: Cortex Product Graph + observability MCPs (NewRelic, Grafana) for the joint structural + telemetry view. CS context comes in via canonical user_id when needed, not as a parallel persona.
So the answer: single-persona by default, no explicit cross-persona routing rule. The bridge is human at the boundary.
One thing worth adding: some MCPs take a usecase argument and reshape their tool responses based on it. Same tool, different output depending on whether you're in incident investigation vs feature planning vs review. This works as a runbook for the agent: the response itself tells it what to call next given the usecase. It's persona-scoping pushed inside the MCP rather than between MCPs.
the human handoff framing is clean — but worth naming what happens when that handoff fails silently. CS-facing MCP confident, engineer not looped in, nobody holds the full context. the Cortex graph angle is interesting — does that carry state across the entry point, or does each session start cold?
Honestly hasn't surfaced yet. Two things keeping it down so far: the setup is far from complete and bug volume hasn't stressed it, and team culture leans on direct communication. CS and engineering all sit in the office, day-to-day relationships are strong, no hesitation to ping someone when CS is uncertain. The "human bridge" relies on that culture more than on any technical guardrail. If we lose that, the silent-failure mode you describe is exactly what surfaces first. Thanks for naming it.
On state across entry points: no agent-side write-back today, sessions start cold. Each one re-queries the graph and re-discovers. The graph is persistent but the session's findings don't flow back into it.
Pulling past issues into the graph would close part of this. Issue history, resolution path, code change, and review verdict are all captured in GitHub PRs. That's an underused source of structured incident knowledge. To be exact, that's PR ingestion rather than session write-back since the records come from humans not the agent. But the practical effect overlaps: durable post-incident state the agent can pick up next time. Good direction to chase. Thanks for the angle.