How Our Agents Understand Enterprise Data

Financial questions often work across systems. A request for "last quarter's spend" may draw vendor records from an ERP, invoice and credit activity from a warehouse, and a company-specific rule for which dates count.

Concourse agents assemble the answer across those systems. They find the relevant data, apply the company's definitions, and preserve the queries and calculations behind the result.

Our context layer coordinates that work through progressive disclosure. It brings data, definitions, tools, and instructions into the agent's working set as the task unfolds. Permissions shape what can be used, while durable state and versioning preserve the decisions and evidence needed across steps. Reviewed corrections can become versioned company knowledge, improving future work without silently changing company policy.

Finding the right data across systems

Identifying which data sources to use for a specific question requires a bit of exploration, allowing the agent to see available data through the customized context layer we generate and the live data itself.

For example, vendor status and approval history may live in the ERP, while invoices, credits, and payments are modeled in the warehouse. The agent identifies the records relevant to the request and reconciles them across both systems.

Our agent starts with the language the team normally uses: vendor, invoice, payment. The underlying data may be named "fct_txn_v2," so the context layer adds business descriptions and tags that make it discoverable. Those signals are initially generated from the data itself and become more precise as the system is used.

The agent checks the most likely sources directly and writes the query against current data. A renamed table, a new field, or a newly connected source changes the path immediately.

When the records come back, the agent aligns time periods and joins the data needed for the analysis. Vendor dates may come from the ERP; invoices and credits may come from somewhere else. The join is assembled for the question at hand.

Joining records across systems depends on knowing when two records refer to the same vendor. Existing mappings are the strongest signal; names, addresses, and tax identifiers help when IDs differ. If the evidence is inconclusive, the result preserves that uncertainty for review.

From a business question to live, permissioned data.

Permissions travel with the work. The search covers only the connections available to the requesting user, and every query is checked before it runs. Data outside that boundary never enters the analysis.

As teams use Concourse and their context layer grows in complexity, the need for exploration tends to reduce. The types of queries, the aggregations, and the order in which they are run becomes standard and repeatable and can be baked into methodology.

From structure to company methodology

Finding the right data is one part of the job. The agent also has to know how the company wants them interpreted. Revenue might follow service dates or booking dates. A vendor might count as new when it is approved, first invoiced, or first paid. Those choices are company methodology: the rules a team uses to turn data into an analysis.

Pre-existing semantic models can handle the reusable parts of that work: shared metrics, dimensions, and joins. They give the agent a consistent foundation for querying company data. However, methodologies go one step further. Workflow-specific decisions sit alongside the model: source precedence, exceptions, date choices, and the evidence expected in a finished report.

In Concourse, those methodologies and workflow instructions are composed as a versioned and permissioned set of rules for a specific kind of task. It can tell the agent which source to trust, which date to use, and how to validate the result. The agent retrieves the relevant methodology when the task calls for it. Different teams can choose to define semantically similar metrics differently and only share with the relevant people.

This separation lets one semantic model support different workflows. A dashboard can use the company's standard definition of spend, while a procurement review applies a category exclusion or a different recognition date. The semantic model provides the shared foundation. The company knowledge provides the method for the analysis.

From structure to meaning: business context, current data, and company methodology contribute different kinds of context.

Business context helps the agent find the right data. Live data shows what is available now. Company methodology tells it how to interpret the result. Keeping those responsibilities separate means a table can change without changing the definition of revenue, and the definition can change without rebuilding the data connection.

Managing context through a task

An agent's working set changes continuously as it works. A request may begin as a few sentences and accumulate tool results, source choices, calculations, failed approaches, open questions, and draft artifacts. Progressive disclosure keeps that working set focused as the task grows.

Keeping context useful means deciding what the model needs now and what the system must remember later. Connection details can fall away once the right source is found. A fiscal calendar or company definition may continue to govern every calculation. Large query results can live outside the context window as long as their source, parameters, summary, and saved output remain in task state.

The context window is the agent's workspace. Loading every policy, prior analysis, and tool response into it would crowd out the information that matters now. Retrieval brings in relevant material when it is needed, while structured observations let later steps use an earlier result without replaying the entire history that produced it.

Long-running work also needs continuity across turns. The task state records selected sources, applied knowledge versions, assumptions, unresolved ambiguities, and references to generated outputs. A calculation can hand a compact result to report generation, and a paused or retried run can resume from explicit state instead of reconstructing decisions from a chat transcript.

At production scale, context engineering becomes a systems design problem. Tools determine what the agent can observe and change. Permissions constrain those tools. Retrieval and compaction shape the working set. State design determines what survives between steps, and versioning records which definitions and instructions shaped the work. The model reasons over context assembled and governed by the surrounding system.

Making the work inspectable

The output of an agent should be easier to inspect than the process that produced it. For each analysis, we keep structured observations about the sources queried, the SQL that ran, a sample of the returned data, the calculations performed, and the artifacts created.

This is more useful than exposing a long transcript of model reasoning. A reviewer does not need every intermediate thought. They need to know which source was used, what query executed, what values came back, and how those values became the number in the answer.

That evidence also makes errors easier to locate. If a number is wrong, the failure usually belongs to one of a few layers: the wrong source was selected, the query was incorrect, identifiers were reconciled badly, or the wrong definition was applied. Those boundaries turn "the number is wrong" into actionable feedback about the exact part of the process that needs to change.

Traceability from query to report

Traceability continues into the final report. Numbers are not accepted simply because they appear in generated prose or a formatted table. Every number we send out is validated against the query results behind it.

During report generation, the value rendered in the report is reconciled with the structured result returned by the query or with a calculation derived from that result. If the values do not match, the current state of the report is rejected with feedback for the agent. This catches a different class of error from query validation: the query may be correct while the report rounds, copies, or transforms the result incorrectly.

A reported figure therefore has a path back to its source data, query, calculation, and applied methodology. If a report says $2.4 million, a reviewer can inspect the result that supports $2.4 million, see how time periods were handled, and rerun the work when necessary. The report stays readable, but the numbers do not become detached from the computation that produced them.

Each number in the report is checked against the query result or calculation that produced it. Prose, tables, and formatting can change while the evidence behind the number remains intact.

Turning corrections into company knowledge

Corrections are valuable context, but they are not automatically company policy. A user may explain that "new vendor" means first payment rather than first approved invoice. That correction should improve the work without silently changing the behavior of every future analysis.

We treat the correction as a proposed knowledge change. An authorized user can review it, revise it, reject it, or incorporate it into the existing company knowledge. Accepted changes are versioned and retain ownership and history. That makes them reusable, but also reversible.

The separation is important. Session memory can help with the current interaction. Durable company knowledge should pass through an explicit review boundary. The agent can learn from usage without turning a single conversation into an ungoverned configuration system.

A governed learning loop: corrections become reusable context through review, authorization, and versioned controls.

The loop is simple: produce an answer with evidence, receive a correction, propose a change, review it, publish a version, and use it in later work. Nothing becomes a shared rule silently. Improvement remains scoped, inspectable, and reversible.

What this changes

Agents work best when they receive the right context at the moment of work.

Each source of context has a specific job. Names, descriptions, and tags help the agent find likely data. A live check tells it what data is available now. Connection permissions define what it may read. Semantic models provide reusable metrics and joins. Company knowledge provides long-term processes and methodologies. Query results and structured observations make the final output checkable.

Together, these components let an agent work across an ERP and a warehouse while respecting each system's boundaries. Shared definitions can be applied across queries. Reports stay concise, with every number connected to its computation. Reviewed corrections improve future work while company policy remains controlled.

The system earns trust through what each session leaves behind: a report that can be checked, a query that can be rerun, a definition that can be reviewed, and knowledge that can be safely reused.

That is the standard we care about: a result that can survive review by the people responsible for the systems and the people responsible for the number.