I've spent the last few months writing about context management from the practitioner's side. How context loss breaks AI sessions before you notice it. How externalizing project state into .md files makes AI tools dramatically more reliable. How those same patterns map onto agent memory architectures being built for production. How multi-agent teams need explicit context boundaries just like human teams do.

All of that is at the individual and team level: how do you keep your AI workflows from degrading over time?

But the more I apply these patterns inside real delivery programs — client engagements, internal transformation work, projects running across multiple teams and tools — the more I see the same problems playing out at a different scale. The context loss that breaks a single AI session is the same dynamic that breaks enterprise AI pilots. Just bigger, messier, and much harder to fix because it spans organizations instead of a project folder.

Which raises a question the tactical posts don't answer: who owns this at the organizational level? And what does that do to our roles?

The enterprise version of the same problem

Every failed pilot I've seen shares the same fingerprint. Not bad prompts. Not underpowered models. Missing context.

The model saw stale data pulled from the wrong system. Critical constraints — regulatory, contractual, architectural — never made it into the workflow. The organization had fifteen different definitions of "customer" spread across as many tools, and the AI picked one at random and ran with it.

In my own work, the fix for this at the individual level is straightforward: build CLAUDE.md, keep DECISIONS.md current, write a HANDOVER.md at the end of every session. The AI doesn't have to figure out what you decided last week because the information is right there, explicit and structured.

The organizational version of that fix is a lot harder. You can't ask a 500-person enterprise to maintain a single project context file. But the underlying principle is identical: you need someone deliberately deciding what the AI knows, what it doesn't know, and how that information stays fresh as the work evolves.

That someone is what I've started thinking of as a custodian of context.

From prompt engineering to context engineering

A lot of early AI adoption focused on prompting: if you just found the right words, the model would do what you wanted. It worked well enough for demos. It doesn't scale to production, for the same reason that "just write better requirements" doesn't solve broken delivery programs. The problem isn't the request — it's the environment the request lands in.

What I see emerging instead, both in my own practice and in how enterprise AI platforms are positioning themselves, is a shift toward context engineering. Not "what do I type?" but "what does the system actually know when it acts?" That means thinking deliberately about memory — what persists and what doesn't. About retrieval — when to pull from a curated source versus a raw search. About policy — what the system is and isn't allowed to use. About handoffs — how context moves between agents and tools without the important thread getting dropped.

The .md files I use for individual projects are a primitive version of this. The agent context architecture I wrote about for multi-agent teams is the next level up. At the organizational level, this becomes actual infrastructure: semantic models, governed retrieval pipelines, access controls, audit trails for what context was available when a decision was made. Context stops being an emergent side-effect of your tools and becomes an explicit layer you design.

Why transformation people are the natural owners

Here's the thing that strikes me every time I work through this: if you work in digital transformation, program management, or enterprise architecture, this is not actually new work. The shape of it is completely familiar.

You map how work actually flows versus how it's supposed to. You mediate between business intent and technical constraints. You align definitions and priorities across teams that each believe they're the source of truth. You turn tacit knowledge that lives in senior people's heads into something that can be shared, challenged, and acted on.

That is context custodianship. We've just been doing it for a consumer that was exclusively human. The shift is that AI systems — agents, copilots, planning tools, decision support — are now also consuming that context, and they're doing it at a scale and speed where the gaps become undeniable immediately.

When I look at what breaks in multi-agent systems, it mirrors what breaks in human delivery programs: agents operating on different assumptions because no one defined the shared ground truth, context getting lost at handoffs, constraints that only one part of the system knows about. The solution in both cases isn't a better technical fix — it's the same unglamorous work of making the implicit explicit. The AI era doesn't change what we do. It changes who else needs us to do it well.

What this actually looks like in practice

The responsibilities are starting to converge, even if the job title hasn't standardized yet. Someone needs to define what "good context" looks like for a domain or workflow — which, concretely, means working with data and platform teams to decide which systems are authoritative for which entities, and building shared semantic models and glossaries so that "customer" means the same thing everywhere.

Someone needs to design how context flows through AI-assisted workflows: what persists across sessions, what's scoped to a task, when agents need a full summary versus a filtered view. More context isn't always better. The "lost in the middle" problem that breaks individual sessions breaks enterprise agent systems at scale too. The job is designing just enough context for each step while preserving the thread across the whole journey.

Someone needs to embed governance into the context stack rather than bolting it on afterward. Legal, risk, and compliance requirements have to become system instructions, access controls, and audit hooks — not review processes that run after the AI has already acted. Translating "we can't use personal data for this type of decision" into an actual architectural constraint is squarely transformation and architecture work.

And then there's the ground-level practice — the organizational equivalent of the context hygiene habits I use personally. Standardizing context headers for major programs. Maintaining shared reference files that both humans and AI tools can use. Treating context as something that gets curated, versioned, and pruned rather than accumulated indefinitely. Unglamorous, but compounding.

How roles change

The immediate implication is that we need context roadmaps alongside feature roadmaps: which domains get formal semantic models first, where AI-assisted workflows get introduced and what context they depend on, how governance evolves as we move from copilots toward more autonomous agents. This is legitimate strategic planning work, not IT infrastructure procurement.

The deeper implication is that our orchestration lens has to expand. The question stops being only "how do we align these teams?" and becomes: what context do humans need, and what do agents need — and are both getting the same source of truth? When we update a policy or refine a definition, how does that propagate to both human and AI actors? We're not just coordinating people anymore. We're designing ecosystems where they share a coherent understanding of the work.

The uncomfortable part: a lot of our current value is in tacit knowledge. Knowing where the real risks are, which dependencies actually matter, what "good" looks like in this specific domain. That expertise has to become explicit and machine-readable — encoded as system instructions, retrieval filters, structured context files — rather than living in our heads and our slide decks. If the constraint only exists in slide 17 of a presentation that never made it into any system, the AI will politely ignore it.

That's not a loss of leverage. It's a multiplication of it. Once the judgment is encoded, it scales.

The choice

The through-line from the individual context hygiene work to the organizational level is the same: AI is only as reliable as the context it operates in, and that context doesn't manage itself. Someone has to own it.

At the individual level, that someone is you. At the team level, it's a shared practice. At the organizational level, it's a deliberate function — and the people best positioned to own it are the ones who've spent careers at the intersection of business intent, organizational knowledge, and technical systems.

We can let context happen to us — as an emergent property of whatever vendors, tools, and teams show up — or we can choose to own it deliberately. If we take the latter path, our roles don't shrink in the age of AI. They deepen. We stop being just coordinators of projects and become architects of the shared context that humans and AI will rely on together.

The question isn't whether this becomes our job. It's whether we walk into it on purpose.