Mock AI Agents

Mocking an AI agent means simulating its interface and behavior — its A2A agent card, skills, and responses — so you can build and test agent-to-agent (A2A) integrations before the real agent is deployed. In A²D you design an agent card with reusable skills, mock its behavior with configurable scenarios, try it live in the playground, and run automated test suites against it across environments.

New to agent cards? Read Creating agent cards and the agent cards concept first.

What an agent mock includes

An A²D agent mock reproduces what a calling agent or client would interact with:

Agent card — the A2A descriptor: identity, capabilities, and skills.
Skills — reusable, invocable units of agent behavior.
Scenarios — mocked responses per skill for success and failure paths.
Protocol versions — target the A2A wire format your consumers expect.

Design, mock, try

The workflow mirrors MCP mocking, applied to agents:

Design the agent card and add its skills.
Add mock scenarios for each skill so behavior is deterministic.
Try the agent live in the Protocol Tester playground.
Point a real A2A client at the mock endpoint to develop against it.

{
  "skill": "summarize_ticket",
  "scenario": "success",
  "output": {
    "summary": "Customer reports login failures after password reset.",
    "priority": "high",
    "suggestedTeam": "identity"
  }
}

Configure the task status

Every A2A response carries a task status — the lifecycle state a calling agent reads to decide what to do next. By default a mocked scenario returns completed, but real consumers also need to handle non-terminal and failure states: a task still working, one that needs more input (input-required), or one that failed.

Each mock scenario has a Task status selector with the eight A2A states:

submitted, working — the task is accepted or in progress (non-terminal).
completed — the task finished successfully (the default).
failed, canceled, rejected — terminal failure states.
input-required, auth-required — the agent is waiting on the caller.

Set it to drive a specific consumer code path — for example, a scenario whose condition matches "escalate" can return input-required so you can exercise your follow-up flow without hand-authoring a full task JSON.

The selector defaults to From response JSON, which keeps whatever status.state your response body specifies (and completed when it specifies none). Choosing an explicit status overrides the status.state in the response JSON. The state you pick is version-agnostic: A²D maps it to the TASK_STATE_* enum for A2A v1.0 and to the plain state string for v0.3.0 automatically, so one scenario serves both transports.

Existing scenarios that predate this control are unaffected — with no status set they keep returning completed.

Signed agent cards

For integrations that require trust, A²D can mock and serve signed agent cards so consumers can validate the signature exactly as they would in production. See Signed agent cards.

Test agents automatically

Move from interactive checks to repeatable coverage:

Build suites that invoke skills and assert on agent responses.
Run across Mock, Pre-prod, and Prod environments.
Track which skills and scenarios are covered.

Next Steps

Creating agent cards - Build an A2A agent card
Design-first agents - Define agent behavior up front
Protocol versions - Target the right A2A wire format
Real-world mocking for MCP and agents - The full workflow

Mock the agent before you build against it — deterministic A2A integrations from day one. 🤖

API Mocking Design-First MCP