AI & Now Assist

ServiceNow's generative AI capability layer, embedded in the workflows: summarizing incidents and cases, drafting resolution notes and knowledge articles, suggesting agent responses, chat summarization for handoffs, and code/flow generation for developers. Powered by the Now LLM service (with bring-your-own-model options), surfaced as skills activated per module.

• Incident/case/chat summarization (the flagship skill).
• Resolution notes generation at close.
• Knowledge article generation from incidents/problems.
• Response suggestions for agents in Workspace.
• Now Assist in Virtual Agent — LLM-backed Q&A over knowledge.
• Creator skills: text-to-code, flow generation.

It compresses reading and writing: a new assignee gets an instant summary of the ticket history instead of scrolling forty comments; at resolution, it drafts resolution notes from the work notes; handoffs and escalations carry auto-summaries; and suggested responses speed customer communication. The measurable effects interviewers want to hear: reduced handle time and better-documented closures.

The developer-facing skills: describe logic in natural language and get script suggestions in the editor (text-to-code), generate flows from descriptions (text-to-flow), and app-building assistance in App Engine Studio. Positioning answer: it accelerates skilled developers rather than replacing platform knowledge — generated script still needs review against your code standards.

Virtual Agent is the conversational bot framework (topics, NLU, chat channels) that end users talk to. Now Assist is the generative AI layer that can power VA conversations (LLM-backed answers, generative topic handling) and also serves agents and developers outside chat entirely. VA is a channel; Now Assist is a capability set that upgrades it.

AI Search (from the Attivio acquisition) replaces keyword Zing search with semantic, ML-ranked retrieval: intent understanding, typo tolerance, result genius cards, and per-user relevance respecting security. It matters doubly in the AI era: it's the retrieval backbone under Now Assist Q&A and RAG-style grounding.

Predictive Intelligence is the older classification/clustering/similarity ML framework — trained on your data to predict category, assignment group, priority (no text generation). Now Assist is generative — LLMs producing text and actions. They complement: PI routes the incident; Now Assist summarizes and drafts. "Discriminative vs generative" is the crisp one-liner.

The framework for building custom generative AI skills beyond the OOB set: you define the prompt, ground it with instance data (records, search retrieval), pick the model, set guardrails, test, and deploy the skill into workspaces/flows. It's how "summarize this contract clause for procurement" becomes a first-class platform skill.

• Skill definition — name, inputs (record/fields/params), output shape.
• Prompt — instruction template with grounding data injected.
• Grounding/retrieval — record data or AI Search results fed as context.
• Model selection — Now LLM or a registered external model.
• Guardrails & post-processing — filters and format enforcement on output.
• Deployment surface — UI action, workspace panel, flow action.

Per-product skill packs: ITSM (incident summarization, resolution notes, KB generation), CSM (case/chat summarization, response drafts), HRSD (case summarization with HR-appropriate confidentiality), ITOM (alert analysis), Creator (code/flow generation), Virtual Agent (generative Q&A). Licensed and activated per module through the admin console.

The central place to manage the generative AI estate: activate/deactivate skills per module, choose model providers, configure data-sharing and guardrail settings, and monitor usage and adoption metrics. Governance headquarters — the answer to "how do you control what AI is on?"

Usage dashboards per skill: invocations, acceptance/edit rates of generated content, active users, deflection. The metric hierarchy worth quoting: acceptance rate beats raw usage (are humans keeping the output?), and downstream outcomes (handle time, deflection) beat both. High invocation + low acceptance = a skill that needs prompt/grounding work.

Layers: input/output content filters (toxicity, PII handling), grounding constraints (answer only from provided context to limit hallucination), data privacy controls over what leaves the instance, role/ACL gating of who can invoke skills, and human-in-the-loop by design — generated text lands as an editable draft, never an automatic customer-facing send.

Same skill families, stricter data posture: HR cases carry sensitive personal data, so summarization respects HR security (case confidentiality, restricted access models), skills are scoped to HR personas, and outputs must avoid surfacing protected details to unauthorized viewers. The interview point: generative AI inherits the module's security model — HRSD proves you understand that.

Baseline first, then compare: average handle time and time-to-first-response, resolution note quality/completeness, KB article production rate, VA deflection rate, and agent satisfaction. Attribute honestly (A/B by team if possible), and net out the license cost. Saying "measure acceptance rate as the leading indicator, MTTR as the lagging one" shows real deployment thinking.

The guided prompt-authoring workspace: templates and patterns for writing effective skill prompts, with placeholders for grounding data, tone/format instructions, and iteration against test inputs. It turns prompt engineering from freestyle into a reviewable artifact.

The catalog of LLMs a skill may target: Now LLM (default, in-platform) and registered external providers (e.g. Azure OpenAI) with their connection and data-handling configuration. It matters because model choice is a governance decision — data residency, cost, capability — made once in the registry, not per developer whim.

Prompt-level constraints ("answer only from the provided context; say 'unknown' otherwise"), input sanitization of user-supplied text, output filters (content moderation, PII masking, format validation), retrieval restricted to approved sources, role-gated invocation, and mandatory human review surfaces for the output. Defense in depth — no single guardrail suffices.

The output of one skill feeds the input of the next — extract facts → summarize → draft communication — typically orchestrated in a flow. Right when stages need different grounding/models or intermediate human checkpoints; wrong when one well-prompted skill would do (each hop adds latency, cost and error compounding). Chain for auditability, not for fun.

Test against representative inputs in the kit → publish the skill → expose it (workspace UI action, flow action, VA topic) → activate per audience in the admin console → monitor acceptance/usage → iterate on prompt and grounding as a versioned change through nonprod first, like any other configuration.

Reproduce with the actual case → inspect what grounding the skill received (thin or noisy ticket data in, garbage out) → check knowledge sources feeding retrieval (stale/missing articles) → review skill configuration and any custom prompt changes → check whether "irrelevant" clusters on a category or team (data problem) or is universal (configuration problem) → fix the input side first; the model is rarely the root cause.

Now LLM — ServiceNow-hosted, processing within the ServiceNow environment under the platform's data agreements. Avoid registering external providers for those skills, and verify the data-sharing settings in the admin console. If even that fails policy, the conversation becomes contractual/legal, not technical — knowing where the line sits is the answer.

Keep VA's deterministic topics for transactional flows (reset password, order laptop — where predictability wins) and add Now Assist generative Q&A as the fallback for the long tail of questions topics don't cover, plus LLM summarization of chat handoffs to live agents. Generative answers augment the catalog of topics; they don't replace flows that must behave identically every time.

Confirm the "why" (policy? existing Azure commitment?) and data-governance sign-off → register the provider in the model registry with endpoint/keys via connection & credential records → point the summarization skill at that model in the admin console → validate output quality side-by-side with Now LLM → document data-flow implications (case text now transits Azure) for security review. Configuration is easy; governance is the deliverable.

Constrain the grounding: restrict the skill's retrieval to designated, curated knowledge bases (AI Search sources), prompt-constrain to provided context only, and keep the human gate — generated articles land in a draft state within the KB's normal approval workflow, never direct-published. Approval workflow + curated sources covers both ends.

Ingest runbooks into a knowledge base indexed by AI Search → skill takes the incident as input → retrieval step pulls the top matching runbook sections (grounding) → prompt instructs: propose remediation steps from these sections only, cite the source → output surfaces as a workspace panel suggestion with links. RAG-on-platform, with the citation requirement as the trust anchor.

Collect failing vs passing examples → diff the inputs (inconsistent grounding is the usual culprit — variable record quality) → tighten the prompt: explicit output format, few-shot examples, lower creativity settings where exposed → constrain retrieval variance → re-test on a fixed evaluation set so "fixed" is measurable, then version the prompt change like code.

High-stakes, so: Now LLM or an approved in-tenancy model (contracts are maximally sensitive), attachment text extraction into controlled fields, a structured output template (clause → risk level → rationale → citation), role-gated to legal, output always a draft attached for attorney review with an explicit "AI-generated, verify before reliance" banner, and full audit of inputs/outputs. Position the skill as accelerating review, never replacing legal judgment.

A chatbot follows authored conversation paths; agentic AI is given a goal and autonomously plans and executes multi-step work — reasoning about which tools to use, acting, observing results, and iterating until done or escalating. VA answers "what do you want?"; an AI agent answers "consider it handled." The defining properties: goal-orientation, tool use, and iterative reasoning.

A task agent does one bounded thing well (categorize this incident, draft this summary). An AI Specialist is role-scoped — it owns a slice of a job (an L1 IT specialist handling password resets, triage and routine requests end-to-end), composing many task-level capabilities under one persona with its own KPIs. Task = function; specialist = role.

Platform-native agentic AI: configurable agents (built in AI Agent Studio) that pursue goals using instructions, knowledge, and a tool library (record ops, flows, retrieval, scripts), coordinated by the AI Agent Orchestrator, operating inside the platform's security and audit model. OOB agents ship for common ITSM/CSM/HR use cases; you build custom ones for yours.

A reasoning loop: the LLM evaluates the goal, its instructions, the context (record data, conversation, prior steps) and its available tools; picks a tool; observes the result; and re-plans — repeating until the goal is met, a guardrail stops it, or it hands off to a human. The available-tools list and the instructions are your control surface over that loop.

The coordination layer above individual agents: it receives the objective, decomposes it, routes sub-tasks to the right specialist agents, sequences their work, manages shared context between them, and consolidates the outcome — including deciding when a human checkpoint is required. Think team lead, with agents as team members.

Flows are deterministic: authored paths, same input → same route. Agents are goal-driven: the path is decided at runtime by reasoning, which handles ambiguity and novelty but trades away predictability. They cooperate — agents call flows as tools for the deterministic parts. Rule of thumb to quote: known process → flow; judgment over messy input → agent.

The aspiration that routine operational work completes with no human intervention: an alert fires → agent diagnoses via runbooks and telemetry → remediates through automated actions → verifies → documents — humans only see exceptions. Agents supply the judgment layer that pure automation lacked, chaining diagnosis to remediation across the long tail of variations.

The layer assembling what the agent "knows" for each decision: relevant record data, conversation history, prior agent steps, retrieved knowledge, user/entitlement context — governed by access controls. Critical because agent quality is bounded by context quality: an agent deciding on stale or over-broad context makes confident wrong moves, and a context engine that ignores ACLs is a data leak with initiative.

The design environment for agents: define role and instructions (natural language), attach knowledge and tools, set guardrails and triggers, then test in a sandboxed playground before deployment. Users: platform developers and advanced admins primarily, with process owners contributing the instruction/policy content.

Tool types: record operations (query/create/update), flows and subflows (the workhorse — wrap any existing automation), retrieval (AI Search/knowledge), script tools, and integration actions via spokes. Configured per agent in Studio: each tool gets a description the LLM uses to decide when to invoke it — writing those descriptions well is the new API design.

It grounds the agent: queries AI Search over configured sources (knowledge bases, catalogs, curated content), returns ranked passages the agent reasons over — semantic retrieval with the user's access rights enforced. Configuration choices: which sources, how many results, and whether answers must cite retrieved content (they should).

The connective layer letting external AI agents (Microsoft Copilot, other vendors' agents) securely discover and invoke ServiceNow capabilities — and ServiceNow agents reach outward — so cross-platform agent ecosystems interoperate instead of each being walled. The security angle: external invocation arrives authenticated, scoped and audited like any integration, not as a trusted insider.

The Orchestrator decomposes the objective and delegates: a triage agent classifies, a diagnosis agent investigates, a remediation agent executes the fix, a communication agent updates the user — each with narrow tools and instructions, sharing state through orchestrated context handoffs. Narrow agents beat one omni-agent for the same reason small functions beat a 2,000-line script: testability and least privilege.

Approval checkpoints before designated actions (anything destructive or customer-facing), confidence thresholds below which the agent must escalate, scoped tool permissions (read freely, write only via approved flows), full execution transcripts for review, kill switches per agent, and staged autonomy — recommend-only mode first, auto-execute earned later with evidence.

The roadmap of role-scoped AI Specialists across functions — IT (L1 support, ops), HR (case handling), CSM (customer support), security operations, finance back-office — each a persona bundling agents, tools and KPIs for a job family. The framing for interviews: it shifts the question from "which task do we automate?" to "which role's routine slice do we delegate, with what oversight?"

Representative set: incident triage/categorization agents, incident resolution/deflection agents (self-service fixes for common issues), case summarization and communication agents, knowledge-gap identification agents, and change-risk assessment helpers — plus the L1 IT Specialist bundling several. Exact catalogs move fast per release; say that and name the pattern rather than reciting a stale list.

Screen with four questions: Is the input ambiguous enough that a flow's conditions can't route it? Does handling require judgment across unstructured content? Is the volume high enough to justify build+governance cost? Is the blast radius of a wrong action survivable (or gateable)? Four yeses → agent. A deterministic process with clean inputs → Flow Designer, cheaper and predictable. Answering "when NOT to use an agent" is what earns senior marks.

Layered: Virtual Agent + Now Assist Q&A as the front door (deflect what knowledge answers); AI agents for triage (categorize/prioritize/route), diagnosis (retrieval over runbooks) and remediation via flows as tools (password reset, access grants — deterministic executions); Orchestrator coordinating; human checkpoints on writes beyond a safe list; Predictive Intelligence still fine for high-volume classification. Start recommend-only, measure, then graduate to auto-execute per action class.

Pull execution transcripts for wrong decisions → was the context complete (did the Context Engine surface impact data)? → are the instructions/priority policy explicit ("P1 requires X users or Y service") or vague? → check tool outputs it relied on → fix in order: instructions first (cheapest), grounding second, tool descriptions third → regression-test on a labeled set of past incidents, and keep priority in recommend-mode until accuracy clears a threshold you agreed with the process owner.

Action Fabric (with the platform's API layer beneath). Security checklist: authenticate the external agent as its own principal (OAuth, never a shared human account), authorize per capability (expose specific flows/actions, not tables), validate inputs exactly as you would an untrusted API caller, audit every invocation with the acting-agent identity, and rate-limit. Treat an external AI agent as a partner integration with initiative — the same rules, enforced harder.

Run agents in recommend-only/approval-gated mode: every proposed action creates an approval a human authorizes before execution; all reasoning transcripts and tool calls logged to reviewable records; tools restricted to flows that themselves write audit entries; role-scoped agent identities so actions attribute cleanly; periodic compliance review of transcripts. Yes, it sacrifices speed — in regulated contexts that's the deal, and saying so plainly is the right answer.

Push back when the flow works: deterministic, testable, cheap, auditable — replacing it with probabilistic reasoning adds cost and variance for zero gain. Agree when the flow drowns in condition branches trying to approximate judgment, or its inputs are unstructured. Often the best design is both: keep the flow as the execution tool, add an agent only at the messy decision point feeding it.

1. Define role, goal, boundaries with the process owner.
2. Draft instructions in Studio; attach knowledge sources and the minimal tool set.
3. Test in the playground against real (anonymized) cases; tighten instructions.
4. Add guardrails: approval gates, escalation rules, confidence limits.
5. Deploy to a pilot audience in recommend-only mode; measure acceptance.
6. Graduate safe action classes to auto-execute with evidence; monitor transcripts.
7. Operate: version instruction changes like code, re-evaluate after each platform upgrade.