Before an agent can act, the company has to agree what its data means

Ask three teams how many customers a company has and you may get three defensible answers. Sales counts signed accounts. Finance counts paying entities. Product counts active workspaces. An agent connected to all three systems has more information, but still needs a rule for choosing among them.

Google Cloud returned to this problem in a July 23 post on enterprise AI infrastructure, arguing that agents need business context and semantic meaning alongside data access. The commercial interest is obvious: Google sells the infrastructure. The underlying design problem is worth examining on its own terms.

A connector establishes that the software can retrieve a record. It does not establish what that record should mean for the task in front of it.

An ordinary word can hide a policy

Consider a company that wants to contact customers approaching renewal. A request to find “at-risk customers” combines several decisions. Does risk mean declining usage, an unresolved support issue, an overdue invoice or something a salesperson recorded after a call? Is the unit an account, a subsidiary or a parent company? Which evidence is recent enough to use?

These examples show why adding more documents can make the problem harder. The agent may find several internally consistent definitions written for different purposes. Selecting the most recent document will not necessarily select the right policy.

An explicit definition gives the team something to inspect. For a renewal task, it could state which account identifier to use, the relevant contract period, the signals that qualify and the exclusions. The owner of that definition matters too. When finance and customer success disagree, the system needs a decision from someone authorised to make it.

Definitions need versions

Suppose the company changes its definition of an active customer. Last month’s report and this month’s report may now use different denominators. An agent can produce accurate calculations for both periods and still imply a misleading trend if it treats them as directly comparable.

Keeping a version alongside the result makes that change visible. It also makes corrections less expensive. A team can identify which reports used the old definition instead of searching through finished documents and trying to infer what happened.

Each undefined term asks the model to make a business choice. Some choices are harmless. Others change who gets contacted, which customer receives an offer or what management believes about revenue.

Our inference is that a company’s shared definitions deserve to be maintained as carefully as other product inputs. They need ownership, examples and a way to handle exceptions. The first test can be small: give the same ambiguous request to the people responsible for the workflow and compare their answers before asking a model to automate it.

Where the answers differ, the implementation has found work the company still needs to do. A more capable model may explain the disagreement very well. It cannot supply the missing organisational decision.