The opener

Somewhere in most businesses there is a file, an export, or a system that nominally contains the answer to a question someone keeps asking. It is not secret. Nobody is withholding it. It is simply accessed in a way that requires hands-on expertise to extract answers out — engaged via a ticket, an engineer, or a backlog item.

The opener removes the friction that stands between the question and the answer. What changes is not that the data becomes available — its that asking becomes cheap enough to do casually. Insights become democratized and your workforce becomes more empowered.

It takes a question in plain language and works out which tools it has to deterministically answer it. It runs those tools, then it reports what came back.

The important word is deterministic. The agent has no figures of its own and is not permitted to just make things up. Every number it states has to have come from a tool call you can see it make. Tools are discrete steps — small programs — the agent runs to determine its answer. When the data cannot answer your question, it says so and names what is missing, rather than hallucinating something it thinks you want to hear.

In this demonstration only a few tools have been built, but dozens could be supplied to an agent to make it robust and capable of genuinely complex work. If there is something you want this agent to do and it tells you it cannot, that means you are ready for Pando to take you even further in Agent automation.

The data is a slice of a real hospital price file, published by Stanford Health Care . It is not a sample we constructed — it is a file pulled directly from the source.

The agent was built with these tools:

• find_charges

  Search the price file for charge items whose description contains a term. Use this first when the visitor names a procedure, drug, or service, to find out how it is actually described in the data before asking about its price.

• price_spread

  For one charge item, return the cheapest and dearest payer-negotiated rate and which payer is at each end. The description must match an item exactly — use find_charges first to get one. Returns null when the item is not in the slice or carries no negotiated rates.

• list_payers

  List every insurer named anywhere in the slice. Use this when the visitor asks which payers are covered, or before claiming a particular insurer is or is not present.

• render_chart

  Draw a small chart of figures ALREADY RETURNED by another tool in this same turn, when a picture makes the answer clearer than a list — comparing several values, or showing a sequence. Call your data tools first; this tool reads no data of its own. Every value is checked against what those tools returned and the chart is refused if a figure cannot be found among them, so use returned figures exactly and never round, scale or estimate them. Needs at least two points. Use "bar" to compare labelled things and "line" only when the points are in a genuine order, such as time. The chart supplements your written answer; it never replaces it.

Tool are closed-loop and strictly validated, so an agent cannot circumvent them to improvise an answer. Everything you see the agent compute is its own discrete work, performed against real data.

The data and tools change, but the fundementals do not. What made this hard was not healthcare — it was defining the process, organizing Tools, and capturing sets of instructions. Your version might be a warehouse nobody queries directly, an ERP export that takes a day to reconcile, or a decade of contracts in a shared drive.

The work is the same three pieces:

• — a retrieval layer that is correct and cheap to verify
• — an agent constrained to speak only from it
• — auditability, so anyone can check an answer against the source

The honest test of whether this fits you is not technical. It is whether there is a question your team has stopped asking because asking is too expensive. If there is, that is the one to bring us.

• — Which accounts moved on margin last quarter gets asked on the day you wonder it, against the same warehouse the monthly reports are built from, instead of becoming a request someone schedules.
• — Why a particular shipment ran late in March is answerable out of the operational data you already keep, without booking an engineer to go and look.
• — Which of a decade of contracts in a shared drive carry a particular indemnity cap is an afternoon, rather than a week assigned to somebody to read them.
• — Before you renegotiate with a supplier, you can ask what you actually spent with them across every entity and every year — the figure you would otherwise walk in having estimated, because assembling it properly would take longer than the meeting is worth.