Org context for AI agents: why raw GitHub data isn't enough

An AI agent is only as good as its context. Point one at your codebase and the first thing it needs is the thing your tools don’t hand it: an understanding of the organization — who owns what, what depends on what, who reviews what. Raw GitHub data and RAG-over-repo both fall short, in different ways.

Two ways to give an agent context — both incomplete

Most teams reach for one of two approaches, and both leave the agent guessing.

The GitHub API gives you events, not context. REST and GraphQL return commits, pull requests, and files. To turn that into “who owns services/auth” the agent has to fetch history, blame files, weight recency, and reconstruct the review graph — per request, against a rate limit. It’s a lot of work to produce an answer that’s stale the moment it’s computed.

RAG-over-repo gives you text, not the org. Chunk-and-embed retrieval is great at “find code that looks like X.” It has no idea that Alex owns the module, that changing it ripples into three services, or that the last two PRs touching it were reverted. Embeddings model the text of your code; they don’t model the organization around it.

What an agent actually needs to ask

The useful questions are relational, and they’re the ones neither approach answers cleanly:

• ›Who should review this change, and who’s the backup if they’re out?
• ›What’s the blast radius if I touch lib/db?
• ›Who knows the payments flow — and is that knowledge concentrated in one person?
• ›What’s moving in this repo right now, and what keeps getting reverted?

A GitHub Org Context API pre-computes exactly these relationships and serves them as cited JSON — ownership, dependency & coupling graph, contributor expertise, the review graph, semantic search with citations, and activity hotspots. The agent asks once and gets an answer grounded in real history.

# Not "find similar code" — "who owns this, with evidence"
curl "https://eos.dev/api/v1/context/ownership?repo=acme/app&path=services/auth" \
  -H "Authorization: Bearer eos_your_key"

Why building it in-house is a trap

Every team that wires an agent to their codebase ends up building a slice of this: an ingestion pipeline, a blame/ownership model, a dependency graph, a freshness story, rate-limit handling, multi-repo scoping. It’s real work, it’s never quite finished, and it’s undifferentiated — the same layer, rebuilt privately, at every company. Meanwhile the raw signals drift and the graph rots unless someone owns keeping it fresh.

For agent builders specifically

If you’re building a multi-tenant AI dev tool, org context is a backend you’d otherwise have to operate for every customer. A context API gives you org-scoped, permissioned access per workspace, semantic retrieval with citations for grounding, and change webhooks to keep your index fresh — without you running the ingestion. It sits underneath your agent, not next to it.

And it complements the assistants your users already run. Claude, Cursor, and Copilot generate; the context layer tells them about the org. They’re customers of the same primitive, not competitors for it.

Start with real context

The free tier is 5,000 context requests a month, no credit card — enough to wire an agent to your org and see the difference grounded answers make. Drop in the MCP server or the SDK and make your first call.