Last week, I gave a talk at GitHub Universe 2026 about context. The question behind it: when a coding agent changes one API, how does it know what else that change breaks?
The demo answers it with two agents building on a healthcare app, each in its own session with no shared memory. Agent A uses the Postman Context Graph to find which services supply the data for a claims-review API, builds a simulation of those dependencies, and publishes it to a Postman workspace. Agent B pulls that simulation, runs the existing tests, and extends the API. The checks go from 10 passing assertions to 14, and Agent B never has to rediscover a dependency.
The part nobody talks about #
My talk was called “Agentic SDLC with Context Graph and API Simulations.” The premise: all of us use coding agents to do engineering work, and it’s rare for that work to have no downstream dependencies that also need updating. The agent writes the code, silently breaks a bunch of other things, and you get paged for an incident tied to your change. That’s the part nobody talks about. The agent does the engineering work, but I’m the one keeping track of everything around it: the context, the dependencies, what’s been verified, and what else needs to be updated. The talk was about handing more of that tracking to the agent, using the Postman plugin.
The endpoint is the fast part #
An agent can write an endpoint quickly. The work around the endpoint is what takes longer. I framed it with four items:
| What takes longer | What it means for an agent |
|---|---|
| Contract | Understanding what the API promises |
| Dependencies | Finding every service the change touches |
| Tests | Checking the behavior, not only whether it compiles |
| Handoff | Leaving the next person or agent a setup they can use |
The Postman plugin gives an agent skills for API engineering. Each skill holds instructions the agent can read for a task: which tools to use, which files to work with, and how to check the result. The full plugin covers development, testing, documentation, CI, and monitoring, so it reaches every phase of the SDLC. For this talk I picked two skills:
api-discovery, which includes the Context Graph, helps the agent understand the APIs and relationships involved.api-simulationgives the agent an environment where it can develop against those dependencies.
Then I added a constraint to make the demo honest: two agents working on consecutive tasks, in separate sessions, with a Postman workspace as the only thing carrying work between them.
A librarian, a catalog, and a lot of shelves #
To explain why the Context Graph comes first, I used a library.
Imagine you walk in and ask the librarian to find everything about chess. There’s no computer catalog, so the only way to answer is on foot. The librarian walks the building, searches every shelf, and inspects individual books. A more experienced librarian might do that faster and notice more, but they’re still searching the entire building from scratch.
Now give the librarian the catalog. Instead of starting at the first shelf and working aisle by aisle, book by book, page by page, they search once and get a list of relevant books with exact shelf locations. The catalog tells them where to begin, which books to pull, and which sections deserve a closer look. It can also point to a chapter inside a book with an unrelated title, a book stored at another location, or a resource that isn’t on a physical shelf at all, like an audiobook. The librarian then opens the books and verifies they contain what you need.
| In the analogy | In the agent workflow |
|---|---|
| The librarian | The model |
| The shelves | The checked-out repositories |
| The catalog | The Context Graph |
The Context Graph tells the model which services, APIs, endpoints, and relationships are likely to matter and where to focus its search. Instead of exploring hundreds of repositories one by one and burning countless tokens, the model starts with a specific set of candidates and verifies those leads in the code wherever it can. Postman’s own writing on why AI coding agents need context graphs makes the same argument with more depth.
The analogy also answers the question I get most about model quality. A better model is a faster, more experienced librarian. It searches the shelves more efficiently, but it still can’t find something that isn’t on those shelves. The Context Graph gives the agent a starting point: which APIs are relevant to the task, where to find them, and which relationships to verify.
Develop against dependencies you can’t run #
Knowing where an API lives doesn’t mean its service is available to run on your laptop. That’s the gap api-simulation fills.
Say my service calls four other APIs. To develop it locally, I need to exercise those calls, including their responses and failures, without bringing up all four real services. A Postman simulation groups the dependency mocks into one runnable setup. Each mock represents an API, and the simulation defines how to reach them together. My real service runs locally and sends its dependency calls to that setup, and I can add delays, errors, and rate limits to see how the service behaves when a dependency has a bad day.
Then comes the handoff. I save the requests and assertions as a Postman Collection and publish the simulation and the collection to a workspace. Another agent can retrieve both, start the same dependency setup, and rerun the existing checks before it changes anything.
The demo: two agents, one workspace #
The demo used a hospital app, myhealthcare.dev, with services that manage patients and billing. The goal was to add an insurance service so a user can view claims and approve or deny them. I split the work between two agents and drew the whole thing on a whiteboard first.
The whiteboard sketch from the talk. Claim data is spread across services, so Agent A has to find out which ones supply it.
Agent A builds the API for viewing claims. Each claim needs an insurance ID, a patient’s name, and a billing amount, and that information lives in different services. The patient’s name comes from the patient service. Agent A asks the Context Graph where to get each piece and which dependencies it needs.
Here’s the start of the prompt I gave it:
Prompt
I’m adding a claims-review feature to claims-status-service: look up a claim with its patient’s name, and approve or deny it, which notifies billing. Ask the Context Graph which services supply the claim and patient data and what relationships to account for, then build a local simulation of those dependencies from the repo’s existing mocks. Implement the feature against the simulation and create a Postman collection with checks for it.
You can watch the whole run in the recording below.
The demo from my GitHub Universe session: two agents in separate sessions, a Context Graph query, a shared simulation, and a Postman workspace in the middle.
Here’s what happens in the video:
- Agent A uses the
api-discoveryskill to ask the Context Graph which services supply the claim and patient data, and how billing connects to the decision. - It uses
api-simulationto simulate those dependencies locally, so it can build and test without running every service on my machine. The Postman skills guide it through creating a collection and adding tests. - All 10 assertions pass, and all four dependencies take traffic. Agent A publishes the simulation and the collection to a shared Postman workspace.
- I switch to Agent B in a separate session. It has no memory of Agent A’s work, so it pulls the shared assets from Postman and runs the existing tests before making any changes.
- Agent B’s task is an endpoint that lists claims by payer. It checks the Context Graph for the relevant APIs, then develops against the simulation Agent A already created.
- Agent B adds tests for the new endpoint and reruns the collection. There are now 14 passing assertions, and it pushes the updated assets back to the workspace.
In the original plan on the whiteboard, Agent B approves or denies claims and has to tell billing about each decision. The recorded run uses a smaller task, but the principle holds: Agent B asks the Context Graph which downstream service needs to know about a change, then uses the simulation to check that the right update reaches it.
The shared simulation in the Postman workspace. Four mocks stand in for the services the claims API depends on.
The moment I care about most is step 4. Agent B doesn’t have to figure out those dependencies or set them up again. The Context Graph helps each agent understand what its change touches, and the shared simulation lets the second agent build on the first agent’s work. That’s the agentic SDLC I wanted to show: discover dependencies, simulate them, build, test, and share the result so the next agent can keep going.
Try it yourself #
You can run the same loop on your own services. I ran the demo in GitHub Copilot, but the Postman plugin installs into other coding agents too, so use whichever one you already have. One command installs it:
npx @postman/postman-plugin
The installer adds the plugin to each supported agent it detects on your machine, including GitHub Copilot and Claude Code. To install into a single agent, pass its ID, and check where the plugin is installed with status:
npx @postman/postman-plugin install --agent copilot
npx @postman/postman-plugin status
The plugin install guide covers the per-agent options if you’d rather use an agent’s own marketplace. Next, connect your repository to a Postman workspace:
postman init
Then sign in and ask the Context Graph a question about a service you own:
postman login
postman context-graph ask "What depends on billing-api?" --wait
Swap billing-api for one of your services. The --wait flag prints the answer inline, and without it the command returns an ask ID you can check later with postman context-graph status. From there, try this prompt in your agent, adapted from the demo:
Prompt
I’m changing the response of the orders API. Ask the Context Graph which services consume it and what relationships to account for, then build a local simulation of those dependencies. Implement the change against the simulation and create a Postman collection with checks for it.
Run the collection, publish the simulation and collection to a workspace, and start a second agent session. Ask it to pull the shared assets and run the existing checks before it changes anything. If it can do that without you explaining the dependencies again, the handoff works.