In a company, a great part of the judgment lives scattered: in formal policies, SOPs, client histories, conversations, known exceptions, and decisions that someone remembers because they were present. When a new employee learns, he does not receive only information: he absorbs patterns about what the organization values and how it acts when the general rules are not enough.
A person with experience fills the gaps with intuition. An AI Employee does not: it can only work with the available context, the authorized tools, and the rules the organization managed to make explicit. Before evaluating whether it possesses judgment, one has to ask whether the company turned its judgment into something that can be taught, consulted, and governed. Sometimes the model fails. Other times the failure reveals something more uncomfortable: not even the humans could explain how the correct decision was made.
The book AI Employee calls that discipline Context Provisioning: the provisioning of the context that produces judgment. The role contract defines the responsibility; context makes it executable with judgment.
Must know, may consult, must not access
The book divides context into three groups. Must know: that without which the role cannot be executed (mission, relevant products, policies, KPIs, limits, escalation routes). May consult: information that is necessary only in certain cases (extended documentation, background, historical cases, catalogs). Must not access: the data, systems, and decisions that fall outside its operational need.
The division seems obvious until you try to write it for a concrete role. Does the collections role need the complete history of disputes, or only the flag that the account is in dispute? Does it need the product margins to draft a payment reminder? Every answer is a design decision. And design decisions get recorded.
Withholding context is also designing
The third category has two foundations, and almost everybody only sees the first one: protecting the information from the resource. It is the least privilege principle of all time, because context is capability but also risk surface.
The second one is less intuitive and equally important: protecting the decision from the information. A resource that sees all of a client's previous disputes anchors itself in them and treats today's client as yesterday's file. One that receives everything "relevant" drowns the signal in what is merely related. More context does not always produce better judgment; sometimes it produces judgment contaminated with more elegance.
Withholding context can be legitimate in both directions, but recorded: what is withheld, on which foundation, decided by whom. Clause HWF-35 requires that every restriction remain in the contract as a record of a context boundary, versioned and auditable. Withholding without a record is something else: the excuse "the system did not have that context" waiting for its turn.
The responsibility for a decision degraded by withheld context falls on whoever withheld it.
Context has an owner and a date
Context needs an owner, a date, and an update mechanism. An obsolete policy can produce consistent and wrong answers: the worst kind of error, because the consistency disguises the wrongness as reliability. A historical case can help interpret an exception, but it should not automatically turn into a rule. That is why it is useful to distinguish facts, criteria, and examples, so that the resource does not treat an anecdote as a mandate.
The discipline has a hidden dividend: it documents the tacit knowledge that depended on one person. The humans onboarded afterward learn better, the managers discover contradictions between policies that coexisted without knowing each other, decisions become auditable. Context is capability: a role cannot decide in accordance with an organization that never managed to explain itself.
Memory is also a data system
The designed role accumulates something from its first day of operation: memory. Recorded payment promises, response patterns, resolved exceptions, corrections received. Memory turns a hundred executions into experience. And it is the most underestimated data surface of the implementation: remembering improves performance and creates exposure in the same movement.
And it is not even the complete surface: the standard forces you to look at five data systems, not one. The inputs: prompts carry confessions, like the client who explains that he has not paid because he is sick, or getting divorced, or being sued. The outputs: every message sent is a recorded decision. The tool results: every query to the accounting system brings back account data. Memory properly speaking. And the category almost nobody sees coming: derived inferences.
When the collections role concludes that "this client is probably in financial trouble", it has just manufactured a piece of data about a person who never handed it over. That data is governed as if it had been collected, and frequently it is more sensitive than everything that actually was collected.
The five need the same thing: a declared purpose and legal basis, minimization (collect what the role needs, not what the integration allows), quality and currency controls, special handling of sensitive data, rules for transfers and for any use by the vendor, isolation by company, and verifiable deletion.
Vendor, deletion, and surveillance
Two requirements deserve development because real implementations omit them. The first one is the vendor rule. Data can leave your organization through the quietest channel that exists: the training pipeline of the model vendor, without leaving a trace in your systems. The rule has to be contractual, not assumed. Ask your vendor in writing whether your data trains their models; if the answer is a link to terms that can change without notifying you, you already have your answer.
The second one is verifiable deletion: deleting and being able to demonstrate that it was deleted are different capabilities, and only the second one counts. If a client asked you tomorrow to delete everything of his, could you do it, and could you demonstrate it? A deletion that cannot be demonstrated is retention with extra steps.
There is one more turn of the screw that the standard applied to itself. Everything hybrid governance requires fattens a file where people appear: what the client said, what the analyst approved, who was slow to intervene. Its purpose is reconstruction and accountability; using it to score employees or profile clients is a new purpose that requires its own justification. An organization that turns its safety apparatus into a surveillance apparatus poisons the incentive to record honestly, and will discover that people learn to operate outside the record. That is why auditing is not the same as logging, and logs are governed with the same severity as the operation they audit.
From the designed role to the operating role
A contract with context still does not work. Turning it into an operation requires joining context, tools, credentials, channels, and relationships, and answering concrete questions. Can it send a communication directly, or only prepare a draft? Can it change a financial status, or only recommend it? What happens if the source system is not available? Who receives an alert, and through which channel? How do we prevent a routine from executing twice? Which channel represents the official version of a decision?
Every answer reduces ambiguity and turns a technical integration into a manageable relationship. What remains is the verification that separates serious design from optimistic design: proving that the authority defined on paper matches the real permissions. A resource can be forbidden from approving discounts and still keep, by mistake, a credential that allows it to. The distance between the contract and the configuration is exactly the space where incidents live.
In the end what remains is a role that is designed and enabled, but still not a trustworthy occupant. Granting it full authority on day one would be as irresponsible as giving total control to a person before observing their work. Capability is demonstrated before authority is granted.
Frequently asked questions
Context Provisioning is the provisioning of the context that produces judgment: the discipline of handing an AI Employee a governed version of the company's scattered knowledge (policies, SOPs, histories, exceptions) so that it executes its role with judgment. It divides context into three groups: must know, may consult, and must not access. It complements the role contract: the contract defines the responsibility, the context makes it executable. Every concession and every withholding is a recorded design decision, with an owner, a date, and an update mechanism.
No. More context does not always produce better judgment; sometimes it produces judgment contaminated with more elegance. A resource that sees all of a client's previous disputes anchors itself in them and treats today's client as yesterday's file. One that receives everything "relevant" drowns the signal in what is merely related. Withholding context can be a legitimate design decision: for security (least privilege) or to protect the decision from the information. The condition is to record every withholding as a context boundary, because the responsibility for a decision degraded by withheld context falls on whoever withheld it.
Five, according to clause HWF-42: the inputs (prompts carry client confessions), the outputs (every message is a recorded decision), the tool results (every query brings back data), the accumulated memory, and the derived inferences. Each one requires a declared purpose and legal basis, minimization, quality controls, special handling of sensitive data, rules for transfers and for use by the vendor (model training included), isolation by company, and verifiable deletion. Audit records are governed with the same severity as the operation they audit: protected integrity, controlled access, bounded purpose.
It is a piece of data the system manufactures about a person who never handed it over. When a collections role concludes that "this client is probably in financial trouble", it has just created new information out of scattered signals. The standard requires governing that data as if it had been collected, because frequently it is more sensitive than everything that actually was collected. It is the category almost nobody sees coming, precisely because it does not appear in any form or integration: it is born inside the system itself, and without explicit governance it stays stored with no declared purpose and no legal basis.
With the role designed, contracted, and provisioned, autonomy is still earned with evidence: the first step is shadow mode, working before owning the work.
Want the full method? Read AI Employee. For executive AI consulting or keynotes and workshops.
Go deeper
Want to bring your team to the next belt?
Book a discovery call or explore the full book.