Imagine that someone on the health system's finance team asks a question that takes four seconds to type.

What’s the overall financial performance for colonoscopy procedures this year compared to last?

It's an ordinary question. A service line director asks a financial or data analyst some version of it every week, and in most organizations the analyst disappears for two days and comes back with a spreadsheet. I want to walk through what happens between that question and the answer in Translucent’s system, because the interesting part isn't the data model or schema. The model is the part I think about least.

If you haven't read the previous post, the short version of the premise is there: we ingest a customer's data onto our infrastructure and the application runs there, because the data layer services and the agents were designed to work together. This post is the same architecture at much higher resolution, traced through one question.

If you’re coming to this from the finance side rather than the engineering side, the takeaway is this: the agent never writes the query. It names what it wants, and then the server builds, validates, and runs the actual query against a contract it can’t deviate from. That’s the difference between an agent that returns plausible-sounding numbers and one that returns checkable ones. The rest of this post explains how.

Nothing in the data schema is called "colonoscopy yield"

Let’s start with the part that makes this hard, which has nothing to do with AI.

For most customers, procedural volume data is readily available. Tying that volume to financial impact is much more difficult. Typically, there is no colonoscopy table or column linking volume data to financials.

Depending on the customer, moving from a procedure name to a total contribution margin across claim lines can take multiple data transformations. Each gets you one step closer to the bigger picture, but the process is extraordinarily time-consuming.

Almost everything a CFO actually asks about requires this type of work, since the direct data connection between clinical operations and financial value does not exist.

That gap between the question and the structure of the data is the problem we need to solve. Everything below is about crossing it.

Where do you even start

Hand an experienced data person an entity relationship diagram of four hundred tables and a question, and watch what they do. They don't read it. They find whatever entity has the most edges coming off it, start there, and walk outward until the shape looks like the question.

That instinct is roughly right, and it's the one we built.

The system searches the shape of the graph. Entity names, column names, roles, descriptions, and the edges between them are where we start, rather than searching the rows. When the question arrives, the search runs in tiers. Exact name match first, then partial and fuzzy, both computed in-process against the compiled schema for that customer. Only if those don't produce good candidates does it fall through to semantic tiers: a vector search over entity names, then over entity descriptors. Every result carries the tier it matched at and which columns matched, so when the ranking is wrong we can see why it was wrong instead of guessing.

Two things about that are worth saying plainly, because people assume the opposite.

We never embed row values. Not the claim lines, not the patient data, not the dimension values. The only thing that gets embedded is schema metadata — names, roles, descriptions. The thing you're searching for is structure, and structure is what's in the index. The data rows themselves are not the structure.

It isn't a knowledge graph, and the descriptions aren't hand-written per customer. The structure is derived as data lands. The descriptions come from a healthcare finance ontology we maintain centrally and map onto each customer's columns, so a column means something in the index without anyone authoring a sentence about it for that customer. A customer's own definitions, where they have them, can win over ours.

A search hit comes back with any matches, plus their “neighborhood”. That neighborhood (entities that are one or two hops away in the graph) and their edges are labeled and include cardinality details. This ends up being one of the highest leverage things in the whole query discovery path; it says “here’s your entry point, and here’s where to go next”, rather than “here’s your entry point”, leaving the agent to figure out where to go next. 

What the agent emits, and what we stopped letting it emit

Here's where I'd expect most readers to have an opinion already, so let me start with the part that's the least conventional and work backward.

Every customer gets the same GraphQL API, compiled to the shape of their data. That schema is compiled automatically from a contract the data pipeline publishes, and recompiled whenever their data changes shape. The agent reaches it through MCP.

The obvious question is why not just build tools. Give the agent get_procedure_volume and get_contract_rate and a dozen siblings, write good descriptions, done.

We can't, and the reason is that the graph has a slightly different shape for each customer. Different EHR, different billing system, different modules enabled, different definitions of the same word. There is no set of tools I could enumerate ahead of time that would be correct for the next customer, because I don't know what's in their data until it lands. A generated schema is the only surface that can be per-customer and still be typed.

The second reason is context management. Every tool requires a descriptor loaded into agent context to decide which to pick. Most tools need skills to work effectively in unison with other tools to complete a goal. All of those cost context.

Now for the more controversial part.

For a while we let the agent write GraphQL documents. It went badly. On the predecessor system, we measured the agent's hand-authored queries erroring on 61% of calls...against a schema the agent had just been shown. One question in the sample burned 17 LLM call iterations and 57 seconds before producing anything. 

The fix wasn't a better prompt. The fix was taking the pen away.

The agent doesn't author documents anymore. It names an entity, names filters as structured arguments, and names a relationship path it wants included — the same path string the search hit handed it. The server renders the document, validates it against the live contract, prices it, and runs it. The agent never has to see GraphQL text and never edits it. GraphQL stayed; the authorship moved.

I think this is the actual lesson, and it generalizes past us: giving a model an expressive language is not the same as giving it an interface. The expressiveness that makes GraphQL a good substrate for us humans is exactly the expressiveness that makes it a bad thing to hand a model a pen and a blank one.

What comes back

The rendered document goes out as a single call. Both date ranges are in it (“this year and last”), so there’s no second round trip and nothing left to reconcile. The query walks from claim lines to procedure codes to the rate table, sums there, and returns only the fields the answer needs. The CPT descriptions are long and nobody asked for them, so they don’t need to come with. The user already knows what they’re asking about, so the agent’s job isn’t to explain concepts (like what the CPT code means), but instead to give back financial analysis: tables, charts, and prose that tell the story the user is searching for.

Because the query was validated against the contract rather than written freehand by the agent, we know exactly how it was produced. The path runs from the result back through the subquery, the tables it touched, the source systems those came from, and the business rules applied along the way.

Four seconds, not two days

The original question took four seconds to type.

Our system takes about a minute to produce the answer, along with an explanation of how it got there, and where the data comes from.

I want to be careful about what that does and doesn’t mean. Human analysts don’t take two days to answer because they are bad at the job, but because the question didn’t match the data. Crossing that gap is manual work every time: find where the concept lives, work out the joins, pull it, pull last year’s version, check that the service line definition matches what finance meant by it. Then, the next inevitable question is “how did you calculate that?” and the analyst has to walk back and explain all their steps. 

None of that work disappeared. It moved to where it only has to be done once: into the shape of the graph, into the ontology mapped onto it, and into a query path an agent can traverse but can’t improvise against.

‍