How to Call a ServiceNow AI Agent Using REST API

[SujanDutta]

One of the most powerful features of ServiceNow's AI agents is that they don't have to work in isolation. Imagine a monitoring agent that detects a problem and automatically hands it off to an incident-creation agent, or a triage agent that forwards complex cases to a specialized handler. This is agent-to-agent (A2A) communication in action, and it's one of the most elegant ways to remove silos and build truly autonomous enterprise workflows.

But how does it actually work under the hood? Let's break it down.

Making Your Agent Discoverable

Before agents can talk to each other, you need to explicitly allow it. This happens in two places:

First, in the AI Agent itself, you enable a toggle: "Allow third party to access this agent." Think of this as opening the door.

Second, you go into AI Agent Studio > Settings and enable "Allow third party to access AI agents (asynchronous)." This tells your ServiceNow instance, "Yes, external agents can call home."

Once both are set, your instance is ready for A2A communication. Without these toggles, your agent stays locked down — which is the right default for security.

The Two Essential APIs

ServiceNow provides two REST APIs out of the box. They work as a pair:

1. Agent Card API (Agent Card - Direct Discovery): This is discovery. When one agent wants to talk to another, it first asks, "What can you do?" The Agent Card API returns a detailed response that includes:
• Agent name and description
• Protocol information
• Available tools and skills (the "capabilities")
• A URL you'll use to actually invoke the agent

Think of it as an agent's résumé — it tells other agents exactly what tasks it can handle.

2. Invocation API( AI Agent A2A V2): Once you know what an agent can do, you use this API to actually call it. You send a message, the agent processes it, and you get back a result.

Understanding JSON-RPC and Input Message Structure

The invocation API uses JSON-RPC 2.0, a lightweight protocol that's perfect for this use case. Here's what a typical request looks like:

• Method: Usually message (because you're sending a message to the agent)
• ID: A unique identifier for this particular message. This is critical when you're sending multiple messages — it lets you match responses to requests.
• Params: The actual payload, broken into two sections:

What You Get Back

The response follows the same JSON-RPC structure. Here's what matters:

• ID: Matches your request ID, so you can verify you're looking at the right response
• Result:
• state: Either "completed" (agent finished its task) or "input-required" (agent is waiting for more info or approval if it's configured as supervised)
• context_id, message_id, reference_task_id: IDs you'll reuse if you send a follow-up message
• The actual task result
• provider: Tells you it's an external agent

Why This Matters

Traditional workflows have humans routing tasks between systems. A2A APIs let your agents do the routing. One agent can spawn multiple downstream agents, they can coordinate, and they can escalate intelligently. You get:

• Faster response times: No delays waiting for a human to route
• Complex orchestration: Chain multiple agents together seamlessly
• Error handling: Agents can handle responses and retry or escalate
• Audit trail: Every message is tracked with IDs and context

If you're building agents, this is mandatory knowledge. The next wave of enterprise automation runs on agent-to-agent communication, and now you know how to build it.