At Knowledge 2026, ServiceNow introduced Otto — a unified AI experience layer that sits above Now Assist, Virtual Agent, and the rest of the platform, deciding which system or agent should handle a request and executing it end to end. It's already live inside ServiceNow EmployeeWorks and AI Control Tower, with a full rollout across the platform planned over the coming year.
If your first reaction was "don't we already have an assistant for this?" — you're asking the right question. This guide walks through what Otto and EmployeeWorks actually add on top of Now Assist and Virtual Agent, how they're built, what they cost, and — just as importantly — the practitioner-level questions worth asking before you bring this into your own instance: roles, clone behavior, integration impact, and what happens when it gets something wrong.
1. What Problem Is Otto Actually Solving?
Most enterprises already have AI everywhere — a copilot in the ticketing tool, a chatbot on the intranet, a summarizer inside the CRM. Each one works reasonably well in isolation, but none of them talk to each other, and none can see past the system it lives in. Employees still switch tabs, chase approvals, and repeat themselves to every tool that doesn't remember the last conversation.
What Otto changes
- Employees describe what they need in plain language — no portal-hunting, no knowing whether it's an ITSM incident, an HR case, or a GRC exception.
- Otto understands intent, decides which agent or workflow should handle it, and routes across departments without the employee orchestrating anything themselves.
- Every action — human-initiated or agent-initiated — is logged, policy-enforced, and explainable through AI Control Tower.
Otto is not sold as a separate SKU, and it's not a rip-and-replace of anything you've already built. It's an experience layer that runs on top of the ServiceNow AI Platform, unifying Now Assist, EmployeeWorks, and AI Experience into one governed interface.
2. The Layered Architecture: Otto, EmployeeWorks, Now Assist, and Virtual Agent
The naming gets confusing fast, so it's worth anchoring on the layers rather than the product names. Four layers, bottom to top: Now Platform (execution — workflows, data, the engine everything runs on), Now Assist / Virtual Agent (capability — smarter within one module, but still bound to it), EmployeeWorks / AI Agents / Action Fabric (the layer that actually acts — built-in agents like Build Agent, or external agents like Claude and Copilot connecting in through Action Fabric), and Otto at the top (experience — decides where a request goes and orchestrates it). AI Control Tower wraps around all four layers as governance, not as a tier of its own.
The part worth remembering: nothing in the lower two layers goes away. Now Assist and Virtual Agent keep doing exactly what they already do. Otto doesn't replace them — it decides when to hand a request down to them versus routing it somewhere else entirely. If you've invested in Virtual Agent topics or Now Assist skills, that work carries forward; it just stops being the only front door.
3. What Actually Makes This "Agentic"
"Agentic AI" gets used loosely, so it's worth being precise. Generative AI answers or drafts — you ask, it produces something, you still decide and click. Agentic AI plans a sequence of steps toward a goal and executes them, often across system boundaries, without a human performing each individual step.
Where Otto fits that definition
- Intent understanding — parsing what's actually being asked, not matching a keyword to a topic flow.
- Autonomous routing — deciding which agent or department handles the request without a human pre-wiring the path.
- Cross-system execution — acting across systems through a shared, governed runtime rather than staying inside one module.
One distinction worth getting right when explaining this to others: Otto itself isn't "an agent" in the singular sense — it's an agent orchestrator. Individual AI Agents (Build Agent, ATF Troubleshooting Agent, and anything built with Now Assist for Creator) do the bounded task work. Otto sits above them and decides which one gets invoked for a given request. Conflating the two is the single most common mix-up in this space.
4. How Otto Accesses Data: Roles, ACLs, and Agent Identity
This is the question every security-minded architect asks first, and the honest answer is: it's not magic, it's still your existing ACL and role model, just invoked by an AI instead of a human clicking through the UI.
What holds true
- Otto and its agents act as the requesting user, not as a superuser — if an employee's role doesn't grant visibility into a record, an agent acting on their behalf shouldn't surface it either.
- Cross-system reach runs through Action Fabric and the MCP Server, which consume the same Assist licensing model as Now Assist and AI Agents — agent-driven actions are governed and metered the same way human-driven ones are, not through a side door.
- Agents themselves are increasingly getting their own scoped, least-privilege identity — tracked separately from the human they're acting for — rather than inheriting a blanket service account.
Practical implication for admins: your existing ACL hygiene work isn't obsolete — it's the foundation this depends on. Role-less ACLs, over-broad data conditions, or table-level access gaps don't get safer just because an AI is making the request instead of a person; if anything, they get exercised more often, since Otto is designed to be asked things constantly.
5. When Otto Can't Resolve It: Ticket Creation and Escalation
Resolution isn't the only outcome Otto is designed for — escalation is a first-class fallback, not an afterthought.
The pattern
- Attempt resolution first, against knowledge articles, catalog items, and workflow actions.
- If it can't close the loop, generate the incident or case itself — pre-filled with the conversation context, not a blank form the employee has to re-explain everything into.
- Route to the correct assignment group automatically, and let the employee track status through the same conversational interface rather than a separate portal.
The context pre-fill is the real time-saver on the fulfiller side — L1/L2 teams inherit a ticket that already has the conversation history attached, instead of starting cold.
6. AI Control Tower: Governance as a First-Class Layer
Every Otto interaction — and increasingly, every AI action on the platform regardless of source — passes through AI Control Tower.
What it actually does
- Discover — inventories AI models, agents, datasets, and prompts across 30+ enterprise integrations, including non-ServiceNow environments like AWS, Azure, GCP, SAP, and Workday.
- Observe — runtime visibility into how an agent reasoned and where it made a decision, not just what it returned.
- Govern — risk assessment aligned to frameworks like NIST and the EU AI Act, with compliance controls out of the box.
- Secure — least-privilege identity enforcement extended to every AI system, agent, and human identity.
- Measure — cost and ROI dashboards, since AI token consumption is now a metered line item, not a flat fee.
The most operationally important piece here is real-time containment: AI Control Tower is designed to detect when an agent operates outside its intended permission boundary and shut it down automatically, generating a security incident and audit trail in the same motion — an enforcement point, not just a monitoring dashboard.
7. What Can Break: Failure Modes Worth Knowing
Yes, this can misdirect or misguide a user — and it's more useful to your team to name the specific failure modes than to wave generally at "AI can be wrong."
The failure modes, and the mitigation for each
- Misrouting — an ambiguous request gets sent to the wrong department or system. Low-stakes: an extra hop. Higher-stakes: an HR-sensitive case routed through a channel without the right confidentiality controls. Mitigate with clear category boundaries and periodic routing audits, the same discipline you'd apply to Virtual Agent topic design.
- Hallucination — a confident answer that isn't grounded in your actual data. AI Control Tower is explicitly built to surface where this is happening, not to pretend it doesn't.
- Over-scoped or drifting agent behavior — an agent acting outside its intended permission boundary. This is exactly what real-time containment exists for.
- Model or data drift — a model that routed correctly at rollout can quietly degrade as your CMDB, org structure, or workflows change underneath it. AI Control Tower generates drift alerts, but someone still has to act on them.
- Autonomy level mismatch — whether a given workflow should run fully autonomous or human-in-the-loop is a real configuration decision, not something the platform forces on you either way. Get this wrong and you either lose the efficiency gain or take on more risk than the use case warrants.
8. Platform Requirements: Release, Licensing Tier, and Plugins
There isn't a classic "install this plugin" checklist here, which trips people up if they're expecting one.
What you need in place
- Otto is an experience layer, not a separately licensed product — it runs on top of Now Assist, AI Control Tower, and EmployeeWorks (which itself bundles the Moveworks-derived conversational front door). Confirm those are provisioned rather than looking for an "Otto plugin."
- Release-wise, this is surfacing with the Australia release; if you're still on an earlier family, this is one more reason to prioritize the upgrade path.
- Licensing runs through ServiceNow's current three-tier model — Foundation, Advanced, and Prime — with Otto's underlying components bundled at every tier, and fully autonomous agent capability reserved for Prime. What changes across tiers isn't whether the AI is present, it's how autonomously it's allowed to operate.
9. Clone Behavior and Integration Impact — What to Validate, Not Assume
This is genuinely new enough that ServiceNow hasn't published Otto-specific clone documentation yet — which makes it worth treating as an open validation item rather than assuming it behaves like anything you've cloned before.
What to check before you assume anything survives a clone
- AI Control Tower's registered integrations and model bindings — treat these like the API keys and OAuth tokens you already know don't survive a clone cleanly, until proven otherwise on your own instance.
- Agent skill and topic definitions — verify whether these clone as configuration or need re-registration per environment.
- Existing IntegrationHub spokes touching Employee Center, Virtual Agent, or HRSD — these have historically followed independent release cycles from the core family upgrade and needed separate post-clone validation; there's no reason to expect EmployeeWorks-related spokes to behave differently.
- Any point-to-point integration with external agent platforms (Copilot Studio, custom agents) that predates your Action Fabric adoption — these are candidates to re-map through Action Fabric's governed runtime rather than left running outside it.
The honest position to take with stakeholders: don't assert clone behavior you haven't verified on your own sub-production instances. Build a specific clone-validation pass for AI Control Tower and EmployeeWorks configuration into your next lower-environment refresh, and treat the results as your actual documentation — not a vendor datasheet.
10. Skills Your ITSM and Dev Teams Will Actually Need
The good news: this isn't a brand-new skill stack from zero. It's your existing ServiceNow skill set, plus three additions.
What to build now
- Conversational and agent design — extends directly from Virtual Agent NLU/topic work most teams already have.
- AI Agent orchestration — comfort building with Now Assist for Creator and Build Agent, since dev teams building custom scoped apps will increasingly work through this agent rather than only by hand.
- AI governance literacy — reading AI Control Tower dashboards, drift alerts, and explainability logs. This is the genuinely new muscle, closer to observability/SRE work than classic ServiceNow administration.
On timing: don't wait for "Otto" specifically to land on your instance before upskilling. Now Assist and AI Agent fluency transfers directly, and the platform readiness work — clean CMDB/CSDM data, documented workflows, defined AI governance ownership — is the actual prerequisite regardless of how far the Otto rollout has reached. That foundation work realistically takes many months, which lines up well with a CoP-driven, phased upskilling plan rather than a scramble.
11. Cost for Existing Customers: What's Bundled, What's Metered
This is more favorable than most new platform capabilities, with one important variable cost to model carefully.
The shape of it
- Every current tier — Foundation, Advanced, Prime — includes Otto's underlying components automatically; what changes across tiers is autonomy level, not presence.
- Capabilities that were previously separate purchases — a subset of EmployeeWorks, Workflow Data Fabric, AI Control Tower, and a Context Engine — are now folded into the tiers.
- The Moveworks-derived conversational layer ships as a bundled SKU rather than a separate procurement.
- The variable to actually watch: AI token consumption. Each tier includes an Assist pool, and usage beyond it is metered — model this as a variable line item, not a flat fee, when you budget.
Confirm the specifics with your account team rather than treating any public figure as authoritative — ServiceNow's pricing remains custom-quoted, and third-party estimates vary.
12. Now Mobile, and How Otto Compares to Market Alternatives
Otto is designed to reach employees through conversational chat, enterprise search, voice, and mobile — it's explicitly not a desktop-only experience, and ServiceNow's own mobile documentation now leads with Otto messaging directly.
Where it sits against the market
- Microsoft Copilot — positioned as interoperable rather than purely competing; Copilot is a named design partner for Action Fabric, meaning employees already living in Copilot can trigger governed ServiceNow actions without switching tools.
- Point-solution AI helpdesk tools (Workativ, eesel AI, and similar) — compete on cost and simplicity for teams that don't want a platform rip-and-replace, but don't offer the same cross-departmental orchestration depth.
- BMC Helix, Freshservice, Jira Service Management — traditional ITSM competitors layering on their own AI, generally narrower in scope than Otto's cross-system ambition today.
Final Thoughts
Otto and EmployeeWorks aren't a rebrand of Now Assist, and they're not a reason to throw out anything you've already built on Virtual Agent. What's actually new is the orchestration layer above them — the piece that decides which system should handle a request, executes across boundaries, and governs the whole thing through AI Control Tower rather than leaving governance as an afterthought bolted onto each integration separately.
For practitioners, the questions worth carrying forward aren't "will this replace my job" — they're the ones this guide walked through: what roles does an agent actually need, what happens during clone, which integrations need re-mapping, and where does autonomous execution need a human in the loop. Those don't have one-size-fits-all answers. They're the kind of judgment calls that separate a team that's read the keynote from one that's actually ready to run this in production — and getting ahead of them now is exactly the kind of thought leadership worth bringing to a CoP or POD conversation before someone else frames the narrative for you.