SujanDutta
Administrator
Options
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
07-31-2026
08:09 AM
All You Need to Know About ServiceNow Action Fabric
ServiceNow Action Fabric enables AI agents on the Now Platform to work with external agents and tools through MCP and A2A protocols. It supports three patterns: ServiceNow as MCP client (calling outward), ServiceNow as MCP server (exposing capabilities), and ServiceNow agents collaborating with external agents via Google's A2A protocol.
This series examines each Action Fabric concept weekly to help you get the most out of AI agents on the platform.
Table of Contents
- Episode 1: Action Fabric Intro
- Episode 2: MCP in ServiceNow
- Episode 3: ServiceNow as MCP Client
- Episode 4: ServiceNow as MCP Server
- Episode 5: A2A (Agent2Agent) in ServiceNow
- Episode 6: ServiceNow as the Primary Agent
- Episode 7: ServiceNow as the Secondary Agent
- Series Wrap-Up
- Frequently Asked Questions
Episode 1: Action Fabric Intro
The Problem: Automation Islands
Today's enterprises run multiple applications, each shipping its own AI agents. These agents create isolated automation silos where they cannot coordinate across platform boundaries. The result: you can't build modular workflows that span vendors.
The Solution: Cross-Platform Interoperability
ServiceNow Action Fabric delivers orchestration where agents across your technology stack interoperate, with ServiceNow at the center.
The Tech Stack Behind the Concept
Action Fabric is platform-agnostic, delivering interoperability through three protocols:
1. ServiceNow as MCP Client (Outbound)
ServiceNow AI agents initiate outbound calls to external MCP servers, discovering published tools and retrieving context or capabilities. This extends agent reach by connecting to specialized external tools.
2. ServiceNow as MCP Server (Inbound)
ServiceNow publishes its capabilities as MCP tools that external clients like ChatGPT or Cursor can consume. Now Assist skills, custom skills, scripted APIs, and knowledge graphs all become available as tools.
3. A2A (Agent2Agent)
Google's open Agent2Agent protocol enables two AI agents to coordinate as peers on shared tasks, delegating subtasks and passing context across turns. ServiceNow agents can act as primary agents delegating outward or secondary agents receiving external delegations.
Episode 2: MCP in ServiceNow
MCP as the USB-C Moment
Before Model Context Protocol, every agent required custom integration code to communicate with each tool or system.
MCP is the USB-C moment. One standard protocol. Any agent can connect to any MCP server, no custom integration work required.
ServiceNow as MCP Server
Existing ServiceNow capabilities become tools any external AI can call. Now Assist skills, scripted REST APIs, and Table API queries packaged behind an MCP server become accessible to any external LLM or agent speaking MCP. Discovery is simple: once agents discover available tools, they make tool calls and ServiceNow returns results.
ServiceNow as MCP Client
ServiceNow reaches outward as an MCP client, consuming tools from external servers such as Microsoft Learn MCP servers or other MCP-compliant sources.
MCP provides the infrastructure for enterprise automation flows.
Episode 3: ServiceNow as MCP Client
The Use Case: Resolution Assist Agent
Support users handling incidents often need information that lives outside the platform: Microsoft application documentation, vendor guidance, or external knowledge bases. MCP as client closes this gap by letting ServiceNow AI agents discover and consume external tools while staying inside the incident workflow.
Workflow Steps:
- Support user handles an incident
- Agent pulls incident context (short description, full description) using an internal script tool
- Agent reaches out to an external MCP server (Microsoft Learn in this demo), performing a doc search using that context
- Retrieved guidance posts to the incident as a work note for user review or knowledge article creation
This demonstrates the mechanics clearly enough to adapt to your own external MCP servers and workflows.
Technical Implementation
1. Register the External MCP Server
In AI Agent Studio, navigate to Settings > Manage MCP Servers. This landing page registers external MCP servers, enabling ServiceNow to discover their published tools.
- Choose authentication type: OAuth 2.0 or API key
- For API keys, provide the server URL and key
- Saved servers appear as available options
2. Create an AI Agent
Add a new AI agent with a clear, meaningful role description so it understands its function. Default settings work for initial attempts.
3. Add Internal Script Tool for Incident Context
Configure a simple script tool that fetches incident details (short description and description fields) using the incident number. Set it as supervised so the agent confirms before executing.
4. Add the MCP Server Tool
Add tool type "MCP tool" and select the registered MCP server. ServiceNow performs a tools/list discovery call against the server; every exposed tool appears as an option.
5. Add Script Tool to Post Results
Configure a second script tool that takes the incident number and the resolution content returned by the MCP tool, then writes the results back as an incident work note.
6. Test It
With the reasoning panel enabled:
- Agent pulls incident context and identifies the actual issue
- Supervised tool pauses for confirmation before proceeding
- Agent proposes a search query and requests confirmation
- Upon confirmation, agent invokes the MCP tool, reaching the external server and returning documentation-based guidance unavailable in the incident or internal knowledge base
- Agent automatically posts guidance to work notes
Result: Support users receive externally sourced, relevant resolution guidance directly in incidents without leaving ServiceNow.
Any agent that needs external context, data, or capability can reach through registered MCP servers under governed authentication, bringing results into triggered records or workflows.
Episode 4: ServiceNow as MCP Server
ServiceNow can expose skills, REST APIs, flows, sub-flows, actions, and knowledge graphs as tools for external MCP clients like Claude or ChatGPT.
The Use Case: ServiceNow as Tool Provider for External AI
This scenario keeps the mechanics visible:
- Register a new MCP server inside ServiceNow and attach tools (starting with incident lookup and modification)
- Set up a secure inbound integration path (OAuth, JWT tokens, user-scoped access) enabling external AI access
- Connect an external AI client (Claude in this demo) to the ServiceNow MCP server using a custom connector
- Extend the server by exposing a custom scripted REST API as a tool
- Test: create an incident from natural language, add a work note, pull data through a custom REST API, all from outside ServiceNow
Technical Implementation
1. Open the MCP Server Console
Requires AI admin role; instance needs Zurich Patch 9 or later, or Australia Patch 2 or later. The out-of-the-box "Quick Search" MCP server provides a sandbox for understanding MCP server behavior before building custom ones.
2. Create New MCP Server
Provide a meaningful name and short description. Upon saving, the server URL populates automatically; this is the endpoint external clients connect to. Prefer multiple MCP servers over one large one for governance. This keeps access boundaries clean.
3. Add Tools to Server
Start simply. In this demo, two tools get added: a lookup incident records tool and a modify incident tool.
4. Set Up Inbound Integration (Machine Identity Console)
This enables external agents to authenticate against the new MCP server.
- Open Machine Identity Console and set up an application registry entry
- Choose Authorization Code grant type
- Fill in the redirect URL
- Copy the generated client ID and client secret
- Scope broadly for demos; production requires locking down API scopes
- Switch token format to JWT (currently expected by the MCP server connection)
5. Build Connection from External Client (Claude)
- In Claude's connector settings, add a custom connector
- Name it (e.g., "ServiceNow MCP") and paste the MCP server URL, client ID, and client secret
- The connector registers but is not yet connected; authentication is still needed
- When connecting, you are prompted for ServiceNow credentials. This keeps the connection user-scoped, so the external AI only sees what that specific user account is entitled to view (no elevated privileges from inbound requests)
6. Attach Now Assist Skill to MCP Server
Create a custom analysis skill that accepts natural-language queries to create incidents. Create a new tool, mark it as "analysis skill" type, and attach the MCP server. Single tools can attach to multiple MCP servers for context reuse.
7. Expose Scripted REST API as Tool
Beyond Now Assist skills, you can expose existing scripted REST APIs, flows, sub-flows, actions, and knowledge graphs as MCP tools. In this demo, a simple scripted REST API tied to incidents gets registered as a tool, tagged to the same MCP server, given a description, and saved.
8. Refresh Tool List on Connector
Back on the Claude side, refresh the MCP server's tool list. Newly added tools appear automatically; no reconnect needed, just refresh.
9. Test End-to-End
- Create incident from natural language: "My MacBook is extremely slow" + "it's really high priority." Claude calls the MCP server, discovers available tools, matches the request to the incident-creation tool, and creates the incident.
- Add work note: "Can you add a comment to this incident?" Claude identifies the modify incident tool and adds the comment.
- Pull data through custom REST API tool: Claude calls the scripted REST API tool and returns the expected results, confirming the custom-exposed tool works like the built-in ones.
Result: External AI clients operating under the logged-in user's permissions create and update ServiceNow records and call custom APIs without opening the ServiceNow UI.
Action Fabric's MCP server direction makes your existing platform investment (skills, APIs, knowledge graphs) into reusable infrastructure for whatever AI tooling your organization or users prefer.
Episode 5: A2A (Agent2Agent) in ServiceNow
By this point in the series, Action Fabric and MCP are old news: you know ServiceNow can act as an MCP client, reaching out to external tools, and as an MCP server, exposing its own capabilities to the outside world. The next question, the one Sayan tackles this episode, is what happens when a tool call isn't enough and you actually need one AI agent talking to another.
What A2A Actually Is
A2A is Google's open standard for direct, peer-to-peer collaboration between AI agents. It's a different shape than MCP. MCP is an agent talking to a tool: a request, a response, done, like calling a function. A2A is an agent talking to another agent: it hands over structured context, the other agent goes and does its own work, and it reports back. That exchange doesn't have to end after one round trip. It can run as a real multi-turn conversation, back and forth, until the job is actually finished.
A Job for MCP
Picture Claude sending a query into ServiceNow and asking for a list of knowledge articles back. Build the skill, wrap it as a tool, attach it to the server: one call in, one clean result out. That's a textbook MCP job: a single function that returns a single answer.
A Job for A2A
Now picture asking an agent that lives somewhere else entirely (built on Google ADK, LangGraph, whatever framework) to plan a trip. That agent isn't going to hand you a flight itinerary on the first try. It comes back with questions: where are you leaving from, where are you headed, when, flight or train? You answer, it goes and looks at options, and the back-and-forth keeps going until you've landed on something. That multi-turn, keep-talking-until-it's-solved pattern is where A2A earns its keep.
How ServiceNow Plays Both Sides
ServiceNow already knows how to be an MCP client and an MCP server. A2A adds a second pattern on top of that same foundation, and ServiceNow can sit on either side of it.
ServiceNow as the primary agent. Here, ServiceNow's AI agent is the orchestrator running the workflow, and it reaches out to an external agent: a Google agent, an AWS agent, an agent built on any framework. The sequence is straightforward: discover the agent, pull everything it can do, then execute it and delegate the task. Once that happens, ServiceNow is the primary agent and whatever it called is the secondary agent.
ServiceNow as the secondary agent. Flip it around, and ServiceNow can just as easily be the one getting called. Register an AI agent in Agent Studio, make it discoverable, and external third-party agents can find it, run it, and delegate work to it: the same interoperability, just running in the other direction.
That's the core of A2A: MCP still owns the clean, single function call. A2A is what you reach for the moment the job means handing real work to another agent and following it through to the end.
Episode 6: ServiceNow as the Primary Agent
The last episode in this series laid out the concept: A2A lets a ServiceNow AI agent sit on either side of an agent-to-agent exchange, either as the one delegating work out or the one receiving delegated work. This episode puts that first half into practice with a live build, ServiceNow reaching out to an agent that lives entirely outside the platform and handing it a real task.
The Use Case: Discovering and Calling an External Flight Agent
For this demo, the external agent is a simple AI agent built with Google's Agent Development Kit, using Vertex AI as its reasoning model and exposed over a URL. Hit that URL and it returns an agent card: a structured description of what the agent does and how to reach it. An API key sits on top of it, so ServiceNow has a way in.
The goal is to get ServiceNow to discover that agent, pull its capabilities, and invoke it, with ServiceNow acting as the primary agent and the Google-built agent acting as the secondary one.
Technical Implementation
1. Turn on Discoverability
Inside AI Agent Studio, under Settings, there's a section called External AI Agents. This is where you turn on discoverability so ServiceNow can reach out to agents registered outside the platform. There's a second toggle that runs the other direction, letting external agents discover agents registered inside ServiceNow.
Flipping that toggle on does not expose every agent in ServiceNow to the outside world. It works the opposite way: nothing is exposed unless you go into that specific agent and turn on exposure for it individually.
2. Register the External Agent
With the agent card URL in hand, head to Create and Manage and choose the option for adding an external agent. Add a new provider and paste in the well known URI, the agent card address.
3. Set Up Credentials
The advanced settings split authentication into two separate moments: one set of credentials used at discovery time, and a separate set used at execution time. Since this particular agent is set up to be publicly discoverable, no credentials are needed to find it. Hit discover, and the agent shows up.
4. Look at What Came Back
Opening the discovered agent shows the basics first: what kind of agent it is, a short description, that sort of thing. Dropping into the agent card itself shows a lot more: what skills the agent exposes, its actual connection URL, and details like the transport protocol it runs on (JSON-RPC in this case). Think of the agent card as a digital business card that other agents can read to understand what an agent does and how it's configured.
5. Activate It
Activating the agent kicks off the skill discovery. In this case, one meaningful skill comes back: a search capability. Once discovery finishes, most of the configuration populates automatically from what the agent card provided, though you can rename things or adjust as you like.
6. Add Authentication for Execution
The communication protocol fills in on its own. From there, add the authentication needed to actually call the agent. Basic auth or an API key both work; this demo uses an API key already saved as a credential.
The connection URL used to call the agent is not the same as the agent card URL used to discover it. The connection URL comes from inside the agent card itself, so it populates automatically once discovery runs, but it is a different address doing a different job.
7. Test It
Upon saving the agent shows as active and discoverable. Once triggered the orchestrator immediately recognizes this as an external agent call. The execution shows is flagged as external, reaching out to the agent that lives outside ServiceNow entirely, and coming back with results.
Result: ServiceNow discovers an agent card, activates the agent, and executes a call to it, with the orchestrator treating the whole exchange as an agent-to-agent handoff rather than a simple tool call. That's the primary agent role in practice: ServiceNow finds the agent, pulls what it can do, and delegates the task to it.
Episode 7: ServiceNow as the Secondary Agent
Last episode put ServiceNow in the driver's seat as the primary agent, reaching out to an external agent and handing over a task. This episode flips the direction entirely. Here, ServiceNow is the one being called. An AI agent registered in Agent Studio becomes discoverable to external agents, and a separate ServiceNow instance acts as the primary agent reaching in.
The Use Case: Cross-Instance Incident Lookup
The setup uses two ServiceNow instances. On the secondary instance, there's a simple AI agent that takes an employee number, looks up the corresponding user, and summarizes their open incidents. On the primary instance, another agent discovers that calls the secondary agent to get the same information, without ever touching the secondary instance's UI.
This keeps the demo focused on the mechanics of a secondary agent and establishing the connection from the other side.
Technical Implementation
1. Build the Agent
In AI Agent Studio on the secondary instance, create an AI agent. This one accepts an employee number, queries the user table to find the matching record, then pulls all open incidents for that user and summarizes them.
2. Enable Discoverability and Grab the Agent Card URL
Head into Settings > External AI Agents and confirm discoverability is turned on, with synchronous communication mode selected (asynchronous requires additional configuration). Also verify that the sn.ai.external.agents property is set to true; this enables external agents to interact with agents registered on that instance.
Then open the agent itself and toggle the property that makes this specific agent externally discoverable. Once that's set, an agent card URL is generated automatically. This URL will be needed by the primary instance to establish the connection.
3. Test the Agent Locally
Before connecting anything, run the agent directly on the secondary instance to make sure it works on its own. Verify by passing an employee number and validate that the agent finds the user and then (with a supervised tool confirmation) pulls up all open incidents for that user. This ensure that the agent is ready to be discovered.
4. Set Up Authentication on the Secondary Instance
Three pieces need to be in place before external agents can call in -
REST API Key: Create a REST API Key and provide a name and associate it with the appropriate user,. Make sure the A2A scope is included.
Inbound Authentication Profile: Create an authentication profile and set the authentication parameter to header for API key. This informs the platform about the credentials on incoming requests.
API Access Policy: In the REST API Access Policies module we need to add the newly created authentication profile to the out-of-the-box record for A2A. This links everything together so that inbound A2A requests authenticated properly.
5. Register from the Primary Instance
Switch to the primary instance and enable the property that allows this instance to access external agents. Navigate to the AI agents list, create a new external agent, and paste in the agent card URL from the secondary instance and provide a name.
Upon discovery, the agent's details are fetched: its description, capabilities, and the full agent card showing skills, connection URL, and transport protocol (JSON-RPC, same as before). The agent is activated and Skill discovery is executed, and the tools registered on the secondary agent (user lookup, incident lookup) appear automatically.
6. Configure the Connection
This is where the details matter.
Retry policy: Set it to the default HTTP retry policy.
Configuration template: Select "secondary bot static token configuration." This is critical. Without it, the flows won't authenticate against the secondary instance for execution.
Connection URL check: Open the connection record and verify the URL. If it ends with /.well-known/agent.json, that's the discovery URL, not the execution URL. The execution URL ends differently. Getting wrong URL will result in execution failure.
Credential: Create a secondary bot static token credential and paste in the API key from the secondary instance. Then override the connection record's credential with this new one. Make sure the header name is correct; the secondary instance's inbound auth profile needs this data. You can also authenticate using OAuth 2.0 here, which follows the usual machine identity console and application registry flow.
7. Test End-to-End
For an complete testing, we need to be back on the primary instance, save the agent configuration, make sure it's active, and trigger a test. The orchestrator recognizes this as an external agent call and reaches across to the secondary instance.
The agent on the other side does its job, finds the user based on the employee number, confirms the match, and pulls up open incidents. The whole exchange runs as a multi-turn conversation, which is the hallmark of A2A. The primary agent asks, the secondary agent responds, confirmation happens, and the final result comes back with incident numbers and states.
You can drive this as Now Assist, a virtual agent, or via other channel.
ServiceNow acts as the secondary agent, receiving an inbound A2A request from another instance, authenticating it, running its own agent logic, and returning results through a multi-turn exchange.
Series Wrap-Up
Over seven episodes, this series walked through every feature Action Fabric supports: ServiceNow reaching outward as an MCP client to consume external tools, ServiceNow exposing its own capabilities as an MCP server for external AI to call, and ServiceNow participating in agent-to-agent collaboration through A2A as both the primary and the secondary agent.
MCP server mode takes the skills, APIs, and knowledge graphs you've already built and makes them available to whatever AI tooling your organization runs. MCP client mode lets your agents pull in external context without leaving the workflow. A2A lets your agents hand off real work to agents that live on entirely different platforms, or receive that work from them.
Action Fabric is a set of protocols and configurations that make the ServiceNow Platform a participant in every AI agent ecosystem your organization is building. The mechanics are deliberate, authentication is user-scoped, discoverability is opt-in per agent, and governance stays with you at every step.
Frequently Asked Questions
What is ServiceNow Action Fabric used for?
ServiceNow Action Fabric makes AI agents interoperable across vendor boundaries, enabling agents built on ServiceNow to work with agents and tools from Microsoft, SAP, Salesforce, and other platforms. It provides cross-platform agent orchestration with ServiceNow at the network center. Practical outcome: single workflows span multiple vendors' agents without custom point-to-point integration.
What is the difference between Action Fabric and MCP?
MCP (Model Context Protocol) is an open standard for exposing and consuming tools between AI systems. Action Fabric is the ServiceNow framework that implements MCP alongside Google's A2A protocol as a governed capability on the Now Platform. MCP is the protocol; Action Fabric is how ServiceNow makes that protocol usable with platform authentication, scoping, and agent orchestration.
What is the difference between MCP and A2A in ServiceNow?
MCP operates at the tool level: it lets AI agents discover and call individual capabilities like Now Assist skills, scripted REST APIs, or knowledge graph lookups. A2A (Agent2Agent, Google's open protocol) operates at the agent level, letting ServiceNow AI agents delegate to and collaborate with complete external agents. In Action Fabric, MCP covers tool access in both directions while A2A covers peer-to-peer agent interaction.
Can ServiceNow agents talk to ChatGPT or Cursor?
Yes, in both directions. When ServiceNow acts as MCP server, external clients like ChatGPT and Cursor discover and call Now Assist skills, scripted REST APIs, and knowledge graphs, subject to OAuth and user-scope enforcement (the caller only sees what that identity is entitled to). When ServiceNow acts as MCP client, agents registered in AI Agent Studio reach outward and call tools on any registered external MCP server.
Is Action Fabric part of Now Assist?
No. Action Fabric and Now Assist are separate but complementary. Now Assist provides generative AI skills running on the platform; Action Fabric is the interoperability layer that lets those skills be exposed to external AI systems and lets ServiceNow agents consume external tools. In practice, Now Assist skills become tools published through Action Fabric MCP servers.
What does it mean for ServiceNow to act as an MCP client?
ServiceNow AI agents initiate an outbound connection to an external MCP server, discover published tools, and call them to retrieve information or capability that does not exist inside ServiceNow. The agent stays in control of the workflow; the external server supplies the tool call and result.
What authentication does ServiceNow support when registering an external MCP server?
The Manage MCP Servers page supports OAuth 2.0 and API key authentication. For API key auth, provide the server URL and key directly when registering the server.
What's the difference between ServiceNow as an MCP client vs. an MCP server?
As MCP client, ServiceNow initiates an outbound call pulling external tools or data. As MCP server, ServiceNow is on the receiving end, with external AI clients connecting and calling exposed tools like Now Assist skills, scripted REST APIs, and knowledge graphs.
What can I expose as an MCP tool besides Now Assist skills?
Scripted REST APIs, flows, sub-flows, actions, and knowledge graphs can all register as MCP tools alongside table lookups like incident records.
Does the external AI need to know which tool to call?
No. That is the point of MCP discovery. The client calls the MCP server, retrieves the available tools list, and matches the natural-language request to the right tool automatically. For example, it recognizes "add a comment" should call the modify-incident tool, not the incident-creation tool.
Can I reuse the same tool across multiple MCP servers?
Yes. Single tools can attach to multiple MCP servers if relevant to multiple use cases.
What is A2A in ServiceNow?
A2A (Agent2Agent) is Google's open protocol for direct, peer-to-peer collaboration between AI agents. Inside Action Fabric, it lets a ServiceNow AI agent hand off a task to an external agent, or receive one from an external agent, using structured context instead of a single tool call.
How is A2A different from MCP?
MCP is an agent calling a tool: one request, one response, similar to calling a function. A2A is an agent calling another agent: it passes structured context, the other agent runs its own process, and the two can go back and forth across multiple turns before the task is done.
When should I reach for MCP instead of A2A?
If a single function call gets you what you need, MCP does the job: a query in, one clean result out, like ServiceNow returning a list of knowledge articles to Claude.
When should I reach for A2A instead of MCP?
Whenever the task needs real back-and-forth with another agent rather than one call and done, for example delegating a multi-step job like trip planning to an external agent that asks follow-up questions before it can complete the work.
What does it mean for ServiceNow to be the "primary agent" in A2A?
ServiceNow is the primary agent when its AI agent acts as the orchestrator: it discovers an external agent, retrieves that agent's capabilities, then executes and delegates the task to it.
What does it mean for ServiceNow to be the "secondary agent" in A2A?
ServiceNow is the secondary agent when an external agent is the one reaching in. Once an AI agent is registered in Agent Studio and enabled for discovery, outside agents can find it, execute it, and delegate work to it.
Can ServiceNow be both the primary and secondary agent?
Yes. The two patterns aren't exclusive: the same ServiceNow instance can call out to external agents as a primary agent and be discoverable by external agents as a secondary agent.
Does A2A support multi-turn conversations between agents?
Yes, that's the point of it. An A2A exchange can run across multiple turns while the two agents work through a task together, instead of stopping after one call.
What kinds of external agents can ServiceNow talk to over A2A?
Any agent built to speak the A2A protocol, regardless of framework: Google ADK, LangGraph, AWS-based agents, or anything else that supports the standard.
What is an agent card in ServiceNow's A2A setup?
An agent card is a structured description an external agent publishes at a well known URI. It lays out what the agent does, what skills it exposes, its connection URL, and the transport protocol it uses. ServiceNow reads this card to understand an external agent before calling it.
How do I let ServiceNow discover an external agent?
In AI Agent Studio, turn on discoverability under Settings > External AI Agents, then go to Create and Manage, add a new provider, and paste in the agent's well known URI. Saving and running discover pulls in the agent's details.
Does turning on discoverability expose all my ServiceNow agents externally?
No. Turning on the discoverability setting only opens the door for the toggle to work at all. Nothing gets exposed unless you go into each individual agent and turn on exposure for that specific one.
What's the difference between the agent card URL and the connection URL?
The agent card URL is the well known address used to discover an agent and read its details. The connection URL is the actual endpoint used to execute calls against that agent, and it's a separate address populated automatically from inside the agent card once discovery completes.
Why are there two sets of credentials when registering an external agent?
One set of credentials applies at discovery time, when ServiceNow is just trying to find and read the agent card. A separate set applies at execution time, when ServiceNow actually calls the agent to run a task. An agent can be publicly discoverable with no credentials needed for that first step, while still requiring authentication, such as an API key, to execute.
What authentication options are available for calling an external agent?
Basic authentication and API key authentication are both supported when setting up the execution credentials for a registered external agent.
What happens when I activate a discovered external agent?
Activation triggers skill discovery against that agent. Whatever skills the agent exposes get pulled in and shown, and most of the remaining configuration auto-populates from the agent card at that point.
What kind of external agents can this work with?
Any agent that publishes a proper agent card at a well known URI.
Can two ServiceNow instances communicate with each other through A2A?
Yes. One instance acts as the primary agent and the other as the secondary. The primary instance discovers the secondary instance's agent via its agent card URL, and the two communicate over A2A just like any other agent-to-agent exchange.
What authentication do I need on the secondary instance for inbound A2A requests?
Three things: a REST API key with the A2A scope included, an inbound authentication profile set to header for API key, and the out-of-the-box A2A API access policy updated to include that authentication profile. All three need to be in place before external agents can call in.
What is the "secondary bot static token configuration" and why does it matter?
It's a configuration template you select on the connection record when setting up the primary instance's link to the secondary agent. Without it, the authentication flows won't work at execution time, meaning discovery succeeds but actual agent calls fail. Pair it with a secondary bot static token credential that holds the API key from the secondary instance.
Can I surface a secondary agent through Now Assist or a virtual agent?
Yes. Once the agent is active and working, you can publish it through Now Assist, a virtual agent, or any other channel supported by Agent Studio.
- 6,543 Views
2 Comments
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
