Arras

Arras is GitHub for AI agents: a governed shared workspace where concurrent agent changes are isolated, proven, challenged, and human-approved before they become canonical.

Comment

Arras

Arras is GitHub for AI agents: a governed shared workspace where concurrent agent changes are isolated, proven, challenged, and human-approved before they become canonical.

GitHub versions files and coordinates human contributions. Arras versions shared reality and coordinates machine work.

Inspiration

I built Arras because I ran into the problem myself while working with multiple AI agents at once.

Parallel agents are enormously useful. One can harden a security boundary while another repairs a workflow, investigates a failure, or tests an assumption. But they can also quietly create a coordination problem: one agent changes the ground beneath another while it is still working. An agent can make a perfectly reasonable change against an out-of-date read; another can alter a dependency halfway through; and by the time the work reaches a repository, the diffs do not fully explain whether that work still belongs to the shared state that was accepted.

I was seeing the same questions appear everywhere around agentic coding: how do we coordinate agents, review their work, preserve provenance, and keep a human in control without simply slowing the agents down?

I did not want to build another dashboard that shows agents talking to each other. I wanted to build the missing shared-work layer: a system where agents can work in parallel, where their work remains isolated until its evidence and dependencies are understood, and where a person—not an automated race between models—decides what becomes shared.

This is not only a problem in my own workflow. GitHub has described its traffic as growing rapidly, driven in large part by AI-assisted and agentic development, and is already transforming its infrastructure to keep up. As agents become concurrent contributors rather than occasional assistants, the bottleneck moves beyond generating code. Teams need a way to preserve dependencies, provenance, review, and human authority while the shared project is changing. Arras is built for that coordination problem.

That became Arras.

What it does

Arras replaces the repository-first mental model with a governed realm: a shared world containing versioned components, dependencies, evidence, challenges, and authority-bound decisions.

The core loop is:

  1. An agent begins an isolated attempt from a known realm version.
  2. Its reads, writes, candidate changes, and validation results are recorded as evidence.
  3. If another accepted change invalidates what the attempt relied on, Arras marks the attempt stale instead of quietly letting it publish against an outdated world.
  4. The agent can reorient on the current shared state, rebuild, and publish a new candidate.
  5. Another actor can open a durable challenge against the evidence.
  6. Only a separately authorized human decision can accept the eligible transition into the canonical realm.

Arras is not an agent orchestration dashboard. Those tools coordinate agents. Arras governs the work itself.

It is also not GitHub with bots bolted onto it. GitHub can remain an import or export projection, but it is not the canonical store. In Arras, files and diffs are useful human views over a more complete record of what changed, what it depended on, what was checked, who challenged it, and who accepted it.

GitHub Arras
Repository Realm
Files and folders Governed components and projections
Commit history Realm versions and accepted transitions
Pull request Attempt
Code diff Projected transition
Review discussion Challenge and resolution
Verified commit Verified transition

The demo

The live demo follows one coordinated team transition.

A Security role, run by Codex inside a contained runner, changes a shared authentication interface and advances the realm from version 417 to 418. Meanwhile, a Recovery role is still working from the old version. Arras catches that stale dependency while the work is in progress and requires the recovery attempt to reorient.

Recovery rereads the accepted interface, rebuilds its candidate, and validates it against the new shared state. A QA role, run by Claude as a control-plane reviewer, opens a durable challenge against the recovery evidence. An independent operator resolves that challenge, reviews the proposed transition, and accepts it. The realm advances from version 418 to 419.

The point is not to stage a contest between models. It is to show agents adapting to the same changing project, with evidence and human authority preserved all the way through.

Arras has both a Plain view for understanding the work and a Technical view for inspecting the underlying receipts, hashes, evidence, and authority records.

How I built it

I directed the product, trust model, and demo story; Codex with GPT-5.6 built the system from that specification.

The implementation is TypeScript and Node.js with no third-party runtime dependencies. At its core is a deterministic state substrate that records realm versions, snapshots, isolated attempts, exact read sets, invalidations, validation receipts, reconciliation receipts, and canonical transitions.

Content is stored and verified by hash. Append-only SQLite logs preserve evidence, accepted operations, authority receipts, enrolled identities, and adversarial challenges. Gateway operations are authorized with realm-scoped Ed25519 grants and signed requests. A contained Node reference runner produces a signed environment receipt that binds the agent, attempt, policy, base state, and final workspace manifest.

I built Arras with Codex running GPT-5.6 across three complementary working roles: Sol for architecture, integration, and adversarial verification; Terra for bounded implementation work; and Luna for scouting, research, and evidence gathering. Codex was not only the builder. Codex also runs inside the governed harness Arras is designed to provide: projected workspace, observed work, bounded execution, signed receipt, challengeable output, and no self-acceptance. The build method became part of the product demonstration.

The project currently verifies with 81 automated tests, including stale-read detection, replay, challenge blocking, authorization boundaries, Unicode-safe read anchoring, append-only persistence, and the live Hub acceptance flow.

Challenges I faced

The architecture design was one of the hardest parts because I am not a coder by nature, this system was more complex than most I have built.

It is easy to make an agent interface look trustworthy with green check marks, hashes, and shiny activity cards. That is not the same as proving what happened. Arras distinguishes an observed action from proof of model comprehension, an environment receipt from a claim of complete containment, and a validated candidate from a human-approved canonical change.

That discipline shaped how I developed Arras. Network enforcement in the current contained demo is explicitly recorded as uncontrolled; local hash-linked history is not described as externally witnessed; and authority is always separate from identity or session health.

Another challenge was making the system understandable. The underlying architecture is dense, but the product cannot require every user to think in kernel vocabulary before they can see what changed. The Plain and Technical views therefore present the same facts at different levels of detail rather than maintaining two different truths.

What I learned

I learned that the difficult problem in agentic development is not just generating code. It is preserving the relationship between work, evidence, dependencies, authority, and shared state as the number of agents increases.

I also learned that “parallel” does not have to mean chaotic. Agents can move quickly without being turned into a competition, as long as the system knows what they read, what changed beneath them, what evidence supports their proposal, and who has authority to accept it.

Arras is the beginning of that infrastructure: a shared realm for agent work that can remain inspectable, challengeable, and human-governed as development becomes increasingly agent-native.

What’s next

The next step for Arras is a hosted realm network connecting Hubs, realm nodes, and governed execution cells. Teams should not need to abandon their existing workflows to begin: GitHub can remain an import, mirror, or export projection while Arras governs the agent-native work underneath it. Over time, materializing a realm can become the stronger successor to cloning a repository: not only the files, but the accepted state, dependencies, provenance, evidence, and authority history required to continue the work.

I directed, specified, and shipped Arras as a non-coder orchestrating a fleet of AI agents—and became the first user of the system I was building.

Built With

Share this project:

Updates