GitHub as Agent Context — why versioned context matters¶
October 4, 2026 · Kishore Babu Gutta
Agents need context.
The first instinct is often to pass that context directly from one agent to another.
That works until an agent stops, a session disappears, two agents disagree, or somebody needs to understand why the current state exists.
While building Engineering Runtime, a different operating model became increasingly useful:
GitHub is the center of agent context and coordination.
The important part is not simply storing files in GitHub.
It is versioned context.
Context should survive the agent¶
An agent may start a task, create an issue, update a document, open a pull request and then disappear.
Another agent should be able to continue without inheriting a hidden conversation.
Agent A
↓
GitHub state
↓
Agent stops
↓
Agent B reads GitHub
↓
work continues
The durable state is the handoff.
Not the model session.
What counts as context¶
For engineering work, useful context already has natural GitHub forms:
- issues,
- branches,
- commits,
- pull requests,
- review comments,
- design notes,
- decisions,
- release evidence,
- backlog items,
- implementation plans,
- documentation.
These artifacts do more than store the current answer.
They preserve how the answer changed.
Context switching becomes explicit¶
A human engineer can switch between tasks by changing branches, repositories or pull requests.
Agents can use the same idea.
repository
↓
branch / issue / PR
↓
bounded task context
Instead of loading one enormous mutable memory, the agent can enter the context for the work it is performing.
That makes context switching inspectable.
The selected repository, branch, issue and pull request become part of the working state.
Versioning changes the quality of context¶
Ordinary context tells an agent:
Here is what we currently believe.
Versioned context can also tell it:
- what changed,
- when it changed,
- who changed it,
- which commit introduced it,
- which PR discussed it,
- what evidence supported it,
- what was superseded,
- and what the previous state was.
That leads to one of the most useful one-liners that came out of the Engineering Runtime development process:
Agents do not just share context. They inherit versioned context.
Why direct agent-to-agent memory is weaker¶
Imagine Agent A directly tells Agent B:
"We decided to use approach X."
Agent B receives the conclusion.
But it may not receive:
- the rejected alternatives,
- the evidence,
- the exact change,
- the review,
- the previous implementation,
- the scope of the decision.
Now compare that with:
Issue
↓
proposal
↓
branch
↓
commits
↓
PR discussion
↓
merged state
The second form is slower than an invisible memory bus.
But it is far more inspectable.
GitHub is not the executor¶
This distinction is important.
GitHub can preserve and coordinate context.
Engineering Runtime governs execution.
GitHub
↓
versioned context / coordination
↓
agent reasoning
↓
Engineering Runtime
↓
governed execution
So the responsibilities remain separate:
GitHub preserves versioned context. Engineering Runtime governs execution.
Why this matters for multiple agents¶
Once several agents work at the same time, hidden shared memory becomes difficult to reason about.
A GitHub-centred model gives each agent a bounded contract:
- what it may read,
- what it may write,
- which branch or artifact it owns,
- what evidence it must leave,
- when it must escalate,
- what it may never merge or publish.
Parallelism then comes from explicit ownership rather than invisible coordination.
The broader idea¶
This is not a claim that every form of agent memory belongs in GitHub.
Ephemeral reasoning, local scratch state and model context still exist.
The claim is narrower:
Durable engineering state should live somewhere agents can inspect, version, review and hand off.
For Engineering Runtime development, GitHub has become that durable context layer.
And because the state is versioned, context is not merely remembered.
It is auditable.