Tool access without business context creates confident action against the wrong object, customer, metric, or state.
A tool permission says the agent can do something. It does not prove the agent knows what should be done. Giving an agent CRM access, email access, ticket access, or billing access is not enough if it cannot identify the authoritative record, current state, owner, and safe next step.
The dangerous cases are ordinary. The agent updates the duplicate account because the name matches. It emails the technical contact instead of the commercial owner. It closes a support ticket that is still part of an escalation. It changes a renewal task without knowing finance is waiting on a billing exception.
The context layer should sit between tool ability and tool use. Before action, the agent should receive the business object, source priority, state, permissions, owner, open dependencies, and escalation rules. For higher-risk actions, it should also receive a reason to stop if required context is missing.
This complements the AI control plane. The control plane can decide whether a tool call is allowed, logged, rate-limited, or escalated. The context layer helps decide whether the tool call makes business sense.
Operators should map tool actions to required context. Sending a customer email requires audience and permission context. Updating CRM requires object authority and state context. Refunding an invoice requires billing source, approval state, and policy context.
A tool is a hand. Context is the operating picture. Agents need both, and the hand should not move when the picture is missing.
This is part 7 of 10 in The AI Context Layer.
