What If AI Agents Had Git for Their Execution History?
Git gave software developers a simple way to experiment, branch, recover, and understand how a codebase changed over time. But AI agents do more than modify files, they make decisions, call tools, execute commands, and accumulate state throughout a run. This raises an interesting question: what if an agent's execution could be versioned just like code? This article explores the idea of reversible agent execution using Shepherd, an open-source research project from Stanford and Northeastern University.
Series: Lets go with AI and AWS (4 articles)
- …
- 3What If AI Agents Had Git for Their Execution History? This article
What If AI Agents Had Git for Their Execution History?
Git changed software development by making code history recoverable.
Developers can create a branch, experiment with an idea, make risky changes, and return to an earlier state when something goes wrong.
Now consider an AI agent working on a complex task.
An agent can read files, call tools, execute commands, modify code, interpret results, and make decisions based on what it encounters. If the agent takes the wrong direction halfway through a long task, going back to the exact state before that decision is not always straightforward.
This raises an interesting question:
What if AI agent execution could be versioned like code?
This idea is being explored by Shepherd, an open-source research project from researchers at Stanford University and Northeastern University. Shepherd represents interactions between an agent and its environment as typed events in a Git-like execution trace, enabling capabilities such as forking and replaying execution.
The Problem: Agents Have More State Than Code
Git is excellent at tracking changes to a repository.
But an AI agent's state is much larger than the files it modifies.
During a single task, an agent may have:
- Model context
- Tool calls and responses
- File changes
- Command execution
- Environment state
- Intermediate decisions
- Outputs from external systems
Consider a coding agent trying to fix a bug:
- It explores the repository.
- It identifies a possible cause.
- It changes the implementation.
- It runs a test.
- It receives an unexpected result.
- It interprets the result incorrectly.
- It changes another part of the system.
- The task eventually fails.
You may be able to restore the Git repository, but that does not necessarily recreate the entire agent state that existed several steps earlier.
The challenge is therefore not simply versioning code.
It is versioning execution.
From Git History to Agent Execution History
A traditional Git history might look like:
1
Commit A → Commit B → Commit C → Commit DAn agent execution is more like:
1
2
3
4
5
6
7
8
9
10
11
12
13
Task
↓
Tool Call
↓
Model Response
↓
File Change
↓
Command Execution
↓
Tool Result
↓
Next DecisionShepherd records these interactions as events in an execution trace. Instead of treating an agent run as one continuous, irreversible process, the execution becomes a history that can be inspected and manipulated.
This creates a powerful possibility:
An agent run can become a collection of recoverable states rather than a one-time sequence of actions.
Forking an Agent's Execution
One of the most interesting consequences is the ability to fork an execution.
Imagine an agent reaches a decision point and has two possible approaches.
Normally, you might have to let the agent continue, discover that the approach failed, and then restart the task.
With a forkable execution model, the idea becomes:
1
2
3
4
5
6
7
Decision Point
/ \
/ \
Approach A Approach B
│ │
▼ ▼
Evaluate EvaluateBoth approaches can begin from the same previous state.
This makes experimentation much cheaper conceptually.
Instead of asking:
"Should I restart the entire task?"
you can ask:
"What happens if I take a different path from this point?"
This can be useful for debugging, evaluation, optimization, and agent supervision.
Replay: Debugging the Agent, Not Just the Code
Traditional debugging often focuses on the final error.
Agent debugging needs to go one step further:
Which decision caused the agent to enter the wrong state?
Execution replay can help answer that question.
Suppose an agent performs 30 actions and fails at action 30. If the execution history is available, an engineer or supervising system can inspect what happened earlier and replay from a relevant point rather than blindly starting from the beginning.
This changes debugging from:
"The agent failed. Run it again."
to:
"The agent failed. Let's inspect where the execution diverged and try another path."
The Shepherd research specifically explores efficient replay and branching of agent executions, including reuse of cached model context during replay.
Agents Supervising Agents
Once agent execution becomes observable and forkable, another possibility emerges: one agent can supervise another agent.
A supervisor could monitor an agent while it works and intervene when the execution starts moving in an undesirable direction.
Conceptually:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Supervisor Agent
│
▼
Coding Agent
│
▼
Tool / Code / Test
│
▼
Evaluation
│
┌───┴────┐
▼ ▼
Continue Intervene
│
▼
Fork
│
Try another pathThe Shepherd paper evaluates this idea through runtime intervention and reports improved results on the benchmarks used in its experiments. These numbers should be interpreted within the specific experimental setup rather than as a general guarantee for other agent systems.
The broader idea is what matters:
A failed agent run does not necessarily have to mean starting over.
What Could This Look Like on AWS?
Shepherd itself is not an AWS service, so it is important to distinguish its architecture from a possible AWS implementation.
However, the underlying concept can inspire an AWS-based design for reversible agent workflows.
A conceptual architecture could combine:
- Amazon Bedrock for model and agent capabilities
- AWS Lambda or Amazon ECS/AWS Fargate for tool and execution environments
- Amazon S3 for artifacts and execution traces
- Amazon DynamoDB for execution metadata
- AWS Step Functions for workflow orchestration
- Amazon CloudWatch for logs and observability
The resulting workflow could look like:
User request → Agent → Execution environment → Trace → Fork / Replay → Evaluation → Verified result
The important design principle is not any particular AWS service.
It is treating agent execution as state that can be observed, stored, evaluated, and potentially recovered.
Why This Matters
As AI agents become more autonomous, traditional software engineering practices need to evolve with them.
For conventional applications, we already have mature mechanisms for:
- Version control
- Testing
- Logging
- Debugging
- Rollbacks
- Deployment
Agentic systems introduce additional questions:
- Can an agent's state be checkpointed?
- Can an execution be replayed?
- Can we branch from an earlier decision?
- Can another agent inspect the execution?
- Can a failed run be recovered instead of restarted?
- Can agent-generated changes be reviewed before affecting production?
These are not simply prompt-engineering questions.
They are agent infrastructure questions.
A New Way to Think About Agent Reliability
There is an interesting progression:
Logging → Observability → Traceability → Replay → Forking → Intervention
Each step provides more control over autonomous execution.
A conventional log can tell us what happened.
A trace can help us understand how it happened.
Replay lets us reproduce a state.
Forking lets us explore alternatives.
Intervention lets another system change the direction of execution.
Together, these capabilities could make increasingly autonomous agents easier to debug and control.
Shepherd Repository
Final Thoughts
Git made software development safer because experimentation became reversible.
The same principle could become important for AI agents.
An agent should not necessarily be treated as a black box that receives a prompt and eventually produces an answer. Its execution can instead be viewed as a sequence of decisions, actions, tool interactions, and environmental states.
Shepherd is an interesting exploration of this idea. By representing agent-environment interactions as a Git-like execution trace, it investigates how capabilities such as forking, replay, and runtime intervention can be applied to agentic systems.
Series: Lets go with AI and AWS (4 articles)
- …
- 3What If AI Agents Had Git for Their Execution History? This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article