Grace is a version control system built around agents reviewing their own commits

What the project claims, and what it says about itself

The README opens by calling Grace a version control system designed and built for the AI Era, and the framing sentence that follows is that Grace is designed for kindness to humans, and velocity for agents, meant to help you stay calm, in-control and in-flow as you ship code at agentic speed. That is a product philosophy, and it is more informative than it might look. The name is expanded from four dictionary senses of grace, elegance and beauty of movement, a pleasing or charming quality, goodwill or favor, and a sense of propriety and consideration for others. What the project actually claims is the usual set of version control basics, plus primitives that help you monitor your agents, capture the work they are doing, and review that work in real time using both deterministic checks and AI prompts that you write, with rules that you set. The stated intent is that AI belongs inside the version control system, reacting to events, reviewing changes and generating what you need to get code from idea to agent to production. The scope also includes capturing work items, prompts, specifications and model versions, so that an agent has context to finish the work and a human can review it with confidence.

The agent bootstrap is the whole entry point

The onboarding story is a single command. All you have to do is tell your agents to run grace agent bootstrap at the start of the session, and Grace and your agents take care of the rest, automatically capturing what is going on. The bootstrap is customizable, and Grace will help you customize it, which is the detail that matters, because the command is where the capture behaviour is defined rather than something hard coded. In the repository you define the checks you want run in response to which events, you define the prompts, you choose the models, and Grace Server does the rest, capturing the results in detailed Review reports. The README says Grace will help you define and customise all of it. That is the architecture in three sentences: the repository is where the rules live, the server executes them, and the output is a review artefact. The related command for watching is grace watch, which pairs with SignalR for live client-server coordination, so the review of a change can be observed as it happens rather than polled for afterwards. The comparison with a conventional code review tool is instructive, since a conventional tool knows about diffs and reviewers, and this one knows about events, prompts and models.

F# and Orleans on Azure, with SignalR and Aspire around it

The technology stack is the clearest statement of what this system is. Grace is written primarily in F# and uses ASP.NET Core for the HTTP API and Orleans for the virtual-actor and distributed-systems core, and it is a modern, fast, powerful centralized version control system made up of a web API with a CLI and, soon, a GUI. The storage story is Azure PaaS services: Azure Cosmos DB for actor state storage covering repos, branches, references and directory versions at what the README calls ludicrous scale and speed, Azure Blob Storage for objects and artifacts including virtually unlimited-size binary files, and Azure Service Bus for event streams you can hook into, and all of these come with emulators for frictionless local development. SignalR handles live client-server coordination, Redis is used by SignalR and for caching, Aspire orchestrates everything for both local dev and cloud deployment, and Avalonia is listed for a fully cross-platform GUI including WASM, with the author's own parenthetical I think attached to it, which is a fair signal of how settled that part is. The footnote under the Azure list is honest in the same way, saying that Grace is designed to be adaptable to AWS and other cloud providers and with coding agents it should be not easy but not too hard to do, and that the author has not done it yet. So the Azure coupling is design, not accident, but it is also not yet proven elsewhere.

Libraries: shared files outside the Save and Reference history

The Library feature is the part of the README that is hardest to parse and the most distinctive thing in the system. Libraries share ordinary nonempty files between authorized Windows working copies outside Save and Reference history. A fresh copy can join a populated Library from an empty local root, install selected content and catch up with later changes using grace library sync enable. The commands are given as a small CLI vocabulary. grace library add <path> and grace library remove <path> change the configured Library roots, and the CLI obtains the current catalog version and creates an operation ID unless you supply explicit values for a controlled request or an exact retry. grace library rename <path> <new-name> renames one clean synchronized nonempty file within its existing parent, and the command retains its generated request across retry and reports local completion only after the accepted changes have been applied in order. grace library sync pause stops Library capture and transfer for one onboarded copy while retaining its saved work, and grace library sync resume continues synchronization, with status reporting pause separately from participation and progress. The ordering guarantees and the operation ID are what make this a distributed protocol rather than a file copy, and the Windows specificity in the description is worth noting for anyone planning a rollout on other platforms.

Configuration is environment driven, and the sample file shows the whole surface

The .env.example file is the most informative document in the repository after the README, because it enumerates every service the server expects. The top of it sets the server URI and a token, with a token file alternative, and the rest follows the stack: Aspire resource mode, telemetry, a block of OIDC settings for the authority, audience, CLI client and redirect port, the CLI scopes and a machine to machine client, and personal access token defaults including a default lifetime and a maximum lifetime in days. Then the storage blocks, with Azure Storage connection string, account name, endpoint suffix and key, and separate container names for directory versions, diffs and zip files, and an Azure Cosmos DB block with connection string, endpoint, database name and container name, and an Azure Service Bus block with connection string, namespace, topic and subscription. Redis comes next with host, port, TLS flag, username, password and a CA certificate, then the Orleans cluster and service identifiers, the pub/sub system defaulting to AzureServiceBus, and finally the log directory and a debug environment setting.

GRACE_SERVER_URI=http://localhost:5000
GRACE_TOKEN=changeme
GRACE_TOKEN_FILE=

GRACE_TESTING=0
GRACE_TEST_CLEANUP=1

ASPIRE_RESOURCE_MODE=Local

The structure is a two-level configuration convention, with the grace__ prefix and double underscore characters separating sections, and the same pattern covers the OIDC, PAT, Azure Storage, Cosmos DB, Service Bus and Redis settings. Note that the telemetry line and the OIDC and storage lines are commented out, which tells you the local default is meant to run without cloud credentials.

Promotions, not merges, and an alpha warning

Two design choices in the README are worth pulling out because they say what the project thinks a version control system is for. The first is that Grace ships with a promotion queue, and it does not do merges, it does promotions, and it automatically handles promotion conflict resolution according to rules and confidence levels you set. That is a real conceptual difference from the merge model, and it follows from the agent premise, since a merge is a human reviewing another human's diff, while a promotion is a decision about whether work that a machine produced is ready to move. The second is the scale claim, that Grace is multitenant, built for massive repositories, insane numbers of developers and agents, and ludicrous amounts of code and binary files of any size. And then the warning, which is the sentence that should govern any evaluation. Grace is an alpha, and is going through rapid evolution with breaking changes, but it's ready for feedback and contributions, and it is not ready for or intended for production usage at this time. That is unusually direct, and it is the correct thing to plan around. The repository also carries an unusual amount of process documentation for an alpha, with AGENTS.md, CONTEXT.md, a code of conduct, SECURITY.md, a .codex/ directory, a .testagent/ directory, skills/, prompts/, test-vectors/, an artifacts/ directory and a _endpoint_stub.txt, and the development process is described as task-record-first to keep human and agent work reviewable.

Editorial conclusion

Grace suits a team experimenting with agentic coding who wants the agent's work to be captured and reviewed inside the repository rather than reconstructed from chat logs, since the bootstrap command and the event driven review pipeline are the point of the project. It is the wrong tool for production use today, because the README says plainly that it is an alpha, is going through rapid evolution with breaking changes, and is not ready for or intended for production usage at this time. It is also the wrong tool if you want a decentralized or offline-first system, because the design is a centralized server backed by Azure Cosmos DB and Blob Storage, and a hosted alternative needs its own evaluation. Before you try it, read the AGENTS.md files in the repository, since the documented development process is built around them, and treat the Azure dependency as fixed rather than portable, since the author says in a footnote that adapting Grace to AWS is doable but has not been done.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. ScottArbeit/Grace on GitHub