Agentic AI on ServiceNow: Otto, Agent Studio, and Build Agent Explained (Chapter 4)

This is Chapter 4 in a series walking through ServiceNow's AI stack from the ground up. Chapters 1 through 3 covered fundamentals, Now Assist as a consumer, and Now Assist for Creator — all of it still fundamentally human-directed, one generation at a time. This chapter is where that changes. Agentic AI means something is making tool-calling decisions on its own, repeatedly, across a task — not producing one draft for you to review once.

This is also the chapter where beginners most often confuse marketing language for architecture. The goal here is to make the distinction concrete rather than conceptual.

1. Agent vs. Chatbot vs. Flow — the Same Task, Three Ways

The clearest way to see the difference is to build the same task three different ways and compare what's actually deciding what happens next.

Task: a user requests a password reset.

Built as a flow (Chapter 1–2 territory):

Trigger: Catalog Item Submitted (Password Reset)
Action 1: Verify identity (MFA challenge)
Action 2: If verified → Reset password, notify user
Action 3: If not verified → Create incident, assign to Security

Every branch here was written by a human in advance. The flow has exactly two paths, and both were anticipated at design time.

Built as a Virtual Agent chatbot (Chapter 2 territory):

Topic: Password Reset
NLU intent match → "I forgot my password" / "reset my password" / etc.
Conversational script: ask for MFA, call the same underlying flow above,
confirm completion in chat, or escalate if MFA fails.

This adds a natural-language front end on top of the same predetermined branches. The chatbot decides which topic matches what the user typed — it doesn't decide what actions to take once the topic is matched. That's still fixed by the script underneath.

Built as an agent (this chapter's territory):

Goal: "Help the user regain access to their account securely."
Tools available: verify_identity(), reset_password(), check_recent_incidents(),
create_security_case(), lookup_account_lock_reason()

The agent decides, per conversation, which tools to call and in what order.
Example run: user says password won't reset even after a reset was issued →
agent calls lookup_account_lock_reason() on its own initiative (a tool the
flow version never even considered), discovers the account is locked from
repeated failed attempts, and calls create_security_case() instead of
retrying reset_password() a second time.

This is the actual distinction: the agent wasn't told "if reset fails, check for account lock." It was given a goal and a set of tools, and it composed its own sequence based on what the situation in front of it actually was. That's what "agentic" means in practice — not smarter conversation, but a genuinely different locus of control over what happens next.

What to actually learn: before calling anything an "agent," ask who or what decided the sequence of actions — a person at design time, or the system at run time. If it's the former, it's a flow or a scripted chatbot no matter how conversational the front end looks.

2. Agent Studio Basics

Agent Studio is where you define an agent's goal, personality, and — most importantly — exactly which tools it's allowed to call. That tool boundary is the real security and reliability control here, more than any prompt wording.

Example — defining one tool, step by step:

• Start with the narrowest possible version of the tool. For check_recent_incidents(), that means it takes a user sys_id and a lookback window, and returns only incidents that user opened — not a general-purpose incident search.
• Write the tool description the way you'd brief a new hire, not the way you'd write a function docstring — the agent uses this description to decide when to call the tool, so vague wording produces inconsistent invocation. "Checks if this user has any open incidents from the last 7 days related to account access" is far more useful to the agent than "Queries the incident table."
• Scope the underlying role to exactly what the tool needs — this is Chapter 1's ACL discipline again, now applied to a tool rather than a human user. If the tool only needs read access to incidents matching caller_id = current user, don't grant it broader incident read access "just in case."
• Test the tool in isolation before adding it to the agent — call it directly with a few realistic and edge-case inputs (a user with no incidents, a user sys_id that doesn't exist) and confirm the output is something the agent can reasonably act on, not a stack trace.

What to actually learn: an agent is only as safe and predictable as the tools it's given. Spend more design time on tool scoping and description quality than on the agent's overall goal wording — the goal sets intent, but the tools set what's actually possible.

3. Build Agent: a Spec-to-Code Walkthrough

Build Agent is aimed specifically at developer-assist scenarios — taking a specification and producing working code or configuration, with more autonomy than Now Assist for Creator's single-shot generation.

Example — a simple utility, spec to output:

Spec: "Build a Script Include that takes a table name and a sys_id, and returns whether the record exists and its current state field value, handling the case where the table name is invalid."

Unlike a single Text-to-Code prompt, Build Agent's process typically involves it checking its own output against the spec — noticing, for instance, that "handling the case where the table name is invalid" requires wrapping the GlideRecord initialization in a check against GlideTableHierarchy or a similar existence check, rather than letting an invalid table name throw an unhandled error deep in the query.

Where the review discipline still matters: the fact that Build Agent iterates on its own doesn't mean the iteration converges on what you actually meant. If the spec was ambiguous about what "exists" means for a soft-deleted record, the agent will pick an interpretation and run with it consistently — consistency isn't the same as correctness. The review checklist from Chapter 3 still applies here; it just gets applied to a larger, more autonomous unit of output.

What to actually learn: more autonomy in the generation process raises the bar on spec precision, not the bar you need to hold for review. Write specs the way you'd write acceptance criteria for a human developer — explicit about edge cases — because an autonomous build process will fill ambiguity gaps with its own assumption, silently.

4. Where Otto Fits

Otto is ServiceNow's broader agentic positioning, and it's the piece most actively evolving — worth tracking rather than treating as settled.

Where it sits, at a glance:

Now Assist ─────────── generation for a human to review, one shot at a time
Agent Studio ───────── individual goal-driven agents with defined tools
Build Agent ────────── an agent specialized for developer/spec-to-code work
Otto ───────────────── the broader orchestration/positioning layer these
                        agentic capabilities sit under

What to actually learn: don't over-invest in memorizing today's exact positioning of Otto relative to Agent Studio — this layer is genuinely still moving. What's worth internalizing instead is the underlying pattern: individual agents with scoped tools, an orchestration layer above them, and a governance layer that has to hold regardless of what any individual product is named this quarter.

Checkpoint Before Moving to Chapter 5

You should be able to: look at a "conversational AI" feature and correctly identify whether it's actually agentic or just a scripted chatbot with a natural-language front end; scope a tool for Agent Studio the way you'd scope an ACL; write a Build Agent spec precise enough that it doesn't leave edge-case interpretation up to the model; and place Otto, Agent Studio, and Build Agent relative to each other without needing the exact current marketing diagram in front of you. Chapter 5 goes one layer deeper — into how these agents actually reach outside ServiceNow to call external tools and models, which is where the tool-scoping discipline from this chapter gets tested against real integration risk.

Next in this series: Chapter 5 — Action Fabric & MCP, including a side-by-side of the same integration built as REST vs. MCP, and a real cautionary case study from hands-on testing.