Your agent reads the diagram, answers questions, and proposes changes you approve.
The diagram answers back
you › what breaks if Stripe goes down? agent › Only checkout. Orders Service is Stripe's single consumer (depends_on · charges) — new orders can't take payment. ✓ unaffected: browsing, sessions, reads from the orders DB. Nothing else touches Stripe. you › ▋
The answer isn't a guess — it's read off the edges you drew. A diagram in a wiki is a screenshot; this one is a live graph, so "what breaks", "who calls this", and "where do we touch PII" are queries, not archaeology.
MCP · one connection, the whole system
An agent in your repo sees one repo. Connected to Merid, it reads the system you actually run — every service, table, and relationship — before it writes a line. That's context no codebase can give it.
Why Merid
“What talks to the orders DB?” Ask in plain language and get answers grounded in the diagram — onboarding and incident triage stop depending on whoever drew it.
Reviewers comment on shapes. Your AI replies with context, attaches a fix proposal to the thread, and flags you only when a question needs the author.
Your agent proposes the diagram update — you apply or reject in one click. Nothing lands without you; everything can be reverted.
Services on one sheet; tables, foreign keys, and enums on another — linked into the same diagram, reviewed in the same loop.
Claude Code, Claude Desktop, or any MCP-compatible agent connects with one config entry. No export step, no lock-in.
Pricing
We charge the people who build diagrams, never the people who review them — share with your whole team without counting seats.
Your architecture changes every sprint. Now the diagram keeps up.
Open Merid