Tangled could become GitHub for agents

Software agents need a place to work.

Not just a chat box. Not just a filesystem on a rented VM. They need durable project spaces where they can create code, track issues, review changes, coordinate with other agents, preserve context, and expose the right parts of their work to humans.

That sounds like GitHub, but GitHub is not built for agents. It is built around human accounts, human organizations, public and private repositories, pull requests, issues, CI, and social discovery. Agents can use it, but only by pretending to be developers inside a human-centered forge.

A better substrate would look different. It would be identity-native, protocol-native, easy to automate, and able to host millions of small repos without assuming every repo is a long-lived human project. It would make public work discoverable, private work protected, and agent work portable.

Tangled is the closest thing I have seen to that shape.

Tangled has the right public skeleton

Tangled is a decentralized code forge built on ATProto. The simple version is:

• Git moves code.
• ATProto moves social and collaboration metadata.
• Knots host repositories.
• The Tangled appview indexes and renders the network.
• Spindles run CI.

That separation matters. Git remains Git. The collaboration layer becomes protocol data.

Tangled already has lexicons for repositories, issues, pull requests, comments, CI status, collaborators, stars, labels, and related forge objects. It already treats repository events as part of a broader social network. It already fits the Atmosphere better than a centralized forge does.

This is why Tangled is interesting for agents. An agent should not need a GitHub account controlled by a company silo to participate in software work. It should be able to have an ATProto identity, publish work under that identity, collaborate with other agents and humans, and carry reputation across applications.

Public agent projects fit Tangled almost immediately. An agent can create a repo, push code, open issues, receive feedback, and publish updates into the same network where its identity already lives.

But public work is not enough.

Agent work needs private spaces

Most useful agent work starts private.

Agents need scratch repos. They need half-formed migrations. They need private analysis. They need test outputs, notes, plans, credentials-adjacent configuration, customer-specific context, and repo state that should not be broadcast to the world.

Today, Tangled is explicitly public. Its repo creation UI says all repositories are publicly accessible. That is fine for an early public forge, but it blocks the stronger agent story. A GitHub for agents needs private collaboration as a first-class primitive.

This is where ATProto permissioned data changes the picture.

Daniel Holmgren's Permissioned Data Diary 4 sketches a much more concrete design than the older roadmap language: https://dholms.leaflet.pub/3mhj6bcqats2o

The core abstraction is the permission space.

A permission space is an authorization and sync boundary for permissioned records representing a shared context. It has a space owner DID, a space type NSID, a member list, short-lived space credentials, and pull-based sync. Each user has a permissioned repo within each space they participate in.

Ignore the naming collision for a moment. A permissioned repo in Daniel's post is not a Git repository. It is an ATProto record store scoped to a permission space.

But that is exactly the private metadata layer a forge needs.

A private Tangled repo could be a permission space

Imagine a Tangled private repository as a space.

The space owner could be a repo DID or an organization DID. The space type could be something like sh.tangled.privateRepo. The space key would identify the repo. The member list would be the collaborator list. Records inside the space would include issues, pull requests, comments, review state, CI metadata, labels, project notes, and agent-specific coordination data.

The result is a protocol-native private collaboration layer.

Instead of storing private repo metadata in a centralized database owned by one forge, Tangled could store it as permissioned ATProto data. Instead of every application inventing a private access model, apps would use space credentials and member lists. Instead of treating agent collaboration as an API bolt-on, agent work would become typed network data.

This is the part that makes the case compelling.

Tangled already has the public forge model. Permissioned data gives it a plausible private forge model.

Git contents still need real privacy

Permissioned data does not automatically make Git private.

Tangled would still need knot-level read authorization. Private Git hosting means authenticated clone and fetch, ACL checks around git-upload-pack, archive, blob, tree, and raw file routes, private search indexing, private fork semantics, and CI access that respects the same permission boundary.

This is not trivial. It is also not mysterious. Git hosting platforms already do this. The difference is that Tangled could derive the authorization model from protocol-level spaces rather than a forge-local account database.

That would make the split clean:

• Git stores code.
• Permission spaces govern who can see and collaborate around the repo.
• Tangled renders the forge experience.
• Agents and humans use the same protocol objects.

For high-sensitivity data, users may still want client-side encryption. Daniel's proposal is not end-to-end encrypted. The PDS and space hosts can see the private data they host. That is acceptable for many collaboration workflows, but it is not a zero-knowledge system.

Still, it is a major improvement over everything being public by design.

Why this matters for agents specifically

Agents are going to create a lot of software artifacts.

Not all of those artifacts deserve a full GitHub repo with a human-maintained project lifecycle. Many will be small, temporary, experimental, or scoped to a single task. Some will be internal memory for long-running agents. Some will be shared workspaces between a manager agent and many execution agents. Some will become real projects.

A centralized forge can host this, but it will treat the agent swarm as an abusive edge case. Millions of tiny repos, high automation rates, non-human identities, and cross-application agent workflows are not the center of gravity for GitHub.

In ATProto, that workload feels less alien.

The identity model already supports portable identities. The data model already supports typed records. The network already assumes multiple appviews and services. The permissioned data proposal explicitly targets spaces ranging from personal data to million-person groups.

That range matters. Agent workspaces are often small, but agent ecosystems could be enormous.

The product shape

A real GitHub for agents on Tangled would need a few things.

First, private repos backed by permission spaces. Repo metadata, issues, PRs, comments, and CI state should live inside a space when the repo is private.

Second, private Git reads enforced by knots. The knot should verify a space credential or equivalent authorization before serving clone, fetch, archive, blob, and tree requests.

Third, an agent-friendly SDK. Agents should not need to manually orchestrate service auth, PDS writes, Git remotes, and record creation. They need simple operations: create repo, write files, commit, push, open issue, open PR, read comments, list tasks.

Fourth, scale testing. Tangled's architecture is promising because knots shard hosting naturally, but the current public network is still small. Agent workloads need benchmarks around repo creation, fetch, indexing, permission checks, and search.

Fifth, a clear privacy story. Public, permissioned, and encrypted should be separate modes. Do not blur them.

The case

The case for Tangled as GitHub for agents is not that Tangled is ready today. It is not.

The case is that Tangled and ATProto are solving adjacent halves of the right problem.

Tangled asks what a code forge looks like when Git hosting is decentralized and collaboration metadata is protocol data.

Permissioned data asks how ATProto can support private shared contexts without forcing everything through the public repo and firehose model.

Agents need exactly the combination of those ideas: portable identity, typed collaboration records, private workspaces, Git-native code, automation-friendly APIs, and a social surface where work can become public when it is ready.

GitHub for agents should not just be GitHub with bot accounts.

It should be a protocol-native forge where agents can own work, share context, collaborate privately, publish publicly, and carry identity across the network.

Tangled is not there yet. Permissioned data is not shipped yet. Private Git on knots is not solved yet.

But the architecture is pointing in the right direction.