The Substrate Autonomous Agents Need: Ownership, Context, Decision Traces

GitHub had more than 14,000 internal repositories and fewer than half with a clear owner. In under 45 days, every active repository had one. Roughly 8,000 repos with no active owner and no active use got archived. The enforcement cadence, which started as a 30-day batch check, is now down to an hourly pass. This is not a culture initiative. It is a dated, reproducible engineering project, and it is the missing half of every conversation about putting agents in the production path.

The industry is racing to give agents write access to code, infrastructure, and runbooks. Almost none of that racing pauses to ask the prior question: does the thing the agent is about to touch have a durable owner, and does the agent have a coherent view of the state it is reasoning over? Skip that question and autonomy is not a capability upgrade. It is a liability with no addressable party.

Ownership Is Solvable, and GitHub Just Solved It

The instinct when ownership data is missing is to treat it as a people problem: nag teams, run a spreadsheet campaign, hope compliance improves. GitHub’s approach was different. They bootstrapped roughly 40% of ownership coverage directly from the existing service catalog, meaning ownership was often already recorded somewhere adjacent to the repo and just needed to be pulled forward instead of asked for again. That single move did more than any awareness campaign could, because it removed the step where a human has to remember and self-report.

For the remaining repos, they didn’t negotiate indefinitely. They applied a clear default: no owner and no signal of active use within the enforcement window means the repo gets archived. Archiving is reversible. Ambiguity is not, because ambiguous ownership is exactly the condition an incident responder or an autonomous agent inherits at 3am with no one to page.

Three properties made this a project rather than a permanent campaign:

• A defined end state. 100% of active repositories with a listed owner. Not “improve ownership hygiene,” a number with a deadline.
• A default that resolves ambiguity automatically. Unowned and inactive means archived, not means escalate to a committee.
• Enforcement that tightens over time. 30-day checks became 1-hour checks once the backlog was cleared, so drift gets caught before it re-accumulates.

The reason this matters for agent governance specifically: an owner is the thing that turns “this changed and something looks wrong” into “call this person, they have context and authority.” Without a durable owner, every agent action on that asset is unattributable to a human who can validate it, override it, or be held accountable for it. You cannot build a review gate, an escalation path, or an audit trail on top of a null.

Context Is the Other Half, and It Doesn’t Collapse to One Feed

Ownership tells you who is accountable. It does not tell you what an agent needs to know before it acts. That’s where the 4-Body Problem framing is useful, even though it comes from a vendor with a commercial stake in infra-context tooling (StackGen) and offers a framework, not data. Read it as a way to name a real gap, not as evidence that any particular product closes it.

The claim: autonomous operational decisions require reasoning across four bodies of state simultaneously, not sequentially.

• Code. What the system is supposed to do, as written and versioned.
• Infrastructure state. What is actually deployed, configured, and connected right now.
• Runtime signals. What the system is doing under live load: latency, error rates, saturation.
• Operational knowledge. The tribal and documented context about why past incidents happened and what fixes worked or didn’t.

An agent with only runtime signals sees a spike but has no way to trace it to the deploy that caused it. An agent with only code and infra state cannot tell if a config change is currently degrading production. An agent with everything except operational knowledge will re-propose a fix the team already tried and rejected two months ago for a documented reason. Each body alone produces a plausible-looking but wrong recommendation. The correct decision lives at the intersection, and today most tooling gives an agent a strong feed on one body and weak or no access to the other three.

This is the actual argument for treating context as infrastructure rather than as a prompt-engineering problem. A better prompt does not manufacture infrastructure state the agent was never given. A unified context layer, whatever shape it takes, is what closes that gap. What shape it takes is a build decision your team makes with eyes open, not something to take on faith from a single vendor’s blog post.

The Decision-Trace Record: Make the Reasoning Auditable

Ownership plus context gets an agent to a defensible decision. It does not make that decision reviewable after the fact unless the decision itself leaves a record. Every autonomous action needs a trace that captures, at minimum:

• Inputs. A snapshot of the state graph the agent reasoned over: which code version, which infra state, which runtime signals, which knowledge sources, at the moment of the decision.
• Policies in effect. Which guardrails, approval thresholds, and blast-radius limits constrained the action.
• Model version. Which model and configuration produced the decision, so a regression in agent behavior can be traced to a specific update.
• Rejected hypotheses. What the agent considered and ruled out, not just what it chose. This is the difference between “the agent restarted the service” and “the agent considered a rollback, ruled it out because the previous deploy was 6 hours old and the queue had already drained, then restarted the service.”
• Action and outcome. What actually happened, and what the system looked like afterward.

This record does for agent decisions what a durable owner does for a repo: it turns an opaque action into something a human can pick up, question, and hold accountable. Without it, “the agent decided to do X” is a dead end. With it, it’s the start of a review.

Neither GitHub’s ownership work nor the 4-body framing was designed with the other in mind. Put together, they describe the same substrate from two directions: who is accountable for what exists, and what an agent must see and record before it’s allowed to act on what exists. Skip either half and autonomy is a demo, not a system you can run in production.

Do This Now

Run GitHub’s ownership audit on your own repos and infrastructure assets this week, not as a hygiene exercise but as a prerequisite check: for every asset an agent might soon be able to modify, does it have a listed, current owner? If coverage is under 80%, treat that as a blocker on expanding agent write access, not a parallel workstream. Bootstrap what you can from existing catalogs before asking anyone to self-report, set an archive-by-default policy for the rest, and put an enforcement job on a schedule so the number doesn’t quietly decay again. Ownership is the cheaper problem to solve and the one with no excuse left not to.

---

This analysis synthesizes How GitHub Gave Every Repository a Durable Owner (GitHub, July 2026), The 4-Body Problem of SRE (CNCF, July 2026).

Victorino Group helps teams build the ownership and context substrate that safe agent autonomy depends on. Let’s talk.