github for agents

Every repo I touch now has its own .claude folder. Skills, commands, settings, a CLAUDE.md telling the agent how to behave inside this specific context. It works great per-repo. The problem starts when you have a personal life, a team, multiple projects, and you want one thing you talk to.

I have a tasks repo where the team coordinates. Source code in another. A personal-branding hub that runs my content. RapidNative source. The geekyants stuff. Each has its own agent setup. Each is a separate front door. Switching between them is a context switch I make a dozen times a day.

The vision in my head: one entry point. I drop a thought, the right thing happens. Without me having to remember which repo I'm in, which agent has the skill, which credentials it needs.

everything is a graph

The deeper I look at this, the more it seems like everything is a graph. Tasks are nodes. People are nodes. Projects are nodes. Edges describe assignment, parent, references, blocks, mentions.

Tasks especially. Some are deeply personal ("remind me to call mom"). Some belong to a project shared with my team ("fix the rapidnative auth bug"). Some are links to external people ("send pratik the design link"). Localising tasks per-user is fundamentally hard because tasks bleed.

Existing tools each force a schema:

• Linear is shaped for product teams. Issues, projects, cycles.
• Notion is shaped for hierarchical wikis with optional relations.
• Asana, Monday for ops.
• Todoist, Things for single-user lists.
• Jira for enterprise dev.

Each is opinionated for its slice. Real life doesn't fit one slice. And bridging them via MCP-per-app (Linear MCP + Notion MCP + Todoist MCP) is weird. Each MCP exposes a different schema. The agent spends its life translating. You pay the schema-mismatch tax on every interaction.

the model: github for agents

The right shape, in my head, is something like github but for agents.

• identity = github username. One global @handle per human, lives forever, cross-org.
• space = github user/org. Owned by a person OR a company.
• workspace = github repo. A scoped context with its own graph, skills, members, scoped credentials, files, MCP endpoint.
• membership = repo collaborator. Personal @ invited into an org's workspaces, with per-workspace roles.
• MCP gateway = github API. Workspaces expose themselves; permitted agents read and write across boundaries.
• discovery = github trending + marketplace. Public skills, follow workspaces.

Concretely: @sanketsahu owns /branding + /life as private spaces. @rapidnative invites me as admin and I get permission to /product, /growth, /support. @geekyants invites me and @pratik. One local runtime authenticated as @sanketsahu syncs ALL my memberships. One entry point, scoped views.

"Send pratik the design link" becomes a node in @rapidnative/product, both of us see it. "Remind me to call mom" is a node in @sanketsahu/life, only I see it. "What's on my plate today" is one query across all my workspaces, permissions filter the result.

why this isn't notion or linear

Notion has separate accounts per workspace. Identity isn't global. Linear is opinionated for product teams; it doesn't model my personal todos. Asana isn't agents-first.

The differences that matter:

• Identity is global, not per-tool.
• Workspaces are agents-first (skills + MCP are first-class, not docs).
• Personal and org spaces share one namespace.
• Local runtime owns YOUR identity and credentials (no SaaS holds your chrome cookies).
• Cross-workspace queries are native.

why now

Two things have historically blocked this:

1. Graph UIs confuse normal users. People want lists, not nodes.
2. Nobody migrates off Linear or Jira voluntarily.

Both just dropped:

1. LLMs generate opinionated views on the fly. You don't show users the graph; you show whatever shape they want for THIS query.
2. Agents handle bidirectional sync gracefully. You don't migrate. The graph mirrors Linear AND Notion AND your todo, and the apps become disposable lenses you can keep using.

local + cloud

The runtime splits cleanly along an identity boundary.

Local layer (per person): agent process on your machine. Your chrome profile, ssh keys, files, real sessions. Browser-use, system access. Routes incoming events. Syncs the workspaces you belong to.

Cloud layer (shared): identity + auth. Workspace graphs in postgres. Member directory + permissions. MCP gateway + event bus. Billing, audit log, public discovery.

Rule of thumb: anything requiring YOUR identity, sessions, or secrets stays local. Anything collaborative becomes a node in the shared graph. You never sync browser cookies to a teammate. You DO sync "i replied to thdxr's tweet" as a task-completion node.

open questions

Things I haven't figured out yet:

1. Graph schema: fixed minimum (id, type, owner, perms, ts) + arbitrary properties, or fully dynamic?
2. Permission granularity: workspace-level or per-node? Per-node is more powerful, way more complex.
3. Forking and PRs: can you fork @rapidnative/product into @sanketsahu/rn-experiments, prototype, and PR back? This is where the github metaphor really earns its keep.
4. Sync conflicts: two local agents writing to the same shared node simultaneously. CRDTs, last-write-wins, or optimistic lock?
5. Credentials boundary: workspace-scoped credentials live local (encrypted) or cloud (hosted secrets)? Probably split: tokens in cloud, browser cookies and ssh keys local-only.
6. Guest access: external @customer gets scoped read on a workspace without joining the full org. How? Per-workspace guest invite with TTL?
7. The actual front door: slack-channel-per-workspace, one channel + routing, desktop app with switcher, or CLI? Probably "all eventually" but you ship one first.

what i'm not doing

Not building this. At least not yet. The temptation is to start coding the graph layer this weekend. The smart sequence is the opposite: build the simplest version that works for ONE person + ONE other person + ONE shared project. Watch where the friction accumulates over 4-6 weeks. Then automate THAT, not the imagined pain.

The agent infra folks fall into this trap constantly. Six months of plumbing for workflows that don't exist yet. When they finally have data, the plumbing is shaped wrong.

For now: writing it down, putting it out there, and seeing if it survives a few weeks of thinking about it.