Git was designed for version control. Track changes over time, enable rollback when things break, coordinate work across teams, resolve conflicts when people edit the same files. This is what Git does, what it was built for. But when work becomes async and agent-driven, Git’s role shifts. It becomes the continuity layer, the record of what happened while you were away. Commits aren’t just snapshots of code, they’re checkpoints in ongoing work. The repository becomes memory, not just history.
The shift is subtle but fundamental. In synchronous work, Git tracks what you did. In async work, Git tracks what happened, whether you were there or not. The difference matters.
The conventional view
I’ve used Git the same way for years. Make changes locally, commit when I reach a stopping point, push when I’m ready to share, pull to get others’ changes, merge when conflicts arise. Commits capture what I did, when I did it. “Fixed authentication bug.” “Refactored database layer.” “Added user permissions.” The commit history is my history, the team’s history, a record of decisions and changes we made together.
This works for synchronous development. Work happens when people are present. Commits are milestones in human work. The repository stores what we built, when we built it, why we made particular choices. Version control in the traditional sense.
What changes with async work
I wake up to commits I didn’t make. “Generated API endpoints based on spec.md.” “Added test coverage for payment flow.” “Refactored to match architectural patterns from plan.md.” Git is recording work that happened without me, documenting decisions made by agents following specifications I approved hours or days earlier.
The repository becomes the record of what occurred. Not just version control, tracking changes, but memory, what happened, why, when. The commit history is the story of how the system evolved, even when I wasn’t present for parts of it. Commits become checkpoints in long-running work. Agents don’t work in one session, they pause, resume, continue across hours or days. Each commit is a checkpoint telling me “here’s where we got to.” When I return, Git tells me what happened since I left.
The overnight implementation
An agent worked overnight implementing a domain API orchestrator. I wake up and check the Git log. 23:47 - “Initial implementation of orchestrator routing.” 00:23 - “Added parallel enrichment for submission flow.” 01:15 - “Implemented idempotency handling.” 02:08 - “Added error handling with 503 retry hints.” 03:42 - “Final: All acceptance tests passing.”
Git provides a timeline of what happened while I was away. Decision points are visible in the commits. The switch from sequential to parallel happened at 00:23, documented in both the commit message and the diff. If I need to investigate something, the checkpoints are there. I have a complete record without having observed the work.
This isn’t just convenient. It’s necessary. I can’t supervise work I can’t follow. Git provides the thread connecting yesterday’s work to today’s decisions. The commit history is my briefing when I return.
Locking verified artifacts
The verified progression workflow from the previous article depends on Git. spec.md committed and locked, Git records “requirements approved.” plan.md committed and locked, Git records “design approved.” Tests committed and locked, Git records “test suite verified.” Code committed, Git records “implementation against locked artifacts.”
Git isn’t just tracking files changing. It’s recording the progression through stages, locking decisions at each gate, creating the verified trail. The commit history proves the process was followed. I can trace back through the repository and see what was verified when, what decisions were locked before implementation, what context informed particular choices.
This transforms how I think about commits. They’re not just snapshots anymore. They’re formal records of approval, gates that prevent work from proceeding until verification completes. Git becomes the mechanism that enforces process.
Context for returning
I left Friday with design in progress. I return Monday. The Git log tells me what happened. Friday: “Draft plan.md with sequential orchestration.” Saturday: AI review ran, committed feedback doc. Sunday: Revised plan.md to parallel enrichment. Sunday: plan.md approved and locked.
Git tells me what I need to know. What stage the work reached, what decisions were made and revised, what’s locked and ready for the next stage. No need to ask “what happened while I was away.” The repository is the answer.
This is different from traditional version control, where the question is “what changed?” Now the question is “what happened?” Git provides the narrative, not just the diff. Commit messages become more descriptive, recording intent and context, not just action. The repository becomes documentation of process, not just code.
Agent reading Git as memory
Tuesday morning. The agent starts work implementing the orchestrator from the locked plan. First action: read Git to understand context. Check out latest from main. Read plan.md, the locked design artifact. Scan the commit history. “Why parallel enrichment?” Find Sunday’s commit: “Revised plan.md to parallel enrichment based on AI review feedback re: performance.” Read the AI review feedback doc committed Saturday.
The agent doesn’t execute blindly. It uses Git to understand prior decisions. Commit messages explain the why behind artifacts. Context files, review feedback, notes, constraints, all stored in Git. The agent reconstructs the decision trail before implementing.
This is bidirectional. Human commits requirements, design, approval gates. Agent reads, understands context, constraints, decisions. Agent commits implementation checkpoints, test results. Human reads what happened, what was decided, where work got to. Git is the shared memory interface. Both sides leave breadcrumbs, both sides follow the trail.
In traditional development, the agent would need me to explain context verbally, answer questions about why we chose this approach over that one, clarify constraints. In async development, the agent reads Git. The repository is the shared understanding. I don’t need to be present to provide context. Git provides it.
What this enables
I can’t supervise what I can’t follow. Agents can’t work intelligently without context. Async work depends on continuity, and Git provides the thread connecting work across time, connecting human and agent across async sessions. Each checkpoint reconstructs the narrative. I’m not guessing what an agent decided or why. The agent isn’t guessing what I wanted or why I made particular choices. The commit history, the messages, the artifacts, the progression through verified stages, all of it creates the shared context both sides need.
Git becomes the shared memory interface. Humans commit requirements, designs, approvals, context. Agents read to understand decisions, constraints, prior work. Agents commit implementations, test results, checkpoints. Humans read to understand what happened, what changed, what’s ready. This is bidirectional. Not just humans supervising agents. Agents also reading Git to understand context. The repository is how both sides stay synchronized.
This changes how I use Git. Commits become more frequent, checkpoint after each meaningful stage. Messages become more descriptive, recording not just what changed but why, what was verified, what constraints mattered. Artifacts get stored in the repo: specs, plans, reviews, context notes. The Git log becomes my briefing tool, the first thing I check when returning to work. The repository becomes the source of truth for what happened, not just what changed.
Without this, async work becomes guesswork. Agents start fresh each time, no context from prior work. Humans return to work with no sense of what happened. Decisions get lost, work gets duplicated. Git as shared memory layer makes async work tractable.
Not just history
Git was version control: track changes, enable rollback, coordinate teams. Git becomes memory: record what happened, provide context, maintain continuity across time and across async work sessions. Same tool, different role. The shift isn’t dramatic, it’s gradual. But the implications compound.
Commits aren’t just snapshots anymore. They’re checkpoints in work that spans days, not hours. The repository isn’t just storage, it’s the shared understanding between human and agent. Git provides the continuity layer that makes async supervision possible, the memory layer that makes async collaboration tractable.
This is what makes async work different from remote work or distributed teams. In remote work, humans coordinate through Git, but everyone is present for the work they do. In async work with agents, work happens when no one is watching. The repository becomes the persistence layer for context. Both human and agent depend on it. Not just to see what changed, but to understand what happened and why.
Teams treating Git as memory succeed at async work. Teams treating Git as just version control struggle to maintain context. The difference is recognizing Git’s expanded role, adapting workflow to treat commits as formal checkpoints, writing messages that document intent and verification, storing artifacts that both sides need, using the repository as the source of truth for what happened, not just what changed.
The choice isn’t whether to use Git. Everyone already does. The choice is whether to recognize what it became, and adapt how you use it accordingly.