Who Owns your/the Context?

Everyone talks about agentic transformation as though the hard part is the agents. It isn't. The agents are getting better on their own, month after month, with no help from you. The genuinely hard part is everything that steers them, the context, the workflows, the processes, the artifacts, and, more than anything, the question almost no one is asking clearly enough: who owns it?

Get that wrong and you land in one of two failure modes. Either a central platform team owns all the context and becomes a bottleneck that nobody trusts and everybody routes around; or it's a free-for-all, and every engineer reinvents the same setup, slightly differently and slightly badly, in parallel. Get it right and the leverage is enormous, considerably bigger than most organisations realise before they've felt it.

This is a piece about how to get it right. It's less about tooling than about the operating model around the tooling, the part that, in our experience, actually decides whether an agentic transformation compounds or stalls.

First, widen the frame: context, workflows, processes, artifacts

It's tempting to make this only about "context," but the ownership question spans a broader set of things: the context you feed agents, the workflows they run, the processes around them, and the artifacts they produce and consume. They don't all behave the same way, and that difference is the key to the whole model.

Workflows and processes travel well. How you shape a ticket, how you run a review, the stages a change moves through, these generalise across teams and can be standardised and shared without much friction. They're relatively portable.

Context is different, and it's the most interesting dimension. Context is the domain knowledge specific to a developer or a team: what this service actually does, why this awkward constraint exists, what "good" looks like right here. It does not generalise. And it's exactly the material agents get wrong without. That combination, highest value, least shareable, is why context is the thing you most need an explicit ownership model for, and, not coincidentally, the thing teams most often leave implicit and unowned. (Sharing context across teams is its own thornier topic; we're deliberately leaving it for another day.)

We've done this before: the DevOps and SRE parallel

If this all feels familiar, it should, we have lived through this shape of problem before. Every prior platform shift, from agile to DevOps to SRE, forced an organisation to answer the same two questions. How opinionated should the central team be? And how much should they do for people versus enable people to do for themselves?

Our strongest piece of advice is this: follow the stance your organisation already took on those earlier transformations. An org that centralised DevOps hard, with a strong platform team setting the rules, will expect and accept a strong central agent-enablement function, and will reject a laissez-faire one as abdication. An org that pushed ownership out to autonomous teams should do the same here, or the whole thing will feel alien and get quietly ignored. You're not choosing in a vacuum; you're choosing in a culture that already has a memory of how these transitions go.

And speed changes the answer. The faster you need to move, the more you should standardise first and fan out later. You cannot transform quickly and bespoke at the same time, that's how you get stuck. If speed is the priority, pick a standard, get everyone on it, and earn the right to diverge afterwards. If deep local fit matters more than speed, you can afford to let teams shape things from the start. Just choose deliberately, rather than discovering your choice by accident.

The ownership model

The cleanest rule we've found is simple, and it maps directly onto the frame above: ownership follows the organisational unit.

• Individual and team context is owned by the domain experts, the people who actually hold the knowledge. This is theirs. An enablement team can and should support them with tooling, but it must not own their context. The people who know why the constraint exists are the only people who can keep that context true over time.
• Org-wide context, the shared foundations everyone depends on, is stewarded by an enablement or platform team, with open contribution from everyone else. Stewardship here means curation and quality, not gatekeeping.

The line that keeps this whole thing healthy: the enablement team provides the tools, not the ownership. Their mandate is to make it easy for the right people to encode, improve, and maintain their own context, not to become the single throat that every context change has to pass through. The instant enablement owns the context, you have faithfully recreated the very bottleneck you were trying to escape, just with a newer logo on it.

Context engineering vs. loop engineering

It's worth separating two terms that get lumped together, because they're owned and operated differently.

Context engineering is the work of optimising the context itself, the markdown, the verifiers, the hooks, the linting rules, everything in the repo that steers an agent on a given run. It's intimate, local work, and it belongs close to the people with the domain knowledge.

Loop engineering is broader. It includes the maintenance agents and the automated factory improvement that make the whole system better over time, the inner loop of a single run, the middle loop that analyses agent behaviour across many runs and proposes improvements, and the outer loop that asks whether the shipped feature actually moved the business metric it targeted.

The reason this distinction matters for ownership: the loops can often be operated more centrally, but the context underneath them usually cannot. So when you design your operating model, don't accidentally hand the deeply local thing (context) to the team that's set up to run the central thing (the loops). They're different jobs with different natural owners.

What the enablement team actually does

If enablement doesn't own the context, it's fair to ask what it is for. Quite a lot, as it turns out, it's just leverage rather than ownership.

A good agent-enablement (or platform) team builds the paved road: the tooling that makes it easy for everyone else to encode and improve their own context. That's the registry where skills and lenses live and get versioned, the eval platform that lets people prove a change to their context actually helped, the review and maintenance loops that operate across the whole org, and the editing tooling that makes context changes low-friction for people who aren't platform specialists. It's a "buy to build" posture: give teams the common infrastructure so they don't each rebuild the plumbing, and let them model their own corner of the world on top of it.

The best analogy is the one we already trust from ordinary software: an enablement team is to a factory what a compiler, a linter, and a testing platform are to writing code. Nobody argues the compiler should own your business logic. It's the dependable machinery underneath, and your logic, your context, sits on top, owned by you. Push the paved road far enough and you get sensible defaults for a team that just wants to click "next," while still letting an opinionated team eject and structure things their own way without rebuilding the shared foundations.

Concretely, the graduated approach looks like this in the wild. An enablement team lands the tooling and runs a show-and-tell in one team that's already seeing value. For a second team that's interested but stretched, they do the first pass of context themselves, draft the skills, wire the verifiers, but nothing merges until that team reviews and approves it, so ownership never actually leaves the domain experts. Only for a team that's stalled entirely, after real communication hasn't moved it, do they step in and make the change directly, and even then they treat it as a temporary intervention, not a transfer of ownership. Same tools, same road, three different amounts of push depending on where each team actually is.

The tension nobody escapes

There is a real, irreducible trade-off at the heart of all of this, and pretending otherwise is precisely how these programmes fail.

Automate too much, do it all for people, and adoption goes up while understanding and genuine ownership go down. You end up with engineers running on context they don't understand and can't maintain, which feels like progress right up until it very much doesn't. Do nothing, leave every engineer to fend for themselves, and they drown, because this is one more demanding thing piled on top of everything else they're already managing. Neither extreme works.

The way through is graduated, and it's the same escalation ladder good enablement teams have always used, only the subject is new:

1. Overcommunicate. Show and tell. Demonstrate value in an area that's already working, so people see the point before they're asked to change.
2. Do some of it for them, but have them approve the output. This is the crucial middle rung. You provide the leverage, but ownership stays with the team because nothing lands without their sign-off. Adoption rises and understanding is preserved.
3. Only if progress genuinely stalls, step in and make the change yourself. This is the last resort, not the default. Reaching for it too early is exactly what erodes ownership.

Measure gently

There's a strong temptation to reach for enforcement metrics, and it's worth resisting. A better instinct is to track something like context-engineering activity per engineer, not as a stick, but as a way to notice who might be stuck and to start a conversation rather than issue a mandate. Think of it as loop-engineering telemetry: it prompts the human interaction that actually moves things, instead of manufacturing compliance. The moment such a metric hardens into a target, the ownership you were trying to cultivate quietly evaporates, and you're back to people gaming a number instead of caring about their context.

Three things to take away

1. The leverage of getting context ownership right is much bigger than people realise. It is, quite literally, the difference between agents that quietly compound value across your organisation and agents that quietly compound mess.
2. Own context at the right organisational level, individual, team, or org, and let the enablement team provide the tools, not the ownership. Match the owner to the knowledge.
3. Decide, deliberately, where you sit on the standardisation spectrum. It is the same decision you made with agile and with DevOps, and your organisation already has instincts about it. This time, make the choice on purpose, with speed and culture explicitly in view.

The agents will keep getting better whether or not you sort any of this out. Whether that makes your organisation meaningfully faster, or merely messier at higher velocity, comes down almost entirely to a question that sounds administrative and is in fact strategic: who owns the context?