Three ways to let an AI agent build on ServiceNow

Yesterday I spoke at The Null Edge. The talk was "SN AI Engineer: MCP, Skills, and CLI". Thank you to every speaker. The videos will appear on the The Null Edge YouTube channel.

This post is the short version of my talk.

The agents are already here

AI agents already write to ServiceNow instances. The question is not if. The question is how much control you keep.

Sam Kececi wrote that soon, the cost of making software will be zero. I agree that code is cheap now. But building software in ServiceNow is not going to zero soon. Writing code is only part of the job. The platform, permissions, testing, and governance still matter. So the way you give an agent access matters too.

In the talk I used one instance and one agent for every demo.

1. MCP: give the agent tools, not an API

An MCP server sits between the agent and the instance. In my demo it is ten tools on a Cloudflare Worker. The tools query, get, create, and update records, read live table schema, run a server script, switch update sets, and run ATF suites and instance scans.

What I like about it:

The agent never holds the password. The server does.
The tools are typed and describe themselves.
You decide the tool list.
One server works for Claude, Cursor, and other clients.

The agent proves its own work. It switches to a dedicated update set, builds, runs an instance scan, then runs an ATF suite. A human reviews the result. The server polls the CI/CD API, so the agent sees one result.

What hurts:

You deploy, own, and secure a server.
An open /mcp endpoint is an open instance.
A script tool is a sharp tool.
The server has no memory of what it changed.

2. Skills: raw REST and a good AGENTS.md

This path has no server and no SDK. It needs an agent, a credential file, and the Table API. A short AGENTS.md carries the rules, and a skill loads only when the agent needs it.

The rules are simple. Discover the fields in sys_dictionary first. Query tight, with fields, a limit, and display values. Use POST and PATCH, never PUT. Re-read after each write.

What I like about it:

You start in a minute, with no infrastructure.
It works on any table, with any agent and any model.
ACLs scope the agent for free.
The brief is plain text you can review.

Then you hit a cliff:

Rules are prose, so the agent can skip them.
A wrong field in sysparm_query is ignored. A typo looks like success.
The credentials sit next to the agent.
Flow Designer is not a Table API job. Flows and workspaces span many tables with no map.

I showed this with a catalog item. With only the Table API, the agent needs many tables, guesses variable type numbers, uses no update set, and ends with an undo that is a list of DELETE calls.

3. CLI: a lifecycle the agent must follow

sndev is my product: a CLI and a desktop app. The agent writes a manifest. sndev plans it, runs it, checks it, and can undo it.

The lifecycle is preflight, plan, preview, execute, validate, test, and drift. No write happens before preflight and plan pass. Execute is idempotent, so a second run makes no duplicates. State is saved on disk, so you can inspect each step. If a run fails, sndev repair names the recovery and sndev patch fixes forward. sndev backout is the last resort.

The agent does not guess what is valid. It asks the tool. At the time of the talk the registry held 281 operations in 61 skill families (sndev ops, v0.37.0, checked on 2026-10-15). The agent asks the registry, not its training data.

Four checks never write:

sndev preflight lists every problem in one run, with where and why.
sndev show --diagram draws a flow as a graph and checks its wiring, offline.
sndev preview compares the plan with live records.
sndev drift --outside lists changes that no sndev run wrote, and how to adopt them.

The desktop app uses the same engine. Each manifest is a card that moves from Drafted to Executed to Tested to Completed. Before auto mode runs a step, an approval card shows the exact command. Ask puts your own agent inside the app. The default is Draft only: the agent reads and drafts, and it cannot write to the instance. To let it write, you turn on Full access yourself.

I will be honest about the limits. The CLI does less than raw REST. It writes only what its registry knows. A manifest is more work than one call. It has no ad-hoc script execution, by design. And it is a paid product. What it does, it can prove and undo.

How to choose

Pick by what you must prove later.

	MCP	Skills	CLI
Setup	Deploy a Worker	Copy one file	Install a binary
Guardrails	In the tool list	In the prompt	In the lifecycle
Credentials	On the server	With the agent	Local profiles
Memory of work	Update set only	None	State file per step
Undo	Manual	Manual	`sndev backout`
Review in	The agent chat	The agent chat	Report and app board
Best at	Shared team access	Fast data work	Config you must trust

The Memory, Undo, and Review rows are the ones auditors ask about.

Other CLIs

sndev is not the only CLI. now-sdk is the official one, for Fluent apps as TypeScript source. nex extends the SDK for operations. jsn is a friendly, stateless explorer. Each has a real strength. All of them move fast, so check the versions.

Try it

The MCP and Skills examples are open source:

The CLI and the desktop app are at sndev.io.

If you were at the talk, or you watch the video, reach out and connect!