A working assessment for teams who already run agents against company data. It scores an estate across four stages of context readiness, from ad hoc files to governed shared memory, and it is built to be filled in with colleagues rather than read alone. The argument underneath it is simple. Context is now a production dependency, and it deserves the same controls you already give production data.

## Why an assessment rather than another guide

We have written enough guides. The problem our customers describe is not that they lack a framework. It is that they cannot tell where their own estate currently sits, so they cannot tell which advice applies to them. A team still keeping context in a shared drive needs a different first move than a team that already runs a governed memory store behind an approval gate.

So this document scores rather than advises. It gives you a set of checks, a way to weigh them, and four stages to place your estate in. We think a defensible number is worth more than another opinion, and we would rather you disagree with our scoring than nod at our framework.

## What context readiness means

Context readiness is the degree to which the information your agents act on is owned, controlled, and traceable. It is not a measure of model quality, and it is not a measure of how much data you have. An estate with a small, well-governed context store is more ready than an estate with a large, unmanaged one.

The reason this matters is that agents turn context into action. When a person reads a stale document, they usually notice. When an agent reads it, it acts, and the action is often irreversible. Readiness is therefore the answer to one question. If an agent acts on the wrong thing tomorrow, can you say why, and can you stop it happening again?

![Four stages of context readiness](/images/blog/context-readiness-assessment-figure-1.png)

## Four stages of context readiness

Every estate we have assessed sits somewhere in these four stages. The stages are cumulative. You cannot skip one, because the control that defines stage four depends on the records that stage three produces.

1. **Ad hoc.** Context lives in personal files, chat threads, and pasted prompts. Nothing is owned, and nothing survives a departure.
2. **Informal.** A shared store exists, but writes are uncontrolled. Anyone can add, and nobody approves. Retrieval quality depends on who wrote last.
3. **Managed.** Writes are scoped and attributed. You can see who added what, and when. Retention is a policy rather than an accident.
4. **Governed.** Approval sits before the read, provenance is exportable, and change control covers rules as well as records. You can answer an auditor without a project.

## How the scoring works

We score each check on a three-point scale. A check passes, partly passes, or fails. A fail is not a criticism of the team. It usually means the control belongs to a platform that has not built it yet.

| Stage | What it looks like | What is usually missing |
|---|---|---|
| Ad hoc | Personal files and pasted prompts | Ownership, retention |
| Informal | A shared store with open writes | Write scoping, approval |
| Managed | Attributed, scoped, retained writes | Approval before read, provenance export |
| Governed | Approval before read, exportable provenance | Change control over rules |

We weight the checks unevenly, and we say so on the scorecard. Ownership and retention carry more weight than retrieval quality, because a store you cannot account for is a liability regardless of how well it answers questions.

![What the assessment scores](/images/blog/context-readiness-assessment-figure-2.png)

## What the checks measure

The scorecard asks about six things, in this order.

- **Ownership.** Is there a named owner for each context store, and is that name a person rather than a team?
- **Retention.** Is there a policy that deletes, and is it enforced by the system rather than by habit?
- **Approval.** Is a change to shared context reviewed before other agents can read it, or only after?
- **Provenance.** Can you export the chain that connects an answer to the records behind it?
- **Change control.** Do rule changes go through the same review as record changes?
- **Evidence.** Is every factual claim in your own documentation traceable to a source you can show?

Those six are not equally hard. Ownership and retention are usually a matter of deciding. Approval and provenance are usually a matter of buying or building. Change control and evidence are usually a matter of discipline, and they are the two most teams fail.

## Where approval and provenance sit

Most buyers ask about approval and provenance last, and need them first. Approval before the read is what stops one team's bad context from propagating to every agent that shares the store. Provenance is what lets you answer a question about an answer months later, when nobody remembers the session.

We would rather see a modest store with both controls than an excellent retrieval system with neither. If a vendor can show you that a write is approved before it is readable, and that the approval record is exportable, they have understood the problem. If they describe storage and search, they have described half of it.

![Which numbers to trust](/images/blog/context-readiness-assessment-figure-3.png)

## How we keep the evidence honest

This assessment names its limits, because an assessment that hides them is worse than no assessment. Every factual claim carries a numbered source. Vendor-run benchmarks are labelled as vendor-run. The method page names the checks we could not complete, and where we cut a claim because it failed checking, we say that too.

You should apply the same standard to your own estate. A score you cannot defend is not a score. It is a mood, and it will not survive the first question from a risk committee.

## What to do with the result

A score is only useful if it implies a sequence. We would work in this order.

- **At stage one.** Pick one workflow and give it a named owner and a retention rule. Do not buy anything yet.
- **At stage two.** Close writes to the team that owns the store, and record who writes what.
- **At stage three.** Put approval before the read, and start exporting provenance.
- **At stage four.** Bring rule changes under the same change control as records, and re-score quarterly.

## Who this is for

This is written for platform, data, and risk leaders in organisations that already run agents against real company data. It assumes you have something in production, or something about to be. It is not written for teams still choosing a model, and it is not a procurement checklist.

If you want the control model that sits behind the scorecard, read our companion document, [The Multiplayer AI Playbook](/blog/multiplayer-ai-playbook). It covers the six layers between a shared session and a system you can run, and the [Shakudo platform](/platform) implements the controls the scorecard asks about.

## Sources and further reading

Every factual claim in the assessment carries a numbered source, and the method page names the checks we could not complete. These are the outside documents we lean on hardest.

- The [EU AI Act](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) is the regulation that will make an audit trail a requirement rather than a preference for many of our readers.
- The [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) gives a shared vocabulary for the governance sections.
- [NIST SP 800-207 on Zero Trust Architecture](https://csrc.nist.gov/pubs/sp/800/207/final) is the model behind our assume-the-agent-is-untrusted checks.
- [NIST SP 800-218](https://csrc.nist.gov/pubs/sp/800/218/final) covers secure development, which is where the provenance checks come from.
- [OpenTelemetry semantic conventions](https://opentelemetry.io/docs/specs/semconv/) describe how to record a trace, which is what an auditor will ask to see.
- [OAuth 2.0 Token Exchange, RFC 8693](https://www.rfc-editor.org/rfc/rfc8693) is the mechanism behind scoped, short-lived agent credentials.
- The [Verifiable Credentials Data Model](https://www.w3.org/TR/vc-data-model/) is how we would export provenance in a form another party can check.
- The [OWASP Top 10 for Large Language Model Applications](https://owasp.org/www-project-top-10-for-large-language-model-applications/) lists the risks the security questions map to.
- The [Google SRE book](https://sre.google/sre-book/table-of-contents/) is the reason we argue that context deserves the same service levels as production data.