The last time I wrote about AI in ServiceNow, I was in the middle of a Now Assist implementation almost 2 years ago. This was, effectively, in the early days of Now Assist - the Xanadu-based features had just come out, and AI Agent Studio had been released to a few select clients. The coming Knowledge 2025 would have AI Agent Studio & Control Tower at the forefront, unveiling the new tag line “Put AI Agents to Work”.
Since then, I’ve run 4 more Now Assist implementations. I’ll have to follow up this note with the scars from all those late nights. But I figured I’d come back and write my second piece at this next pivotal moment - the rollout of EmployeeWorks & Otto, the long-awaited embedding of the Moveworks product within the ServiceNow AI Stack.
I’ll first give a recap of how we got here from Now Assist, how to think about EmployeeWorks/Otto within the Agentic AI market, the good news, and some open questions you should be asking your ServiceNow AE as you are deciding whether to migrate (yes, there is a migration).
The short version
The deal
ServiceNow paid $2.85B for Moveworks - its largest acquisition ever - and turned it into Otto and EmployeeWorks.
The split
EmployeeWorks owns the requester (employee) side, Now Assist owns the fulfiller side, and Otto is the one assistant across both.
The fine print
EmployeeWorks is a separate, Moveworks-based AI stack that runs off-instance - its own place to build agents, its own connectors, its own search layer. It's effectively a new product, and your existing Virtual Agent and Now Assist work doesn't carry over automatically; you'd rebuild it in the new stack.
The move
Don't migrate on reflex. Gauge how deep your existing Now Assist and Virtual Agent investment runs, and press your AE on the licensing, migration, and architecture questions before you sign anything.
What actually happened
A quick recap: ServiceNow bought Moveworks for 2.85 billion dollars, the largest acquisition in its history. It was announced in March 2025, then spent most of the year under a DOJ second request before closing in December. If you enjoy a little drama, the deal looked genuinely wobbly throughout.
Five months after it closed, at Knowledge 2026 in May, Bhavin Shah, Moveworks’ founder and now the GM of Employee Experience and AI at ServiceNow, introduced the next generation of ServiceNow’s employee AI. Three pieces are worth separating out:
- EmployeeWorks: ServiceNow’s official move into the “Employee Front Door” AI space, and a SKU in its own right. It’s the employee-facing side of the house, powered by Moveworks, that takes a request across IT, HR, finance, or facilities and handles the routing, the workflow, the approvals, and the confirmation - so the employee never has to know which system actually did the work.
- Employee Slate: the front end of EmployeeWorks. This is the new, ChatGPT-esque, conversation-first UI that replaces Employee Center - an omnibar where you ask anything, a personalized canvas of widgets, a unified inbox, world knowledge, and enterprise search. Brand new code base, built off-instance on ServiceNow’s AIUX framework (Google’s Lit.js), not a reskin of the old portal.
- Otto: the face of AI at ServiceNow. Whoever you are - an employee on the requester side or an agent on the fulfiller side - the assistant you talk to is Otto. Under the hood it’s the unified experience layer (Now Assist + Moveworks + AI Experience on a new AI-native architecture), and its real job is orchestration: routing each request to the right stack and the right agents and actions underneath, summoning EmployeeWorks for the employee-facing moments and Now Assist for the fulfiller-facing ones. ServiceNow is adamant it’s not a rebrand, and having seen it, I’d agree.
EmployeeWorks & Otto in the (crowded) Employee Front Door Space
We are at the advent of the “Employee Front Door” AI product offering. It tracks with a core concept of really any end-user facing product - meet your users where they are, not the other way around. No swivel-chairing with 10 tabs open. The Employee Front Door knows everything about its user because it’s connected to all the relevant systems where I’m doing work - M365, ServiceNow, Workday, SAP - either via API or MCP. And if those two aren’t supported, remote desktop and/or a Chrome extension fills in the gap.
Who was the first in this space, we can debate all day. But the ones that come to mind first are Glean, Sana, and Copilot Cowork (which only hit GA this June).
One mental model that helps is that some of these companies started with Enterprise Search, then moved into ‘tools’, and others went the opposite way. Glean, for instance, started as Enterprise Search, nailed down the context graph, and is actively moving into more and more connectors for that 360 understanding of how desk workers do their jobs. Sana went the opposite route - and one of the reasons why Workday bought them.
EmployeeWorks sees itself as the latter - tools and system-of-record connectivity first. Prioritizing SN, obviously.
Requester vs Fulfiller
Before we get into Otto, the one distinction that makes the rest of this make sense: requester versus fulfiller. The requester is the employee - the person whose VPN certificate just died and wants a new one. The fulfiller is the team on the other side actually working that ticket. EmployeeWorks owns the requester experience; Now Assist owns the fulfiller experience. Same problem, opposite ends of it.
The part that trips people up is that Otto sits across both. The employee asking and the agent resolving are both talking to Otto - it just summons a different stack underneath depending on which side of the request you’re on. Time will tell how cleanly that separation of powers holds in practice, but that is the design.
Otto
So if Otto is the face across both sides, what is it actually doing? Orchestrating. Otto is the thing you talk to; the work happens in whatever stack it summons behind the scenes. The clearest way to show it is to walk one request end to end.
Say I’m an employee, I go into Employee Slate, and I type “I need a new laptop shipped to me.” I’m talking to Otto. Because this is an employee-facing, request-creating moment, Otto calls the EmployeeWorks stack. EmployeeWorks reasons through what it needs to properly answer the question, summons the right service catalog item, fills in what it can, and creates the request. I never left the conversation.
Now say it’s the kind of request that needs a human check before approval. The fulfiller picks it up and opens it in their ServiceNow workspace. At that point Otto summons Now Assist for the agent-assist side of the experience. Same Otto, different stack: it tells the fulfiller “here’s what this request is, here’s the employee, and here are the four or five things I’d check before approving,” pulling data from other systems to back it up.
Once the fulfiller clears the validation and the request is fulfilled, any outbound notification or follow-up that lands back on the employee side is, again, Otto - this time summoning EmployeeWorks.
That’s the whole mental model. One face, Otto, on every surface. Underneath, it routes to EmployeeWorks for the requester moments and Now Assist for the fulfiller moments, and neither the employee nor the agent ever has to know which stack did the work.
The Good
Moveworks is, and always has been, a conversational AI company
Hot Take: The quality of a conversational AI product differs depending on two simple questions:
- Is the company’s primary purpose creating a great conversational AI experience, or is conversational AI simply bolted onto a broader product strategy?
- OR does this company have a long history (5+ years) of making kickass conversational AI product(s)?
I made this point before in front of a Fortune 100 company, and got some stick from a vendor in the room who shall remain nameless. That vendor was neither a 1 nor a 2. In an age where every platform bundles a conversational AI offering into its license, I think time has proven the point: making a genuinely good conversational AI product is an art, not a RAG pipeline bolted onto the latest Anthropic or OpenAI model.
Back to ServiceNow, I’d argue two things.
Number one: the acquisition of Moveworks is just another chapter in ServiceNow’s history of acquiring conversational AI companies to augment a platform that wasn’t AI-native to begin with, or at least didn’t use to be. The first example was Parlo in 2018, followed by Passage AI in 2020. Obviously, Moveworks is an order of magnitude larger from an acquisition perspective.
Number two, and back to my original point: Moveworks was, and still is, a conversational AI company. They don’t have a portfolio of unrelated products. Their primary raison d’être is the conversational experience itself.
Now, maybe Moveworks didn’t have the horsepower of some of the bigger players like AWS Lex, Google Dialogflow, or Watson Assistant. But it absolutely was - and still is - a very competitive player in that independent conversational AI category. Moveworks, Kore.ai, those guys were always hot on the heels of the hyperscaler convo AI products.
The fact that it’s now being embedded into ServiceNow brings not only the technical aspects of conversational AI into the platform, but also all of the little nuances that are required to actually make a good conversational experience.
I’m not going to go into all of those here because that deserves its own article, but the logic is fairly self-explanatory. Moveworks has spent more than half a decade building a world-class conversational experience. Everything from the technology, to the UI/UX, to the human-computer interaction element.
Now ServiceNow inherits all of that.
And honestly, without going into too much detail, and with all due respect to my SN colleagues, I think Now Assist certainly needed this. Again, that’s probably a different article.
Technically, Now Assist was a strong virtual agent platform. It actually surprised me in a few areas. Through multiple deployments, one thing that consistently impressed me was the lack of hallucinations, the groundedness of the responses, and the consistency of the answers. But there were still a few quirks that never quite felt right, especially coming from a background of building virtual agents on IBM Watson, AWS Lex, and similar platforms.
Bottom line… ServiceNow AI now has a true conversational AI pure play inside the platform.
This is genuinely exciting.
The overhaul of the UI/UX
What else did they get right? The UI/UX overhaul, and the entirely new flow that comes with it.
We touched on it in the last section, but this is a fundamentally different way of approaching embedded AI in the requester’s lifecycle.
Before, Now Assist was trying to play along with the existing ServiceNow stack. The requester experience through Now Assist was trying to fit into what already existed. We had Service Portal, and then we embedded the Virtual Agent into it. The Virtual Agent UI itself went through several iterations, eventually becoming that familiar two-sided panel.
But there was always something that felt grafted on. It never quite felt like conversational AI was the core experience. It felt like another feature inside the existing portal, rather than the experience itself.
This is a different take entirely. It aligns with where the market is heading on the Employee Front Door, and where it’s heading on adoption and repeat usage. And it really creates what is essentially a coworker - a human-first approach where AI is always there.
I think it’s the right call. They’ve flipped the requester experience on its head, and we’ll talk about some of the implications of that in a moment.
A completely new architecture
The next piece - and you can take this as a good thing or a bad thing, since we’ll cover the downside in a moment - is that this is a wholly new architecture. And it is bigger than the UI.
The temptation is to fixate on the front end, because that is the visible part. And it is real - this is a different framework entirely, built off-instance on Kubernetes using ServiceNow’s new AIUX framework (Google’s Lit.js). ServiceNow says so directly: it is “not a revamp of Employee Center,” it is a new code base. But the front end is the least interesting part of the change. The bigger story is that this is a completely different AI stack, end to end. It does not extend Now Assist. It connects to ServiceNow through a Graph API, but it is not part of ServiceNow.
The new AI stack
If you’ve looked at any conversational AI platform in the last 10 years, the shape will be familiar. ServiceNow’s own framing is a three-layer sandwich: an experience layer (what the employee sees and touches), an intelligence layer (the agentic reasoning engine, where the decisions get made), and a tools and integration layer (where it reaches into your real systems - connectors, plugins, MCP, enterprise search). Underneath all of it sits platform management: telemetry, audit logs, analytics, access controls, the governance plumbing.
None of that is new as a pattern. The engagement / intelligence / tooling sandwich has been around for a decade. What is new is the agentic middle. Instead of a static intent-to-answer mapping, the intelligence layer runs a live loop - sense the request and its context, plan the steps, execute the tools, present the result - and it does it in seconds.
The practical consequence: the old Virtual Agent Designer is effectively gone for anything you build in EmployeeWorks. If you’re building something new, you’re building it in the Moveworks authoring experience, not the classic ServiceNow one. And honestly, that’s a good thing - the classic Virtual Agent Designer always felt tacked onto the platform, and building agents in Moveworks is genuinely fun: quick, responsive, the kind of maker experience that pulls you in. What this means for everything you’ve already built in Virtual Agent Designer, though… that remains to be seen.
Employee Slate
The other half of “new architecture” is the front end itself: Employee Slate. This is the part the employee actually touches, and it is a full revamp, not a face-lift on Employee Center. The whole experience is organized around an omnibar - you ask, and the conversation takes it from there - with a personalized canvas of widgets, a unified inbox, world knowledge, and enterprise search built in. The interaction model is the two-sided panel you’d expect from an AI-first product: the conversation on one side, the content or the form it is acting on right alongside it.
Points of Consideration
There are a few things we know so far about the introduction of EmployeeWorks that will particularly affect current Now Assist customers.
Licensing
If you’re under the legacy Now Assist contracting model, EmployeeWorks will be a new license. If you purchased Now Assist any time from 2023 through early 2025, you’re likely under the original hybrid seat & assist-based Now Assist model.
ServiceNow’s own materials describe Employee Slate as bundled into existing SKUs rather than sold standalone. But in practice, getting the Moveworks-powered experience is its own commercial motion - new paper, a new conversation with your AE - and the delta is still unknown publicly.
This matters because EmployeeWorks is not replacing Now Assist. And to be clear, Now Assist isn’t going anywhere. There are no announced plans to deprecate anything you’ve already built in Now Assist.
But going forward, the requester experience - the employee-facing AI, anything interacting directly with your employees - is clearly moving toward EmployeeWorks. That’s the platform ServiceNow is investing in.
Does that mean you can’t build requester-facing agents in Now Assist anymore? Absolutely not. You can still build them.
But it’s not hard to imagine a world where all of the exciting new requester-facing innovation and engineering effort goes toward EmployeeWorks. That leaves Now Assist primarily focused on the fulfiller experience. Anything helping your help desk agents inside Agent Workspace, Agent Assist, or similar fulfiller experiences continues to live within Now Assist. That’s the overall direction ServiceNow appears to be taking.
So, back to licensing: it’s a separate product, and it’s worth talking with your Account Executive about what it means for your organization, especially the difference between someone who bought Now Assist two years ago versus six months ago.
That’s the first point of consideration.
Migration
The second point is migration. Your existing Virtual Agent Designer topics will not automatically migrate into the EmployeeWorks / Otto authoring experience. I’ll say that again. They will not migrate automatically. There is no magic migration button.
There is no magic migration button.
What that migration looks like depends heavily on how you’ve used Now Assist and Virtual Agent over the last couple of years. From my conversations with clients, I generally see four categories.
Category 1: Heavy Virtual Agent customization
These are organizations that went well beyond out-of-the-box. They’ve built sophisticated Virtual Agent topics with JavaScript, Script Includes, CRUD operations inside ServiceNow, Integration Hub actions, custom APIs, etc.
If this is you, you probably have a significant migration effort ahead.
How easy/hard the migration will be is the next question. For the moment, there really is only one firm with the know how - Moveworks Professional Services, or SN Professional Services rather. Not exactly the competitive landscape, yet, that caters to price competition.
Category 2: Mostly out-of-the-box Now Assist
I also see a surprising number of customers in this category. These are organizations that purchased Now Assist as part of a broader renewal or platform agreement but never heavily customized it. Their environment typically consists of:
- Out-of-the-box topics
- A few branding changes
- Welcome and exit node customization
- Genius Search
- Conversational Catalog
- Maybe a handful of additional topics without much custom logic
If this sounds familiar, your migration will likely be much simpler. Most of the value in your implementation already comes from capabilities that EmployeeWorks naturally builds upon. In other words, this isn’t so much a migration as a platform shift.
Category 3: ServiceNow without Now Assist
The third category is interesting. These are organizations that use ServiceNow extensively but never adopted Now Assist. Instead, they built their own AI layer using one or more hyperscalers or enterprise AI platforms. ServiceNow remains the system of record and system of action, while the intelligence lives somewhere else. Maybe that’s AWS. Maybe Azure. Maybe Google Cloud. Maybe it’s an enterprise AI platform serving multiple business applications.
For these organizations, migration isn’t really the question, because there’s very little to migrate. The question is whether EmployeeWorks is compelling enough to justify changing that architecture. It’s less about migration and more about whether the requester experience is finally strong enough to bring conversational AI closer to the ServiceNow platform.
I’d also keep a close eye on how the platform itself evolves over the next few releases. As EmployeeWorks becomes more central to ServiceNow’s strategy, expect the interfaces, APIs, and integration patterns around it to keep moving. If you’re integrating custom AI today, build against supported, documented extension points, not whatever happens to work right now. The teams that assume the platform will shift under them are the ones who won’t be redoing this work in a year.
Category 4: Greenfield
The final category is the easiest. You’re just getting started. You haven’t invested in Now Assist or Virtual Agent yet. There’s nothing to migrate. You can simply begin building on EmployeeWorks from day one.
Ironically, this is probably the group with the least complexity, while long-time Now Assist customers have the most architectural decisions to make. That’s often how platform transitions go.
Questions to your AE
Here’s the list I’d walk into the room with. Be specific. “It’s all unified now” is a marketing answer, not an architecture answer, and the difference is going to show up in your next statement of work.
1. Search and relevancy. Does EmployeeWorks reuse my existing Genius Search setup - search profiles, indexed sources, source weighting, synonyms, and my tuned Genius Results - or does Moveworks stand up its own index over the same content? If it’s a separate index, I’m now tuning two search engines over the same knowledge bases, and I want to know who owns relevancy, how reindexing and freshness work, and what happens to the months of tuning I’ve already paid for.
2. Knowledge permissions. Does Moveworks enforce my ServiceNow KB user criteria and read ACLs at query time, or does it snapshot permissions when it indexes? How is permission trimming handled across non-ServiceNow sources like SharePoint and Confluence? And when someone changes roles or loses access, how fast does that propagate? Permission drift between two systems is exactly where these deployments earn a finding from your security team.
3. Migration and deployment tooling. Two halves here. First, migration: we already know there’s no automated path from Virtual Agent Designer today - you rebuild your topics and flows by hand - so is automated migration tooling on the roadmap, and when? Second, deployment: how do I promote an EmployeeWorks or Otto agent from dev to test to prod? Now Assist, for all its quirks, at least rode the Update Set rails that thousands of ServiceNow developers already know. If EmployeeWorks runs off-instance, do Update Sets even apply, or is there a separate AgentOps and promotion mechanism I have to learn and govern from scratch?
4. Integration Hub vs Moveworks connectors. Can Otto invoke my existing Integration Hub spokes, flows, and actions directly, or do I rebuild those integrations as Moveworks connectors and plugins? EmployeeWorks connects to ServiceNow through a Graph API and runs as its own platform, so this is genuinely a second integration estate, not an extension of mine. If both can reach the same downstream system, which one owns the action at runtime - and how do I avoid maintaining two integration layers, two sets of credentials, and two change windows to the same endpoints?
5. AI Agent Studio interop. Can the agents I built in ServiceNow AI Agent Studio be registered as domain agents that Otto routes to, and what’s the handoff contract for context, auth, and state? Or do I rebuild them in Moveworks’ Agent Studio? And where does Action Fabric, the agent interop layer they announced at Knowledge 2026, fit - can Otto call out to third-party agents, and can external orchestrators trigger my governed ServiceNow actions?
6. Channels. Do my existing Virtual Agent channel integrations - Teams, Slack, Employee Center, mobile, the web widget - carry over, or are they re-provisioned through Moveworks’ own channel apps? If the Moveworks Teams app replaces my current Virtual Agent Teams integration, what happens to the deep links, proactive notifications, and conversational catalog already live in those channels?
7. Analytics, governance, and continuity. Is there one reporting layer across the fulfiller side (Now Assist) and the requester side (EmployeeWorks and Otto), or am I stitching together six or seven tables across two stacks to reconstruct one employee’s journey? I want deflection, containment, resolution, and CSAT in one place. Does Otto run under AI Control Tower - logging, guardrails, model routing, data residency - across both, or does governance fork between the two stacks? And when Otto hands a thread from EmployeeWorks to Now Assist and back, does context actually carry - the conversation, the employee, the request history - or does each side start cold?
8. The data boundary. Moveworks indexes and reasons off-instance, on its own cloud. So what content actually leaves the ServiceNow trust boundary, where is it stored, what’s the retention, and how does that square with the data residency and DLP commitments I’ve already made to my security and privacy teams?
If your AE can answer all eight cleanly today, I’d be impressed, and I’d want to hire them. Most of these don’t have public answers yet, which is exactly why you ask them now - before the SOW is signed, not after.
Excited, and a little wary
I’m not here to tell you to migrate or to sit tight. This is the lay of the land, not a sales pitch in either direction. Your move depends on which of those four categories you’re in, and you already know which one that is.
What I will say is this: it’s exciting. After years of bolting conversational AI onto the platform, ServiceNow finally has a real conversational AI stack inside it - a pure play, Moveworks-grade, built the way these things should be built. For anyone running ServiceNow, that’s a genuinely good day.
But excited and wary can share a sentence. New architecture, new license, a real migration with no magic button, and a stack of questions your AE can’t fully answer yet. None of that makes the move wrong. It just makes it a decision worth making with your eyes open.