Version Control for AI Agents: What Small Businesses Should Set Up First

Why this matters now

Small businesses are putting AI to work in everyday tasks, including writing, support, and software changes around WordPress sites. That is useful, and it also creates a new kind of risk: an agent can move faster than a person, touch more files, and leave you without a clear way to answer "what changed?" or "can we go back?"

This is not only a developer problem. If you use a coding assistant on a theme, a plugin, or a staging copy of a site, you need the same discipline you would use for any other code change: work in isolation, review the diff, then merge. If you use a custom agent for customer support or internal research, you also need a record of the instructions and tools it was running, because a small prompt edit can change its behavior. Our AI Consulting work starts with that kind of practical control, not with adding more tools for their own sake.

Two things to version

It helps to separate two layers:

• The work the agent does. File edits, command output, and any data it writes. The goal is to review that work and roll it back if needed.
• The agent itself. System prompts and templates, tool names and schemas, model settings, configuration, and memory or knowledge the agent relies on. The goal is to know which combination was in use, and to promote or roll back that combination on purpose.

The rest of this article walks through the main options in each layer, using the vendors' own documentation. We are not recommending that every small team adopt every product below. Most teams should start with Git and human review, then add a prompt registry or a data-versioning tool if they are actually running a custom agent or an AI workflow that depends on changing datasets.

Git workflows for coding agents

Git remains the durable record. Checkpoints and undo features in coding agents are built for a single session. The official docs for these tools say so plainly, and they tell you to keep using Git for permanent history and collaboration.

A branch and a pull request per task

A reliable pattern is: start from a clean, committed state, create a branch for one agent task, let the agent work only on that branch, then open a pull request and review the diff before merging. If the approach is wrong, you can delete or abandon the branch and your main branch never received the change. That is ordinary Git practice, applied on purpose because agents can generate a lot of changes quickly.

GitHub documents this pattern for its cloud agent as well. In Copilot CLI, the /delegate command hands a task to Copilot cloud agent on GitHub. According to GitHub's documentation, Copilot creates a branch, opens a draft pull request, works in the background, and requests a review. You can keep working locally, and the pull request is the review surface. That is the same idea as "one task, one branch, one review," even when the agent is running in the cloud rather than on your laptop.

Worktrees, so agents do not collide

A Git worktree is a second working directory attached to the same repository, with its own checkout and usually its own branch. That lets two agents, or an agent and a person, edit the same project at the same time without overwriting each other.

Cursor's documentation says worktrees let Agent work in isolated Git checkouts, so each task gets its own files and changes while your main checkout stays untouched. In the IDE, /worktree starts an isolated run for the rest of a chat. Afterward you can commit or open a pull request from that checkout, bring the result back with /apply-worktree, or discard it with /delete-worktree.

Claude Code documents the same idea. The command claude --worktree feature-auth creates an isolated worktree, by default under .claude/worktrees/ at the repository root, on a new branch. You can start another isolated session with a different name in a second terminal. Anthropic also documents worktree isolation for subagents, including an isolation: worktree setting, so parallel edits are less likely to conflict.

Checkpoints and undo, and what they do not cover

These features are useful, and they are not a substitute for Git.

Cursor says Agent automatically creates checkpoints before significant changes, capturing the state of modified files. You can click a checkpoint in the chat timeline to preview files and restore them. Restoring a checkpoint reverts files only. It does not remove messages from the conversation. Cursor stores checkpoints locally, separate from Git, and tells users to use Git for permanent version control.

Claude Code automatically tracks file edits made with its editing tools. Each prompt that starts a turn creates a checkpoint. The product keeps file snapshots for the 100 most recent checkpoints in a session, saves them with the conversation so /rewind still works after you resume, and by default deletes a session's snapshots about 30 days after the session last saved one. The rewind menu can restore code and conversation, conversation only, or code only. Anthropic is explicit about the limits: files changed only by Bash commands are not tracked; most subagent edits are not restored (with a narrow exception for a foreground forked skill); and checkpoints are "designed for quick, session-level recovery." For permanent history, it says to keep using version control such as Git.

GitHub Copilot has more than one agent surface, and the undo story is not identical on each of them. In agent mode in supported IDEs, GitHub says Copilot can edit files and run commands to complete a task, and that you stay in control: you review streamed edits and can undo any you do not want, and by default you approve commands before they run. In Copilot CLI, GitHub documents a fuller rewind: press Esc twice when Copilot is idle, or use /undo (alias /rewind), then choose conversation only or conversation plus files. Rewind restores only the files Copilot changed, works even in folders that are not Git repositories, skips files you edited afterward, and is not available for remote-backed sessions. GitHub also lists cases where file restoration is skipped, including files over 10 MB and a single turn that changes more than 500 files. After a rollback, GitHub suggests using Git commands to verify the repository state.

The practical takeaway is the same across these tools: use checkpoints or undo to back out a bad turn in the current session, and use Git if you need a record that survives a new chat, another computer, or a teammate's review.

Versioning prompts, tools, configs, and memory

Once you are running a custom agent, or even a single important prompt that you keep editing, the prompt is part of the product. A wording change can alter what the agent does. The same is true of tool definitions, model settings, and memory. Several platforms now treat those artifacts more like versioned code.

LangSmith

LangSmith, from LangChain, stores prompts with commits and tags. Every saved update creates a new commit with a unique hash, so you can view history, compare a commit with the previous version, and pull a specific version in code by commit hash or by tag. Reserved staging and production tags are used as environments. You can promote a commit to Staging or Production, and each environment keeps an ordered history so you can roll it back to a previous commit. Tags such as production can be referenced in code, for example client.pull_prompt("joke-generator:production"), so you can change which version is live without editing the application. LangSmith can also fire a webhook on a prompt commit, which vendors and users often hook to CI/CD or to a GitHub sync.

LangSmith's Prompt and Context Hub goes a step further for agents. LangChain describes contexts as versioned bundles of instructions and tools that define a skill or a full agent, promoted through environments so agents pull the right version. That is one of the clearer official attempts to version "the agent," not only a single prompt file.

PromptLayer

PromptLayer's Prompt Registry stores the messages, input variables, model settings, and version history your application uses at runtime. Each save creates a new version. Before saving, the product shows a diff and asks for a commit message. You can inspect previous versions and compare them side by side. PromptLayer's documentation points from there to release labels, which choose which prompt version production code should use, including options for staged or split releases. The idea is the same as a tagged Git release: edit and test in the registry, then point production at a chosen version.

Langfuse

Langfuse manages prompt deployment with versions and labels. Each prompt version gets a version ID, and you can assign labels for environments (such as staging or production), tenants, or experiments. To deploy a version, you assign the production label, or another environment label you created. The default fetch in the SDKs serves the version labeled production. Langfuse documents a simple rollback: set the production label back to an earlier version. A missing label is an error, not a silent fallback, which helps you notice a misconfigured environment. Langfuse also provides a prompt diff view, and on higher plans it can protect labels so only admins and owners can change what "production" points to.

MLflow Prompt Registry

MLflow's Prompt Registry is documented as a way to version, track, and reuse prompts across LLM applications and AI agents. Versions are immutable and use Git-inspired, commit-based versioning with optional commit messages and side-by-side diffs. Aliases let you isolate prompt versions from application code and handle rollbacks or experiments without hard-coding a version number. You can load a prompt by name, or with an alias such as prompts:/summarization-prompt@latest. MLflow also ties the registry to its tracing and evaluation features, which matters if you want to know how a given prompt version behaved, not only what the text said.

Memory and agent state

Memory is often the least controlled part of an agent. If the agent writes facts, preferences, or retrieved documents into a store, a later change can alter answers even when the prompt did not change. There is no single standard product that every team must use, but there is a documented pattern in LangGraph, LangChain's agent orchestration library. LangGraph checkpoints save agent state as a run proceeds. Its time-travel documentation describes two operations: replay from a prior checkpoint, and fork from a prior checkpoint with modified state to explore an alternative path. The original history stays intact when you fork. That is version control for a conversation or workflow, not for a Git repo, and it is one of the more fully documented agent-native approaches.

If you do not use LangGraph, the same principle still applies: know what is in the memory store, take snapshots or exports when you change it, and do not let a new agent version write incompatible data into a shared store that an older version still has to read.

Versioning data and agent workspaces

Some agent work is not just code. A retrieval collection, a folder of documents, a training set, or a database can change the agent's answers. Git is a poor fit for large data files, which is why data-versioning tools exist. You only need these if agents or AI workflows actually depend on that data. For a typical WordPress site, they are usually more than you need.

lakeFS provides Git-like version control over a data lake: branches, immutable commits, merges, tags, reverts, and hooks. Importantly for this topic, lakeFS's own documentation now describes that control plane as a way to make data safer to hand to AI agents. It says you can give each agent an isolated, zero-copy branch, keep a human in the loop by gating changes behind pull requests before they reach production, and audit what each agent did. Initial branch creation is a metadata operation and does not duplicate the objects. If you already keep site backups, exports, or datasets in object storage, this is the closest analog to "a branch per agent task" for that data.

DVC (Data Version Control) sits beside Git rather than replacing it. You run dvc add on a dataset or model. DVC writes a small .dvc metadata file that Git can track, stores the actual data in a cache, and can push and pull that data from remote storage such as S3. To switch versions, you check out the matching .dvc file with Git, then run dvc checkout. DVC's getting-started guide calls this "Git for data," and it notes that DVC is designed for Git-based projects. For large data lakes and object storage at infrastructure scale, the same page points readers to lakeFS.

Dolt describes itself as Git for data, with a key difference: Git versions files, Dolt versions SQL tables. The command line uses familiar verbs such as init, add, commit, diff, branch, merge, revert, and push. If an agent is allowed to change business records in a database, a tool like Dolt can give you a commit history and a branch to review, instead of an in-place update that is hard to undo.

What a small team should do first

You do not need the full stack above to be safer than you are today. A practical starting point looks like this:

• Put agent work on a branch. One task, one branch, one pull request or equivalent review. Merge only after a person has looked at the diff.
• Use worktrees when two agents, or an agent and a person, need to work at the same time. Cursor and Claude Code both document first-party commands for this.
• Use the tool's checkpoint or undo feature for a bad turn in the current session. Then commit anything you intend to keep. Do not treat checkpoints as a backup. Cursor, Claude Code, and GitHub all document limits, including changes that undo will not restore.
• Keep agents off the live site. If the work involves WordPress, run it against a staging copy or a local repository, then deploy through your normal process. An agent that can edit files can also break a production site faster than a person can notice.
• If you maintain a custom prompt or agent, keep a versioned copy. That can start as a file in Git. If non-engineers will edit prompts, or you need a one-click rollback in production, a prompt registry such as LangSmith, PromptLayer, Langfuse, or MLflow is built for that job.
• Snapshot memory and data when they affect answers. If the agent learns from a document set or a database, version that input too, or at least keep dated exports you can restore.

If you are unsure which of those steps you actually need, that is a scoping question, not a shopping list. We can help you sort it on an AI Readiness Consultation.

How NTx can help

NTx works with small and mid-sized organizations that are adding AI to real workflows, including teams that already rely on us for WordPress. We can help you decide where an agent is allowed to work, how changes get reviewed, and what "rollback" means for your site, your repo, and any prompts you depend on. We will tell you what we see before we recommend a tool, and we will not introduce a registry or a data platform unless you have a use that justifies it.

FAQ

Is the undo or checkpoint button in Cursor, Claude Code, or Copilot enough?

It is enough for a quick rewind inside the current session, and it is not enough as your only backup. Cursor says checkpoints are local and separate from Git, and that restoring one reverts files only. Claude Code says checkpoints are for session-level recovery, do not track every Bash change, and may expire after about 30 days. GitHub's Copilot CLI rewind restores only files Copilot changed and skips some cases, such as files you edited afterward. Keep using Git for a reviewable, durable history.

Should every agent task get its own Git branch?

That is the simplest safe default. A branch per task means a bad run can be discarded without touching main, and a pull request gives someone a chance to read the diff. GitHub's Copilot cloud agent follows a similar pattern by creating a branch and a draft pull request and requesting a review. Worktrees are an extra isolation step when more than one agent needs to work in the same repository at once.

Do I need LangSmith, PromptLayer, Langfuse, or MLflow if I only use a coding assistant?

Not at first. If the agent is only editing code in a repository you already version with Git, a branch and a review are the main controls. Those prompt registries become useful when you maintain a custom prompt or agent that you change over time, especially if you want to roll back a production prompt without redeploying an app. You can also start by keeping the prompt in a Git-tracked file.

Can an AI agent work directly on my live WordPress site?

That is a poor place to start. Give the agent a staging copy or a repository checkout, review the changes, then deploy through your normal process. The same idea shows up in data tools: lakeFS, for example, documents isolated branches and pull-request review before agent changes reach production data. A live site has no useful undo if the agent edits the wrong template or deletes the wrong file.

What should we version besides the code?

Version the instructions and tools the agent uses (prompts, tool schemas, model settings), and version the data or memory that shapes its answers when those change. LangSmith, PromptLayer, Langfuse, and MLflow all document prompt versioning with history and a way to point production at a chosen version. For larger datasets, lakeFS, DVC, and Dolt offer Git-like history for data lakes, files, and SQL tables respectively.

Sources

1. Cursor, "Cursor Agent" (checkpoints are local and separate from Git). https://cursor.com/docs/agent/overview
2. Cursor, "Worktrees." https://cursor.com/docs/configuration/worktrees
3. Claude Code docs, "Checkpointing." https://code.claude.com/docs/en/checkpointing
4. Claude Code docs, "Run parallel sessions with worktrees." https://code.claude.com/docs/en/worktrees
5. GitHub Docs, "Using agent mode in your IDE." https://docs.github.com/en/copilot/how-tos/copilot-in-your-ide/use-copilot-agents/use-agent-mode
6. GitHub Docs, "Canceling operations and rolling back changes in GitHub Copilot CLI." https://docs.github.com/en/copilot/how-tos/copilot-cli/use-copilot-cli/roll-back-changes
7. GitHub Docs, "Delegating tasks to Copilot" (Copilot cloud agent creates a branch and a draft pull request). https://docs.github.com/en/copilot/how-tos/copilot-cli/use-copilot-cli/delegate-tasks-to-cca
8. LangSmith docs, "Manage prompts" (commits, environment tags, and rollback). https://docs.langchain.com/langsmith/manage-prompts
9. LangSmith docs, "Prompt & Context Hub." https://docs.langchain.com/langsmith/prompt-context-hub
10. PromptLayer docs, "Editor and Versioning." https://docs.promptlayer.com/features/prompt-registry/prompt-editor-versioning
11. PromptLayer docs, "Release Labels." https://docs.promptlayer.com/features/prompt-registry/release-labels
12. Langfuse docs, "Prompt Version Control." https://langfuse.com/docs/prompt-management/features/prompt-version-control
13. MLflow docs, "Prompt Registry." https://mlflow.org/docs/latest/genai/prompt-registry/
14. LangGraph docs, "Use time-travel." https://docs.langchain.com/oss/python/langgraph/use-time-travel
15. lakeFS documentation home (Git-like data versioning and isolated branches for AI agents). https://docs.lakefs.io/
16. DVC, "Get Started with DVC." https://dvc.org/doc/start
17. Dolt docs, "Git for Data." https://www.dolthub.com/docs/introduction/getting-started/git-for-data/