Managing Requisite Context for AI Workflows

Many organizations are adopting AI in their business, whether as generative AI or as AI agents. In all cases, the AI needs a context to work from, and for the AI to be effective that context must be requisite.

An AI model knows nothing about your organization. Everything it produces on your behalf rests on the context supplied at the moment of use. If that context covers what the task requires, the workflow can be trusted. If it doesn't, the model fills the gaps with public defaults and no one is told.

Managing requisite context is how organizations keep their AI workflows on the right side of that line.

Basic Context

The model never learns

An LLM's knowledge is fixed when it is trained. Once deployed, it doesn't learn, adapt, or accumulate experience. Its intelligence is applied to whatever is in the context window at the time of inference. Everything you need the model to know must be placed there, every time.

Retrieval (RAG) extends what can be placed in context. It doesn't extend what the model knows. A document in the context window is being read, not understood. The model can quote it and summarize it. It can't connect it to everything else it knows, notice that it contradicts a commitment made somewhere else, or apply it to a question that doesn't resemble it.

Trained knowledge is integrated into the model. Retrieved knowledge is only consulted. These are different capabilities, even though the output reads the same either way.

The model's training works against you

Public models are trained on public knowledge. An organization's working knowledge is mostly the opposite: commitments made, obligations held, decisions taken, how the organization actually operates. None of this is in the model.

It gets worse. Where your knowledge differs from public consensus, the model's training pushes back. I have spent considerable time teaching AI systems what Lean Compliance means from an operational perspective. They follow the distinctions while the context holds them in view. As soon as the context thins, they fall back to the public default, where compliance means conformance and checklists. The knowledge that makes your organization distinctive is the same knowledge the model resists. Your context has to keep correcting the model, not just inform it.

Requisite context

Requisite context is the context necessary to properly govern the work. An agent draws on two sources: its training and its context. Context is what shapes inference to align with the organization's objectives, and it is the only source the organization controls.

For any task, the requisite context is what the task demands. What must be supplied is that demand, minus what the model's training already covers, plus what it takes to correct the model where its training does not align with your institutional knowledge.

This divides work into two classes.

For some work, the prompt alone is sufficient context: summarize this document, draft this email. The task carries what it needs, and the model's training covers the rest. Agents do well here, and this is what most demonstrations show.

Other work requires institutional knowledge sufficient to govern and shape it. That knowledge is contained in policies, procedures, obligations, and other institutional documents. Some of it can be supplied with the prompt, and some can be pre-filled through retrieval and embeddings.

But supplying the organization's entire body of institutional knowledge with every request is not possible within the model's context limits, and would be costly even to attempt. And whatever is supplied, none of it improves the model's inference or teaches it anything.

The question is always what exactly is needed for the work, and answering it is where institutional intelligence comes in. Without that judgment, the agent produces output that sounds competent but is shaped by public defaults rather than by the organization.

The model will not close this gap for you. It fills every unstated requirement with defaults from its training. Nothing gets flagged. The output looks complete, hiding the fact that no one made those decisions.

Organizations must manage requisite context

Requisite Context

The AI industry calls the technical side of this problem context engineering: designing the retrieval, memory, and pipelines that assemble what a model sees. That tooling delivers context to the model. It cannot decide what the context should contain.

Only the organization can determine what its knowledge is, where that knowledge differs from public consensus, which workflows can be safely delegated, and who is accountable when the context falls short.

This demands a different kind of knowledge management. Traditional KM served human readers who compensated for gaps, ambiguity, and stale content with their own understanding. AI workflows have no such reader. Where a person fills a gap with institutional knowledge, the model fills it with the public default. Knowledge must now be managed for machine consumption: explicit, complete, current, and marked for authority. Fit for inference, not just searchable.

Requisite context does not assemble itself. It is an organizational capability. Organizations that deploy AI workflows without it will get confident answers based on the public average.

The essential capabilities for today's Knowledge Management include:

• Knowledge codification. Institutional knowledge must be made explicit, current, and authoritative before it can be supplied as context. Much of what matters lives in unwritten commitments and operating norms that no retrieval system can fetch. Knowledge that carries obligations must be versioned, attributable, and revocable.

• Scope determination. For each class of AI workflow, list what a correct output depends on. If the list can't be completed, that tells you something important: requisite context cannot be supplied and the workflow should not be delegated to an agent.

• Interference assessment. Identify where your organization's knowledge differs from public consensus. These are the points where the model will revert to public defaults, and they need explicit, persistent context.

• Context provisioning. Assemble and deliver the right context to the right workflow through governed means, not ad hoc prompts and pipelines built by whoever happens to write them.

• Sufficiency testing. You can't prove context is sufficient, but you can test for when it isn't. Probe deployed workflows with questions where the correct answer depends on your knowledge and the wrong answer is the public default. If you get the public answer, your context isn't enough.

• Drift monitoring. Sufficiency degrades in operation. Context gets compressed, sessions drift, and the model's training reasserts itself. Requisite context is a variable to be regulated, not a condition established once at deployment.

The context an AI agent acts from is the organization's representation of itself. Keeping that representation faithful is a promise the organization makes to everyone who relies on the agent's outputs. That promise must be managed.

---

Raimund Laqua, P.Eng., PMP is the founder of Lean Compliance and chairs the Digital Engineering Committee for Engineers for the Profession (E4P).