Has this ever happened to you? You pick up what looks like a straightforward coding task: update an API, run the tests, open the PR, and move on. Then, a few nights later, you’re paged for an incident tied to that change. The update worked exactly as expected in your service, but it silently broke a dozen downstream consumers you didn’t know existed.
You even asked your coding agent to verify that the change wouldn’t break anything, and it did – within the boundaries of the repository. That’s the problem. A repository can show an agent what an endpoint calls, but it rarely reveals the full dependency graph: who calls that endpoint, which consumers rely on an undocumented field or side effect, whether those consumers are still active in production, where they’re deployed, or which team owns the pager when they fail. The coding agent we used accurately reasoned about the systems that it could see, but it just didn’t have enough operational context to understand the true blast radius. If we had a complete view of those downstream dependencies, we could have identified all of the affected consumers, coordinated the necessary updates, and avoided the incident altogether.
This is why we’re launching the Context Graph API: a private, authenticated knowledge graph that gives agents a machine-readable model of your entire API ecosystem.
It connects services, endpoints, schemas, consumers, owners, deployments, environments, telemetry, and runtime call relationships in a single traversable graph. You connect the systems where this knowledge already lives, and the graph resolves those fragmented signals into entities and relationships your model can query at inference time.
That changes what an agent can do. Instead of reasoning from the repository alone, it can inspect the broader system, trace upstream and downstream dependencies, distinguish declared architecture from observed runtime behavior, and calculate the likely blast radius before it writes a line of code.
In other words, the agent can finally answer the question every senior engineer asks before touching a critical API:
If we change this, what breaks?
Bring your own model #
If you’re like me, you’re probably thinking: How much of my existing stack do I have to replace to use the context graph API? The answer is none.
The Context Graph API is designed to fit into the stack you already have. You connect your existing sources once through the Postman UI. The context graph ingests the data, resolves entities across those systems, and builds the relationships that turn a collection of disconnected records into a queryable graph. After that, the graph refreshes nightly as your API ecosystem changes. So now, every time a new service appears, or a deployment moves to another environment, or ownership shifts to a different team, the graph picks up those updates on its next refresh, giving every agent an up-to-date view of your API ecosystem.
Without a shared context layer, every one of those changes makes the agent’s understanding of the system a little more stale. Before long, it’s reasoning about the architecture you had six months ago, not the one currently running in production.
The Context Graph keeps that operational picture up to date without asking you to change how your team works. You don’t need to move to a new IDE, adopt our coding agent, or rewrite the agent you already built. The API fits into the model you already use. It’s not another place for developers to work. It is a shared context layer for the systems already doing the work.
One endpoint, one question #
Using the API is simple. You don’t need to learn a new query language or orchestrate a dozen endpoints. You send one question to /asks.
For example, if we want to understand the blast radius of changing a shared SDK, we can ask: Which repositories in this organization depend on the shared backend SDK module?
The API is asynchronous, which makes sense once you consider what it may need to do. Traversing relationships across several hundred repositories, services, deployments, and runtime signals isn’t the kind of work you want to perform while holding an HTTP connection open.
The initial POST returns a 202 Accepted response with a job ID and status:
{ "id": "abc-12345678", "status": "pending" }
Then poll the same path until the status leaves pending, queued, running, or in_progress:
Once the job reaches completed, the response includes a written answer and the structured data behind it. The agent can use the answer directly or inspect the individual results before deciding what code needs to change.
In our benchmark against an organization with several hundred repositories, most queries completed in roughly 20 to 40 seconds. We’d make this call once at the beginning of the task, add the results to the agent’s context, and then let it plan the implementation with a better picture of the system.
This is the important difference: we don’t need to know the full scope before we ask. If we already knew every affected repository, service, and team, we wouldn’t need the Context Graph in the first place. We only need to identify the thing we’re changing—the endpoint, schema, service, or shared module. The graph discovers the scope around it.
It can also return repositories that aren’t checked out locally because it queries an organization-wide index, not just the current workspace. That is exactly the context the coding agent was missing in the original incident.
The result is a small but important change to the workflow. Instead of asking the agent to update the code and hoping the repository contains enough context, we first ask the graph what the change touches. Then the agent can plan against the actual dependency graph—not just the code it happens to have open.
Up to 74% fewer tokens, 52% fewer tool calls, and 72% lower cost #
We wanted to know whether giving the agent that extra context would make a measurable difference, or whether it would just add another API call.
So we built a controlled benchmark. We gave three frontier models access to an estate of 468 repositories and asked each of them eight questions:
- What are the runtime dependencies between services?
- List each service and the logs, metrics, and traces it produces.
- Which services do we actually deploy, and how is each one deployed?
- Which services serve HTTP endpoints, and what paths does each one serve?
- Which services consume from a message bus, and which topics do they read?
- Which services call the platform’s HTTP API?
- Which services declare a machine-readable data or API contract?
- What does each service depend on at run time?
These are exactly the kinds of questions we’d want answered before changing shared infrastructure.
For the baseline, the model received the code and a set of read-only search tools. It had to search the repositories and reconstruct the relationships on its own. It was not even told the Context Graph exists.
Then we ran the same benchmark with the Context Graph API. Same models, same questions, same repositories, same tools, same pinned commit, same temperature. The only difference was that the harness made a single query to the graph first and added the response to the prompt.
The model still had to inspect the code and prove its answer. It just started with a map instead of searching 468 repositories from scratch. By the time ingestion finished, that map held 6,712 nodes: 4,828 endpoints, 1,424 APIs and services, 309 external systems, 139 database schemas, and 11 telemetry configurations.
We ran every question three times in both configurations, 144 cells in all. What we wanted to isolate was simple: does better context help the model work more efficiently without lowering the standard for a correct answer?
To keep ourselves honest, we added three guardrails.
The graph provided a lead, not the answer.
We treated the candidate list the same way we’d treat a tip from another engineer: useful, but unverified. The agent still had to open the repositories, inspect the code, and cite real files.
We checked whether it found the known dependencies, cited at least three paths that existed at the pinned commit, and invented more than 20% of its citations. We also penalized false positives, so the graph couldn’t boost its recall by simply returning every repository in the organization.
The graph stayed on the clock.
We counted the full latency of every /ask request, including retries when the first response was empty. A graph query typically added 20 to 45 seconds. If the graph had no useful context for a question, the graph-assisted run still paid that cost.
The model couldn’t grade its own homework.
Letting a model judge its own answer would be like letting an engineer approve their own PR: it could miss the same problems twice. We built the answer keys from real call sites and go.mod files, verified every citation against the pinned commit, and had a separate model compare anonymized answers. That way, the score reflected what was actually in the code, not how convincing the response sounded.
One caveat: this wasn’t a perfect apples-to-apples comparison. The baseline searched an exact version of the code, while the Context Graph searched a broader organization-wide index that could be slightly newer or older.
So we’re not saying the graph will always win. The result shows that giving an agent a map of likely dependencies, and then having it verify them in the code, can save a lot of searching and reduce the chance of missing something important. That’s the real benefit. The model spends less time trying to discover the blast radius and more time making sure the change won’t create the incident that started this story.
But saving time and tokens is only useful if the model still finds the right answer. So after measuring the reduction in search effort, we looked at whether the graph helped each model find more of the real dependencies without introducing more wrong ones.
Fewer tokens would be worth little if the answers got worse, so here is what happened to accuracy. Across three models and seven scored prompts, the Context Graph API improved it in 18 of the 21 prompt-model pairs.
Take runtime call relationships, the question sitting behind most bad incidents. When one service calls another at run time, neither repository records it, because the target is a URL assembled from configuration at startup. There is no string to grep for. Here is what Opus and Astra did on that one question:
| Run | Model | Prompt tokens | Cost | Tool calls | Accuracy |
|---|---|---|---|---|---|
1 |
Opus 4.7 | 0.61M → 0.31M ( −49% ) | $10 → $5 ( −45% ) | 39 → 26 ( −33% ) | 0.136 → 0.243 |
2 |
GPT-6 Astra | 1.44M → 0.90M ( −38% ) | $15 → $10 ( −37% ) | 152 → 97 ( −36% ) | 0.168 → 0.194 |
Opus went from 5 correct services to 15, and Astra from 10 to 20, both while spending less to get there.
That brings us back to the original API change. If the agent starts with 468 repositories, it has to discover the relationships one search at a time. If it starts with a short list of likely consumers, it can move directly to verification. Every step it skips saves time and tokens.
The question grep cannot answer #
The findings above show that the Context Graph cut the tokens, tool calls, and cost of getting an answer, and improved the answer itself. But one prompt made it clear why.
Which services call the platform’s HTTP API?
If we ask which repositories import a library, the answer is usually written down somewhere. In Go, we can inspect go.mod. In other ecosystems, we’d look at package.json, pom.xml, or requirements.txt. The filename changes, but the basic problem is easy: parse the dependency manifests and follow the declared edges.
Runtime API calls are different. There is no organization-wide file listing every service that calls an endpoint. Those relationships are spread across application code, generated clients, configuration, service discovery, gateways, and live traffic.
In the estate we tested, 13 services genuinely called the API. We verified each one by hand. Several used generated client libraries, so the literal /api/... path never appeared in their source code. You can’t grep for a string that isn’t there. The agent can search harder and read more files, but the missing relationship still won’t appear in the repository. This is also the question API owners end up answering manually, usually in Slack, under time pressure, right before a breaking change ships.
We gave each model the same prompt and code, then ran it three times with repository tools alone and three times with the context graph queried first.
| Model | Callers found of 13 | Accuracy |
|---|---|---|
| Opus 4.7 | 9 → 12 | 0.777 → 0.943 |
| Sonnet 4.5 | 3.7 → 8.3 | 0.439 → 0.773 |
| GPT-6 Astra | 10.7 → 11.7 | 0.864 → 0.909 |
Every model improved with the Context Graph API. Sonnet more than doubled the number of real callers it found, while Opus reached 12 of 13 and Astra improved even though it was already close to the full answer. The graph gave each model a stronger place to start, helping it find more of the services that actually call the API without padding the answer with as many guesses.
You can’t reason your way to a fact you don’t have #
Let’s go back to the example at the beginning of this blog. Say you rename an API field. The implementation is correct, the tests pass, and nothing in the repository suggests there’s a problem. But somewhere else, a partner gateway still depends on that field. If the agent never sees that gateway, it has no reason to account for it, and no reason to think it would cause an incident.
A larger model might search the available code more effectively. It might follow clues that a smaller model misses. But it still can’t discover a caller that never appears in the evidence you gave it.
That information usually lives somewhere else: production traffic, gateway configuration, deployment metadata, a service catalog, or an ownership directory. These aren’t things the model should be expected to infer. They’re facts it needs to be given.
This is where the Context Graph API fits. It gives the agent access to those relationships before it starts making changes. The agent still has to inspect the code and verify what it finds, but it no longer has to reconstruct the entire architecture from whichever repositories happen to be open.
If you have been defaulting to your most expensive model for cross-service work because cheaper ones kept getting it wrong, the graph hands you a new assumption to test:
Perhaps the model was not too small. Perhaps its view of the system was.
Everything typed, every edge sourced #
The graph is a property graph consisting of typed nodes: APIs, deployments, databases, external services, teams, and telemetry.
A database is a node you can traverse to. So is the cluster the service runs on, and so is the team that owns it. That’s what makes a question like “which teams own something that reads from this database” answerable in one hop instead of three conversations.
Then typed edges, each with a fixed meaning:
| Edge | What it asserts |
|---|---|
exposes |
This API serves this endpoint |
calls |
This service sends requests to that endpoint |
depends_on |
This thing stops working correctly without that thing |
backed_by |
This service reads or writes this database |
owned_by |
This team is accountable for this API |
monitored_by |
This telemetry source or monitor watches this endpoint |
Six edge types is not many, and that’s deliberate. A schema an agent can hold in its head is a schema an agent writes correctly, and a fixed vocabulary is what lets you ask the same blast radius question about an endpoint, a database, and a cluster without learning three query shapes.
No single source knows the whole system, so the graph reads from three and reconciles them.
| Source | What it contributes |
|---|---|
| Your Postman workspaces | The API specifications ,collections ,monitors , and mock servers you already maintain |
| GitHub | Repository scans for OpenAPI ,AsyncAPI , and service definitions, plus the call sites in source |
| New Relic | What is actually deployed and running, observed from real traffic and telemetry |
Reconciling those three is the premise of the context graph. A specification in a workspace says an endpoint exists. The code says it is called from a repository that specification never mentions. New Relic says it is serving forty thousand requests a day from a deployment nobody wrote down. Your agents cannot resolve those conflicts, and until now neither could anything else in your stack.
Start building #
Every agent you deploy against your API estate is making a bet about what it cannot see. The Context Graph API is how you stop making that bet.
We run our context graph ingestion in Daytona. Each job runs in its own sandbox, inspects the relevant code, pulls out the relevant relationships, and writes them to the Context Graph. We use Daytona because it gives us the security and isolation we need without having to build and manage the AI infrastructure ourselves.
To start ingesting into the context graph, click on Agent Context from the Home Menu dropdown.
Then, click on Connect More, and then you’ll be taken to the indexing page. Postman is indexed by default.
Connect the rest of your sources, let the first ingest finish, then point your agent at the endpoint above.
Here is the test we would run in your position. Take the next cross-service change on your roadmap and ask your agent who it breaks. Write the answer down. Then ask the graph the same question and compare the two lists. If they match, you have lost twenty seconds and gained a lot of confidence in your tooling. If they do not, you have just found the consumers that were going to find you.
The HTTP endpoint is not the only way in. We are also bringing the Context Graph API to the Model Context Protocol (MCP), so any MCP client you already run — your editor, your agent framework, your own harness — can query the graph as a tool without you writing the request or handling the polling. Same graph, same evidence on every edge, one less integration to maintain. That is coming shortly. The endpoint above works today, and nothing you build against it now goes to waste when the MCP server lands.
Use the Context Graph API today. Bring the model you already use.
Read the docs here.