A half-million-dollar customer who was never that rich
Carolyn Inworth of Wisconsin is a name in a customer 360 demo, not someone a sales team should call. Ask an AI agent who spends the most, and the walkthrough has her coming back at $502, 529. Attach one sentence of business meaning to a column and ask again: $27, 991.66. Same question. Same model. Same agent code.
The agent treated purchases.price as a unit price and multiplied it by quantity. The column was the amount paid for the whole order. Multiply an order total by quantity, and a forecast invents a customer who was never that rich.
That is the practical risk of AI agents on live operational data. Whether the model can write SQL barely matters. The query runs. The number is wrong. The prose around it can still sound like a briefing, so a meeting might not catch it. This demo shows the misread. It does not show how often a room would miss it.
What the comment and the view changed
The demo loads a customer 360 dataset, drawn from the Stardog kit, into one EDB Postgres AI instance and a schema named c360. Four tables: customers, locations, products, purchases. One derived view, big_spender. Foreign keys already say a purchase belongs to a customer, and that a customer’s location points at a city, state, and zip.
Business language sits in ordinary Postgres comments. The comment on purchases.price is blunt: “Total amount the customer paid for the entire order, in US dollars. Not the unit price.” The location comment says the column joins to locations.id and that state lives in locations.state. The Social Security number comment marks the column sensitive and says a column-level grant is required.
AIDB, the Postgres extension used here, builds a semantic knowledge base over that schema. It embeds definitions of tables, views, and columns, including the comment text. It does not embed the rows. Picture a card catalog for the database. The books stay on the shelf. A named, read-only query can sit beside that metadata, described in plain language, so the agent can call it instead of inventing the SQL.
With the price comment in place, the authors report Carolyn Inworth of Wisconsin at $27, 991.66. Without it, her row is the $502, 529 figure. Their line after the corrected query is the argument:
Same model, same prompt, same tool catalog. The semantic knowledge base changes the answer.
The model is Anthropic Claude on Amazon Bedrock, described as the latest Claude Sonnet. No model ID is pinned, and availability varies by Region. Treat the spend correction as one worked example. It is not a benchmark. The walkthrough reports no test-set accuracy score, latency, cost, or data volume.
A view does the same job for a contested term. Here, a big spender is a customer with at least one order over $250, and the view comment tells the agent to use that view for the question. A plain “which state do they live in” question resolves through the foreign key, rather than by guessing that state might sit on the customer row.
If the business later decides a big spender means cumulative spend over $5, 000, the authors’ point is that the change is one view replacement. Agents see the new definition the next time the semantic knowledge base refreshes. That redefinition was not run. The $250 cutoff belongs to this demo, not to every design that reuses the customer 360 questions. Own the rule in this database.
Related designs put those definitions in a knowledge graph, a data-virtualization layer, or a dimensional metrics product. This one keeps them in the operational database. Sharing the customer 360 pattern does not mean the physical schema matches.
The lock is the grant, not the prompt
The governance rerun is the result worth taking to a risk committee. Same prompt, same tools, same knowledge base, same agent code. Two Postgres roles. One can read every column. The other can read customers except Social Security number.
Under the fuller role, five customer rows come back with Social Security numbers populated. Those values are not printed. Under the restricted role, the tool call fails with permission denied for column ssn, and the agent says the numbers are not accessible.
The failure is enforced by the column-level GRANT, not by the prompt or the model.
The authors quote the AIDB endpoint reference for the policy in one sentence: “Postgres grants decide what each agent can run.”
The wiring, briefly: an analyst authenticates and calls Amazon Bedrock AgentCore Gateway with a JWT. Gateway can evaluate a Cedar policy against the token claims to decide which tools that caller may invoke. AgentCore Identity injects the Postgres username and password. The agent code never sees the database credential. Tool calls reach an MCP endpoint that AIDB exposes from Postgres, with no Lambda translating protocols in the middle. The walkthrough describes that path. It does not print the Cedar policy, the Cognito setup, or the credential-provider configuration.
A few limits belong in the same breath. The demo uses two stored credentials. It does not map each person’s token to a personal database role. Row-level security is part of the design story. The worked denial is column-level. AIDB’s “purpose” control applies to agents that run inside the database. It does not cover this external path. A column grant also does not stop a model from echoing sensitive text it saw somewhere else. The authors treat Amazon Bedrock Guardrails as the complementary control: content filters, denied topics, and PII redaction on the reply. Postgres stops the read. Guardrails watch what gets said.
Audit splits the same way. AgentCore traces go to CloudWatch. AIDB stores OpenTelemetry spans for SQL execution as ordinary rows, so a reviewer can query what the agent ran. EDB Agent Governance reads those spans.
A dictionary, and a cache that can lag
For AI automation aimed at live operational questions, the attractive part is ownership. Finance, sales ops, or the data owner changes a comment or a view in the system that already holds the transactions. They are not filing a ticket against a side catalog and hoping a copy catches up.
That pitch needs one distinction, or a finance lead will find the gap. Comments, views, foreign keys, and grants are the source of truth. The semantic knowledge base is an embedding index of that metadata, so an agent can search definitions in natural language. It is a cache. It can lag.
Schema changes can refresh the index live, through Postgres event triggers, in the background from a worker, or only when someone asks. The authors say agents see a redefined view the next time the index refreshes. They do not say how long that takes, including in live mode. In the gap, the database can already hold the right view while the agent is still searching yesterday’s card.
You do not deploy a second product to hold the definitions. You still have a lag to operate. Who may change a comment or replace a view, and who notices an answer that landed before the index caught up, is the decision this design actually forces.
Leave “price, ” “top customer, ” and “big spender” as tribal knowledge, and an agent will freeze a bad guess into a number that sounds finished. Put the definition where the grant already lives, and the same stack can answer one caller and refuse another without a second prompt. Leave the definition only in a system prompt, and a later model change could give you a new reading of last quarter. That last risk is plausible. This demo did not measure it.
Questions worth asking before you wire this up
Why did one prompt invent a $502, 529 customer?
Because the agent read an order total as a unit price and multiplied by quantity. A column comment stating that purchases.price is the full order amount, in US dollars, produced the corrected figure of $27, 991.66 for Carolyn Inworth. That is one demonstration, not a scored accuracy study.
Does this replace a separate semantic catalog?
It can, if you accept that comments, views, and grants are the source of truth and the embedding index is a cache that must be refreshed. It does not, if you also need those definitions published to BI tools. Other designs keep meaning in a graph, a virtualization layer, or a metrics product. Those are competing choices. They are not stages of one stack.
Can the same agent see Social Security numbers for one caller and be blocked for another?
Yes, in the demo, and only because a different Postgres role was injected. The restricted role lacks a column grant, and the database returns permission denied. The walkthrough does not show per-user role mapping, a printed Cedar policy, or a worked row-level security example. A grant also does not police every way a model might repeat sensitive text it saw elsewhere.
If we change what “big spender” means, do we retrain the agent?
Not in this pattern. The definition is a view: at least one order over $250. A later redefinition, such as cumulative spend over $5, 000, would be a view change that agents see after the semantic knowledge base refreshes. That later change was not executed. Agree the rule, and the refresh path, before you automate the question.
Who may change a comment or a view, and how do we notice a stale answer?
The demo does not name an owner or a monitor for the gap. You have to assign both. Even live refresh is still a refresh, and the post does not quantify the lag. If nobody owns the dictionary, the index will faithfully search whatever guess was written down last.
What is still unproven?
Cost, latency, data volume, a production customer, a pinned model ID, and any accuracy number beyond this single misread. Lakehouse tables and foreign data sources are described as compatible with the same labels, through EDB’s analytics accelerator and foreign data wrappers. No cross-source query is run. Production guidance points to a private load balancer and VPC egress. A public listener with a self-signed certificate is described as enough for development and testing. It is not offered as a hardening checklist.
Put the dictionary where the lock already is
Agentic AI will keep getting better at planning a query. That does not make it better at knowing that price means amount paid, that state lives on another table, or that a Social Security number is not a column every caller may project. Those are business decisions. Postgres already had a place to write them down and a place to enforce them.
Indexing those definitions for an agent, and letting the database credential decide what the tool may return, is a narrower promise than “the model understands the company.” It is also a promise a finance lead can audit, if someone owns the refresh lag and does not confuse the index with the lock.
Start with the questions sales and customer teams already argue about. Write the definition next to the column. Grant the column to the role that should see it. Decide who may change either one, and how you will know the agent searched the new text. Then let the agent talk. When a comment change moves the number, you have a meaning layer. When only a prompt edit moves it, you still have a prompt.