The prompts only the Postman AI Engineer can answer

Postman's AI Engineer, a natural-language layer over the Postman Context Graph, can trace data across APIs, collections, monitors, and frontend code, as demonstrated by five prompts that reveal hidden bugs and existing APIs. The tool's three-way drift detection compares OpenAPI specs, collection bodies, and live monitor responses, catching issues like a server returning 'amount' as a string when the spec says number. This capability addresses specification-vs-code drift that traditional two-way validation misses.

The prompts only the Postman AI Engineer can answer The Postman AI Engineer https://blog.postman.com/introducing-the-ai-engineer/ is a natural-language layer over the Postman Context Graph https://blog.postman.com/managing-downstream-dependencies-with-the-ai-engineer/ , a live index of every API, Postman Collection https://learning.postman.com/docs/collections/collections-overview/ , monitor, mock server, and connected repo you have access to. You type a question in plain English. The AI Engineer walks the graph and answers. The first time I ran a real question through it, I got back an annotated chain across four systems no single tool I have ever used has been able to touch at once. I stared at it for a minute. Then I ran the other prompts I had been carrying around as thought experiments. Most of them worked too. Here are the five I use most. The one I run first: tracing a value across your entire stack We have an identifier called employee id . It’s defined in the HR API, referenced by Payroll and Finance, and rendered in a React dashboard the internal tools team owns. It also gets renamed to employeeId in one service and emp-id in a legacy URL. Nobody has the whole map in their head. Trace an employee id value from the HR module through Payroll, Finance, and the frontend Dashboard component. Show me every hop, every rename, and every place it's persisted. The answer comes back as a chain: employee id HR API | ├─ HR OpenAPI file: defined on the Employee schema | ├─ Payroll collection: GET /employees/{employee id}, stored as variable | └─ Payroll monitor staging, hourly : last 24 runs saw the field | ├─ Finance API: renamed to employeeId inside GetPayrollSummary | └─ Legacy endpoint served at /finance/emp-id/{emp-id} | └─ Frontend repo dashboard : rendered by <EmployeeCard / └─ fetch call: /api/employees/{id} Read the chain. It’s the specification, the collection, the runtime signal, and the frontend source code in one answer. To produce it, something has to be looking at all four at once. That is what the graph is. Every other prompt in this post works the same way. Each one walks a different slice of the same graph. The prompt that catches bugs the specification and the code both miss Every team has fought specification-vs-code drift. The OpenAPI file says one thing, the handler does another, you diff them. Fine. Except there is a third source of truth you’re probably ignoring: what the running server actually returns. Compare the Enterprise Resource Planning API's OpenAPI file to what the v2 collection sends and what the running server actually returns. Show me three-way drift. You get a three-column table. Specification. Collection body. Last monitor response. Two-way validation catches rows where the first two columns disagree. Three-way validation catches the row where columns 1 and 2 both say amount: number and the running server is quietly returning amount: "12.00" as a string because a middleware layer stringifies decimals somewhere on the way out. That row exists in almost every large service I’ve ever touched. It has been invisible to every tool I’ve used until now. The prompt works because the graph already has the monitor results. It doesn’t have to go get them. The runtime signal was already there waiting to be asked. Ben Wilcock covered the underlying idea in more depth in Why context beats code alone https://blog.postman.com/api-specification-drift-why-context-beats-code-alone/ . The prompt that finds the API your org already built I run this one before I write a single line of new code. Do we have any existing API that manages user notification preferences? Show me endpoints, OpenAPI files, and collections that look like a match across every workspace I have access to, even if they're named differently. The graph searches across every workspace in the org, not only mine. It matches on schema shape and endpoint semantics, not on names, so the notification-preferences service that another team quietly shipped last quarter shows up even though they called it MessagingSettings . I’ve killed two duplicate proposals with this prompt. In one case the existing service was three teams away, used a naming convention I would never have grepped for, and lived in a workspace I did not know existed until the prompt surfaced it. That is the whole story. The graph knows what exists across the org because the org’s APIs live in it. The prompt that simulates a breaking change before you ship it Renames are the ones that get you. You rename a field, the compiler is happy, the tests pass, and three days later a downstream integration in another business unit stops working because it was using the previous field name in a hard-coded JSONPath. I'm about to rename id to employee-id. Simulate the blast radius across specifications, collections, mocks, monitors, downstream workspaces, and the React dashboard before I merge. The output is a directed graph of impact. Every collection that references the previous name. Every mock server that returns it. Every monitor whose assertion checks for it. Every source file that reads it. When I ran this before a rename last month, the number was 27. Twenty-seven places I had never audited, in three workspaces I didn’t own, across two repos I couldn’t see from my editor. The rename turned into a coordination doc instead of a merge conflict. Ship-blocking information, produced by a prompt. The prompt that writes the PR review before the reviewer opens it Given the current branch diff, auto-generate the PR review: contract changes, affected collections, affected mocks, affected monitors, affected consumers, and suggested OpenAPI updates. The reviewer opens the pull request and finds a pre-written review that already lists which contract fields changed, which collections need updating, which mock servers will now drift, which monitors will start failing, which downstream teams should be pinged, and what the updated OpenAPI file should look like. This is the one that has quietly become the most useful of the five in my day-to-day. Human review used to start with the reviewer reconstructing the diff’s blast radius from memory or grep. Now the review starts with that reconstruction already attached to the PR, and the human focuses on the parts a graph cannot judge: is this a good decision, does this match the design intent, is the API name right. Where this actually changes the work Every prompt in this post is a graph query wearing an English sentence. That is the point. The moment your API surface stops being a pile of files and starts being a live graph, questions that used to be “let me ask around” become “let me type it and hit enter.” Ownership. Consumers. Drift. Duplication. Blast radius. Review notes. All of it becomes a thing you type instead of a meeting you schedule. To run one of these against your own workspace, open Postman Agent Mode https://learning.postman.com/docs/agent-mode/overview/ in a workspace that has at least one API with an OpenAPI file, one collection, one Postman Monitor https://learning.postman.com/docs/monitoring-your-api/intro-monitors/ , and a connected repo through Native Git https://learning.postman.com/docs/agent-mode/native-git/ . Run the trace prompt against an identifier you actually care about. The answer is where the graph stops being an abstraction and becomes something you use. Resources Introducing the AI Engineer https://blog.postman.com/introducing-the-ai-engineer/ on the Postman blog Managing downstream dependencies with the AI Engineer https://blog.postman.com/managing-downstream-dependencies-with-the-ai-engineer/ Why context beats code alone for specification drift https://blog.postman.com/api-specification-drift-why-context-beats-code-alone/ Postman Agent Mode overview https://learning.postman.com/docs/agent-mode/overview/ in Postman Docs Native Git https://learning.postman.com/docs/agent-mode/native-git/ in Postman Docs Postman Monitors https://learning.postman.com/docs/monitoring-your-api/intro-monitors/ in Postman Docs Postman Collections overview https://learning.postman.com/docs/collections/collections-overview/ in Postman Docs