ServiceNow's July 2026 Now Assist Update: What IT Leaders Need to Know
In-form resolution, device remediation from the incident record, and a quiet change to default models. The July Now Assist release says more about the direction of ITSM AI than the feature list suggests.

Key takeaways
- Now Assist can now classify intent and suggest a resolution before a ticket is submitted
- Agents can trigger Intune and Jamf device remediation directly from incidents, tasks and changes
- Default models for ITSM skills shifted from Now LLM to selected smaller third-party models, with larger models requiring approval
- Suggested Steps and the Incident Assist skill are deprecated in favor of newer AI recommendations
ServiceNow shipped its July Now Assist for ITSM update, and the release notes contain two separate stories. The visible one is about capability. The quieter one is about which model processes your service desk data, and that is the one worth reading twice.
What actually shipped
Three changes stand out.
In-form resolution before submission. Now Assist can classify intent, retrieve relevant knowledge and suggest a resolution while the employee is still filling out the form, before a ticket exists.
Device remediation from the record. Agents can trigger Intune and Jamf remediation actions directly from incidents, tasks and changes, without leaving the workspace for a separate endpoint console.
Deprecations. Suggested Steps and the Incident Assist skill are being retired, with customers directed toward newer AI-driven recommendations.
Alongside these, the default model for ITSM skills changed from Now LLM to selected smaller third-party models. Larger third-party models now require approval.
The capability direction is correct
The strategic signal here is that the industry has stopped treating a generated answer as the finish line. Retrieving a knowledge article and presenting it to an employee leaves the actual work undone. Triggering a device remediation completes it.
That is the right direction, and it is the direction the whole category is moving. The distinction that matters for buyers is between suggesting a resolution and executing one. In-form suggestion catches the request earlier, which is genuinely valuable, but the employee still reads a recommendation and acts on it themselves. Execution means the access is granted, the software is installed, the mailbox permission is applied, the account is unlocked.
The endpoint remediation piece is the more consequential half of the release, because it crosses from advice into action.
The model change deserves a closer read
A default model change is the kind of line that scrolls past in a release note and shows up later in a security review. Three things follow from it.
Data processing has changed. If your ITSM skills previously ran on a first-party model and now route to a third-party one by default, the set of processors touching ticket content (which routinely includes employee names, device identifiers, access requests and occasionally sensitive HR context), has changed. Your data processing agreement and privacy documentation should reflect that.
Behavior may drift. Smaller models are cheaper and faster and do not respond identically to the same prompt. Prompts and workflows tuned against a prior model can degrade quietly. Regression testing on your highest-volume intents is not optional after a default change.
Approval is now a workflow. Requiring approval for larger models is sound governance, but it creates an internal process. Someone owns the decision about which requests justify the more capable model, and that decision has both a cost and a quality dimension.
Questions worth asking your platform vendor
This applies to any AI service platform, ours included:
- Which model processes my ticket content today, and where is that documented?
- How will I be notified if the default changes?
- Can I pin a model for a specific workflow, or is selection controlled entirely by the vendor?
- Which sub-processors are in scope, and under what data residency terms?
- Is model selection visible in the audit trail for a given resolution?
That fifth question is the one most platforms struggle with. If you cannot reconstruct which model produced a given autonomous action, you cannot fully explain the action, and an unexplainable action is difficult to defend in an audit.
Where we land on this
The capability trajectory ServiceNow is describing matches what we built toward: resolution rather than routing. Sidekick resolves roughly 70% of requests before they become tickets, across Teams, Slack, email and voice, with grounded and cited answers. How Sidekick Thinks describes the eight specialized agents reasoning over a single shared conversation, which is our answer to the model-selection problem, different reasoning steps use different specialized capabilities rather than routing everything through one general model.
For organizations already standardized on ServiceNow, Rezolve.ai runs on top of it as well as standalone, so the resolution layer and the system of record do not have to be an either-or decision.
The governance principle we hold to is simple: autonomy is always paired with approval gates, audit trails and explainability. A model change that alters who processes employee data should be a decision the customer makes, not a default the customer discovers.
See how governed autonomous resolution works in practice, book a demo or read how Sidekick thinks.
See the agentic service desk in action
Watch Rezolve.ai autonomously resolve real IT and HR tickets: governed, auditable, glass-box.



