Customer 0 for Sovereign AI: How EDB Runs Mission Control AI on EDB Postgres AI
EDB runs its own revenue reviews, renewals, and executive metrics on the same data and AI platform it sells. This is how that estate is built: the layers we own, the pieces we rent, where the guardrails sit, and what running it on ourselves taught us.
The architecture rests on one decision. Models, chat surfaces, and connectors are rented, because someone else improves them faster than we could. Four layers are owned, because they are the record of how EDB understands itself. The semantic layer defines our metrics. The context layer holds our operating knowledge. The agent stack routes and traces every question. The learning loop turns corrections into tested releases. That piece is about the decision. This one is about the build.
Everything described below runs inside EDB today. Sellers, finance, and executives use it for revenue reviews, renewals, and executive metrics, on the same EDB Postgres AI platform we sell. That is the point of Customer 0. If it does not hold up on our own revenue numbers, it has no business in front of a customer.
Start with the picture
The diagram below is the whole estate on one page. The dashed row at the top is rented. Everything under it is open source or ours.
Rented surfaces (dashed) in front of the orchestration layer, three agent families, and one converged data and AI platform on EDB Postgres AI. The four owned layers are tagged where they live. Guardrails run alongside as a rail: identity-bound access, sensitive content filtering, and trace redaction.
The platform, bottom up
One converged platform. WarehousePG handles analytics, with a medallion architecture that refines raw data into gold tables that are analytics ready and AI ready, built by dbt models running on Airflow. CloudNativePG with pgvector carries operational and embedding workloads. A metadata catalog gives us lineage across all of it, and object storage holds raw and unstructured content. Access is enforced at this level, by role and attribute, before any agent is involved. I will come back to why that ordering matters.
Three agent families, kept in separate lanes
Natural Language Insights is our analytical agent. It reads the Cube semantic layer, where every metric is defined once, and a context platform where our people maintain glossaries, playbooks, metadata, and agent instructions, then writes SQL against the gold tables in WarehousePG. The semantic and context layers both live here. The SQL is generated, but it is generated from governed definitions against curated tables, not inferred from a raw schema. That is the difference between an agent that guesses what revenue means and one that is told.
Knowledge agents are a different lane. They do purpose-built retrieval over unstructured content: tailored LangGraph nodes, hybrid search in pgvector, and source attribution on every answer. They do not compute metrics. Workflows in n8n handle the rule-based and AI steps behind scheduled reports and multi-step tasks.
The separation is deliberate. A retrieval agent that also does arithmetic is how you get a confident number with no definition behind it. Intent classification at the front door decides which lane each part of a question enters, and a single question can carry more than one intent. Ask what a SKU is and how much pipeline sits against it, and the knowledge agent answers the first part, Natural Language Insights answers the second, and the orchestration layer joins them into one response. The lanes stay separate in how they work. The answer does not.
The orchestration layer
In front of the agent families sits one LangGraph graph. It classifies intent, resolves the caller’s identity and policy, and routes the question to the right lane. Every call is traced in Langfuse: the prompt, the route, the tools called, the data touched, and the answer returned. Those traces are more than observability. They feed the evaluation set that every release is scored against before it ships, which is the learning loop running on production traffic.
We chose LangGraph over more autonomous agent frameworks because routing in a governed enterprise should be explicit and auditable. A reviewer should be able to read the graph and know in advance which paths a question can take. Open-ended autonomy is the wrong default when the question is what ARR was last quarter.
Guardrails are a layer, not a prompt
Guardrails do three jobs here, and only one of them happens near the model.
First, identity flows to the data. A person’s single sign-on identity passes through the orchestration layer to the platform, and role and attribute-based access control decides which rows, metrics, and documents come back. The agent does not query on a shared service credential on a user’s behalf. If you cannot see a region’s pipeline in the warehouse, Mission Control AI cannot see it for you either. Data provisioning stays in the data platform, where it is enforced; it is not in a prompt, where it is requested.
Second, sensitive content is filtered before the agent ingests it. We use Amazon Bedrock Guardrails to screen content for personally identifiable and other sensitive information so it does not enter the retrieval corpus or the model context in the first place. Removing something from an index after the fact is cleanup. Never ingesting it is a control.
Third, logs can be opened up without leaking. The same filters redact traces, so a domain owner reviewing how the agent handled a renewals question does not see a colleague’s HR question sitting in the log next to it. That is what lets us give trace access to the people who own the definitions instead of restricting review to a security team. The learning loop depends on many people reading the logs. Redaction is what makes that safe.
Bedrock Guardrails is a rented engine, and that is consistent with the thesis. The policy is ours: what counts as sensitive, what gets masked, and what gets blocked. The ApplyGuardrail API evaluates text independently of which model produced it, so the control survives a model swap. We own the rule. We rent the enforcement.
Customer 0 in practice
The front door is EDB Mission Control AI, the assistant we built for our own company and rolled out to every employee. Ask it a business question in plain language and it answers from governed data, approved content and policy, with the sources behind every answer. The orchestration layer decides whether the question is analytics, a competitive comparison, a pitch draft, a policy lookup, or a scheduled report, and routes it. The person asking never needs to know which room they are in.
Running it on ourselves did something a pilot never could. Sellers, finance, and executives tell us within minutes when an answer is wrong, and they tell us in the thread where the answer appeared. The fix lands in the semantic layer or the context layer, becomes an evaluation case, and ships in the next release as a better answer for everyone. The context compounds inside our four walls instead of inside a vendor’s product. That compounding is the asset.
Adoption is push, not pull
People do not go to a new tool. They go to where their work already is. Mission Control AI was multi-surface from day one: a connector and skill in Claude, an app in Slack, a web interface. Same orchestration, same layers, same answer behind every door. Most of the traffic arrives through MCP into Claude and Slack, and the web interface is the smallest door. Speed is the feature. A correct answer that takes a meeting loses to a correct answer that arrives in the thread.
Owning the layers is what makes this possible without fragmentation. A surface holds no definitions and no context. It authenticates, passes identity through, and renders. Everything else is upstream.
What this asks of a data team
Most data organizations are deep in components: database engineering, warehouse optimization, pipeline tooling. The scarce skill is different. It is deciding where each layer should live and why: why the semantic layer belongs in the data platform and not the prompt, why identity must flow to the database, why evaluation runs at release rather than per answer, why guardrails sit at ingestion and on the trace rather than only at the model, and how open source and commercial pieces become one platform instead of a stack of tools. That skill is rare everywhere, and every out-of-the-box pitch is priced on the assumption that you do not have it. A small team that owns the architecture of meaning and assembles the rest is worth more than any single component you could buy.
The test of whether you built a platform is the second agent. Once the layers were in place, ours was cheap, and so was the tenth. If adding a capability is another six-month integration, you built a function. If it is a week on top of meaning you already trust, you built a platform.
We are early. The agent estate at EDB will look different in a year. But the four layers will be the same layers, still ours, and better because of every question our own people asked. That is what I would want any customer to be able to say about EDB: “They run their own business on it.”