Agents Shouldn't Guess at the Data Lake

Give an AI agent access to Athena and ask it a business question — "how many participants enrolled last quarter" — and you can watch it improvise. It lists tables and picks the one whose name sounds right. It infers that status = 'active' probably means enrolled, because what else would it mean? It writes a query that scans every partition because nothing told it the table was partitioned by month. The SQL is fluent, the answer arrives with confidence, and every load-bearing assumption in it was a guess.

This is not a model-quality problem, and better prompting will not fix it. The agent guessed because the environment gave it nothing better than names to reason from. The Glue Data Catalog — the one machine-readable description of the lake an agent can reach — records structure, not meaning: no keys, no nullability, no allowed values, and, in most real estates, precious few descriptions. An agent grounded only in the catalog is grounded in a phone book.

What grounding actually requires

The CoreModels Glue integration exists to give agents the thing the catalog cannot: a governed model of the lake, exposed over the Model Context Protocol. A CoreModels server speaks MCP at https://coremodels.example.com/mcp, secured with OAuth, and any MCP-capable agent — Claude among them — can connect and consult it as naturally as it would call any other tool.

What the agent finds there changes the enrollment question entirely. Every imported Glue table is a governed type identified as database.table, carrying its S3 location and its Hive types verbatim. Columns carry the descriptions and allowed-value lists your stewards attached — so "does status mean enrolled?" becomes a lookup, not an inference. Partition keys are explicitly flagged in the governed metadata, which means an agent can write the partition-pruned Athena query instead of the full-table scan. The agent starts with get_vendor_integration_status to see what estate is governed and when it was last imported, get_project_summary for the shape of the model, and search_nodes to find the specific types and elements a question touches. Structure that was guessed becomes semantics that are stated.

Honest ignorance beats confident fabrication

The subtler half of grounding is telling agents what is not known — language models fill silence with plausibility, so silence is dangerous. The governed model is deliberately explicit about its own boundaries. Glue declares no primary keys and no nullability, and CoreModels invents neither, so an agent never sees a fabricated constraint it might build a join on. Hive struct<>, map<>, and array<> columns are honestly approximated rather than silently flattened, and the audit keeps flagging them as carrying ungoverned inner schemas — a standing signal to any agent that this column's interior is terra incognita; do not speculate about it. Even undocumented tables surface as named audit findings, which is precisely the message an agent needs to lower its confidence instead of raising its creativity.

We would rather an agent say "the governed model doesn't specify this" than produce a beautiful answer built on an invented key. Grounding is as much about transmitting uncertainty as transmitting facts.

Agents in the governance loop itself

Consultation is the passive half. The same MCP surface lets an agent participate in governance. With audit_vendor_project, an agent can take a fresh catalog export and run the full drift check — coverage, drift, conformance — getting back machine-readable findings and a human-readable report; for catalogs too large to inline, artifacts can be passed by URL instead. An agent triaging a data incident can therefore answer "did the schema drift?" with evidence rather than vibes, and the same nonzero error count that fails a CI build gives the agent an unambiguous signal. With generate_vendor_artifacts, it can draft the governed Athena DDL for a new table — output that goes to a human for review, never to AWS directly.

Just as important is what an agent on the public endpoint cannot do. The read/write split is enforced server-side: the standard MCP endpoint serves read-only tools, and importing an estate is an admin-endpoint, admin-role operation. An agent can consult meaning all day and cannot alter it. The human gate that governs your stewards governs your agents identically — which is exactly the property that makes it safe to hand agents a seat at the table.

The quiet prerequisite for agentic data work

There is a pattern here worth naming. Most of the effort in "AI for data" goes into making agents cleverer at inference — better at guessing schemas, better at recovering from wrong joins. The leverage is on the other side: make the environment legible enough that inference is unnecessary. A governed model with stated semantics, declared approximations, flagged unknowns, and a queryable drift trail turns the hardest part of an agent's job — figuring out what the data means — into a tool call.

The lake does not get less complicated. But complicated-and-described is a problem agents handle well; complicated-and-mute is the one they handle by hallucinating. Between those two futures sits nothing more exotic than an export of your Glue catalog and an import into a governed project.

The AWS Glue quickstart in the CoreModels docs covers the MCP tools alongside the HTTP surfaces, including the exact arguments agents use.