ServiceNow AI Agent subflows: design multi-step work people can inspect

What a ServiceNow AI Agent subflow actually does

ServiceNow's AI Agent Studio guide lists subflows alongside script tools and knowledge retrievers as agent tools. A subflow is not an extra AI brain. It is the repeatable, structured part of a job that the agent can call when its inputs fit.

That distinction is useful. A good subflow makes the system easier to run because its inputs and outputs are explicit. “Resolve access issue” is too broad. “Prepare an account-recovery handoff from a verified ticket number” is a job an operator can test.

A concrete support-handoff subflow

Consider a customer who says their account is missing. A support agent should not create a new account simply because a chat message asks for it. A practical flow is:

1. Receive the ticket number and customer identifier. Reject an incomplete request instead of guessing.
2. Retrieve permitted account and ticket context. Return the fields the next decision needs, not an unrestricted record dump.
3. Check for evidence. Has the customer supplied the account email, order reference, or other required verification? If not, draft the clarification question.
4. Create a handoff draft. Include the evidence found, the missing evidence, and the owner queue.
5. Send or update only after the configured approval path. The subflow can end with a prepared result when a human decision is needed.

The valuable output is not “the agent did something.” It is a handoff with the evidence another teammate needs.

Give each stage its own contract

This design also makes incident review less vague. If a failure comes from an absent record, fix the retrieval path. If it comes from missing customer evidence, improve the intake message. Do not treat both as a reason to grant a broad write action.

Configure security at the actual boundary

ServiceNow's current AI Agent Studio guide calls out two separate controls. ACLs determine who can discover and invoke an AI agent or agentic workflow. User identity determines what the agent can access after it starts. The recommended dynamic-user mode inherits the invoking user's roles; an AI user uses a dedicated account with fixed roles. Role masking can restrict inherited roles further.

That means an ACL is not enough to answer “can this subflow write this record?” It controls invocation, not the data authority during execution. For a script tool that accesses platform data, ServiceNow specifically recommends GlideRecordSecure rather than GlideRecord so table-level ACL checks apply.

ServiceNow also documents supervised mode for sensitive or critical tool actions. Use it where your own process requires a human decision. It is a configuration choice, not a claim that every action is automatically held.

Test the branch, not just the happy path

Run the subflow with a normal case, a missing identifier, a record the invoking user cannot access, contradictory evidence, and a failed downstream update. ServiceNow's current build guidance says access controls must be configured before testing or deployment. Its release notes also describe AI-native playground testing and automated agentic evaluations in the Australia release.

Check three outputs each time: the tools invoked, the data returned, and the final action or escalation. This is how a team finds a wrong boundary before it becomes an operational habit.

Inspect a scheduled or event handoff with eesel

eesel's AI helpdesk teammate is for teams that want a defined support job staffed in the tools they already use. The dashboard and CLI operate the same workspace and teammate. A person can run the commands; a script or coding agent such as Claude Code, Codex, or Cursor can read the JSON output and prepare a reviewed change.

With Node.js 18.17 or newer, inspect a scheduled or event-driven handoff before changing it:

npx @eesel/cli automations --agent "IT support"
npx @eesel/cli instructions --agent "IT support"
npx @eesel/cli activity --agent "IT support"

eesel automations shows event, scheduled, and webhook automations. eesel instructions lets you inspect the teammate's standing rules, and eesel activity shows recent work. If the evidence and rules look right, use the command's --help to find the supported update, run it with --dry-run, and only then make the approved configuration change. This does not configure ServiceNow for you; it gives the same eesel teammate a reviewable operating surface. The full CLI guide documents the commands.

The eesel Activity page shows recent work with filters for its status.

Build a handoff people can trust

A subflow is worthwhile when it turns a fuzzy support task into small, testable pieces of work. Start with retrieval and a draft handoff. Expand to an approved update only after real cases show that the inputs, access, and failure paths hold up.

Inspect one support handoff before you scale it

eesel lets a support team operate the same teammate in the dashboard, terminal, or a reviewable script. Connect the knowledge it needs, inspect the instructions and automation that shape the handoff, and test the result before you approve a wider configuration. Try eesel when you want that support work to be visible and reviewable.