# Testing APIs with Postman Agent Mode: A Practical Guide If you've spent any amount of time writing API tests by hand, you know the drill: copy a response, write assertions for every field, chase down a mystery 401 for half an hour, then do it all again when the contract changes next sprint. Postman's Agent Mode takes a different approach. It's an AI agent that lives inside your workspace, sees your actual requests and responses, and generates tests based on what it observes. Not templates. Not boilerplate. Context-aware assertions derived from real data. Here's how to actually use it. ## **What Makes Agent Mode Different** Agent Mode isn't a generic AI assistant that happens to know some JavaScript. It runs inside your Postman workspace with access to your collections, environment variables, response data, and API specs. That context is what makes it useful. When you point it at a response, it picks up on patterns you'd normally encode yourself: ID prefixes, email formats, enum values, timestamp structures. It also understands auth flows, so when something breaks, it can trace the issue back through your pre-request scripts and environment config. Three things worth knowing upfront: 1. It generates standard Postman test scripts (plain JavaScript), so everything it produces runs in Collection Runner, CLI, and CI/CD without any special runtime. 2. It asks for approval before modifying your collections. You can toggle this on or off. 3. It's only as good as the context you give it. More on that later. ![](https://blog.postman.com/wp-content/uploads/2026/03/Screenshot-2026-03-23-at-10.25.50-PM-300x184.png)## **Generating Tests from a Response** Send a request. Open Agent Mode. Tell it what you want. Say you've got this response from a user endpoint: ``` { "status": "success", "data": { "id": "usr_7x9k2m", "email": "developer@example.com", "name": "Test Developer", "role": "admin", "created_at": "2026-03-15T10:30:00Z" } } ``` > Ask Agent Mode: *"Generate tests for this response that validate the structure and required fields."* You'll get something like: ``` pm.test("Status code is 200", function () { pm.response.to.have.status(200); }); pm.test("Response has success status", function () { const response = pm.response.json(); pm.expect(response.status).to.eql("success"); }); pm.test("User data contains required fields", function () { const data = pm.response.json().data; pm.expect(data).to.have.property("id"); pm.expect(data).to.have.property("email"); pm.expect(data).to.have.property("name"); pm.expect(data).to.have.property("role"); pm.expect(data).to.have.property("created_at"); }); pm.test("User ID follows expected format", function () { const userId = pm.response.json().data.id; pm.expect(userId).to.match(/^usr_[a-z0-9]+$/); }); pm.test("Email is valid format", function () { const email = pm.response.json().data.email; pm.expect(email).to.match(/^[^\s@]+@[^\s@]+\.[^\s@]+$/); }); ``` Notice it picked up on the usr\_ prefix and generated a regex for it. It saw the email and added format validation. That's the difference between generated-from-context and generated-from-a-template. ## **Debugging Auth Failures** This is where Agent Mode earns its keep. When you hit a 401, drag the failing request into the chat and say *"diagnose this authentication failure."* It checks your environment variables, token format, Authorization header, and expiry timestamps. A typical diagnosis might look like: > *"The request is failing because {{access\_token}} resolves to an empty string. Your environment variable access\_token isn't set. Check your OAuth token refresh flow — the pre-request script in your Auth folder should be setting this value."* That kind of specific, traceable answer is the difference between a 2-minute fix and a 20-minute scavenger hunt through your environment config. ## **Building a Full Test Suite** For real coverage, you want contract tests, functional tests, error handling, and performance checks. You can ask Agent Mode for all of these at once: > *"Review this collection and suggest tests for comprehensive coverage."* Here's what schema validation looks like: ``` pm.test("Response matches user schema", function () { const schema = { type: "object", required: ["status", "data"], properties: { status: { type: "string" }, data: { type: "object", required: ["id", "email", "name"], properties: { id: { type: "string" }, email: { type: "string", format: "email" }, name: { type: "string" }, role: { type: "string", enum: ["admin", "user", "viewer"] } } } } }; pm.response.to.have.jsonSchema(schema); }); ``` And a performance gate: ``` pm.test("Response time is under 500ms", function () { pm.expect(pm.response.responseTime).to.be.below(500); }); ``` ## **Chaining CRUD Workflows** For multi-step flows (create → read → update → delete), Agent Mode generates tests that pass data between requests using environment variables - It includes cleanup steps automatically, which is a detail that's easy to forget when writing these by hand: ``` // POST /users — test script pm.test("User created successfully", function () { pm.response.to.have.status(201); const userId = pm.response.json().data.id; pm.environment.set("created_user_id", userId); }); // GET /users/:id — test script pm.test("Retrieved correct user", function () { const expectedId = pm.environment.get("created_user_id"); const actualId = pm.response.json().data.id; pm.expect(actualId).to.eql(expectedId); }); // DELETE /users/:id — test script pm.test("User deleted", function () { pm.response.to.have.status(204); }); // Cleanup pm.environment.unset("created_user_id"); ``` ## **Tips That Actually Help** **Let it see failures first.** Run your collection, let tests fail, then bring the results to Agent Mode. It's often faster to diagnose failures than to write perfect tests upfront. **Drag in context.** Use the @ mention to attach collections, requests, environments, and OpenAPI specs. The more context Agent Mode has, the more specific its output![](https://blog.postman.com/wp-content/uploads/2026/03/select-agent-context-v12-300x212.png) **Create Test Coverage Reports.** Use the /Create Test Coverage Reports to validate for quality ![](https://blog.postman.com/wp-content/uploads/2026/03/Screenshot-2026-03-23-at-10.30.27-PM-300x215.png) **Ask for negative tests explicitly.** By default, it focuses on what it can observe. If you want tests for invalid inputs, missing fields, and unauthorized access, say so. **Watch for overly specific assertions.** It might generate ``` pm.expect(user.name).to.eql("Test Developer") ``` when you really want. Always review before accepting. ``` pm.expect(user.name).to.be.a("string") ``` ## **Running in CI/CD** Since Agent Mode produces standard test scripts, they plug directly into your pipeline: ``` npm install -g @postman/cli postman collection run "User API Tests" \ --environment "staging" \ --reporters cli,json \ --reporter-json-export results.json ``` ## **The Bottom Line** Agent Mode shifts your job from writing every assertion to defining what you want tested. You describe intent, it generates implementation, you review and refine. The tests are real, runnable, and CI-ready. If you want to try it out without touching production, import the Postman Echo collection and start experimenting. Send a request, open Agent Mode, and ask: > *"What tests should I write for this?"* ![](https://blog.postman.com/wp-content/uploads/2026/03/Screenshot-2026-03-23-at-10.28.06-PM-300x190.png) Then iterate from there. ## **Resources** - [Postman Agent Mode](https://www.postman.com/product/agent-mode/) — Official product page - [Meet Agent Mode](https://learning.postman.com/docs/agent-mode/agent-mode-overview/) — Learning resource - [Writing Test Scripts](https://learning.postman.com/docs/tests-and-scripts/write-scripts/test-scripts/) — Test script reference - [Postman CLI Docs](https://learning.postman.com/docs/postman-cli/postman-cli-overview/) — CI/CD integration - [postmanlabs/postman-mcp-server](https://github.com/postmanlabs/postman-mcp-server) — MCP server for AI tool integration