Documentation

    How the NovusAI ServiceNow agent works — connecting an instance, the approval model, what it can build, and where its limits are.

    Getting started

    Connect NovusAI to a ServiceNow instance and it can start reading it immediately. You will need the instance URL and a set of credentials it can authenticate with.

    Start on a Personal Developer Instance (PDI). ServiceNow gives these away free, they reset if you break something, and nothing on them is production. You can watch a full build end to end without any risk.

    • Open the agent and add your instance URL.
    • Authenticate. Nothing is written to the instance during setup.
    • Ask a read-only question first — a count or a lookup — to confirm the connection.
    • Turn on writes when you are ready for it to make changes.

    How approvals work

    The agent separates reading from writing, and treats them very differently.

    Reads — queries, lookups, counts, inspecting a rule or a workflow — happen without asking. They cannot change your instance.

    Writes never happen without you. Before any change, the agent states in one sentence what it is about to do and to what, naming records by their human labels rather than sys_ids, and waits. You approve or decline each one. Declining is not a failure — it tells the agent to find another way, and it will.

    Writes are also gated at the account level. If writes are switched off, the write tools are not merely hidden from the agent — they are not available to it at all.

    What it can build

    The agent works through the ServiceNow Table API and, where an instance allows it, a server-side script runner it can install with your approval.

    • Business Rules, Script Includes, and client-side scripts
    • Catalog items, record producers, and variable sets
    • Flow Designer flows and classic workflows, including activities and conditions
    • Reports, dashboards, and Performance Analytics widgets
    • ACLs and role configuration, including elevating to security admin when you approve it
    • Fields, choice lists, and system properties

    Anything it creates comes back as a link into your instance so you can open the record and check it yourself.

    Verification

    A successful insert proves a row exists. It does not prove anything works — and the two are very different when a dashboard renders empty or a button never appears on a form.

    So the agent verifies its own work against the instance after building. A dashboard is checked for the widgets actually bound to it. A form or portal change is checked for the element a user would really see. If a check fails, the agent fixes the cause and checks again.

    It will not report success over a failed verification, and it will not claim a change from an insert result alone. If it could not verify something, it says so.

    Knowledge and memory

    The agent has three sources of knowledge, and treats your instance as the most authoritative of them.

    • Your instance — always the source of truth for what is actually configured.
    • ServiceNow documentation, retrieved per question rather than recalled from memory.
    • Live web search, for release notes, version-specific behaviour, and community fixes. Web pages are read to inform an answer, not copied or stored.

    Corrections you give it are remembered and applied to later work, scoped to your account. If you tell it something about your instance that contradicts its assumption, it keeps that.

    Limits and safety

    Some things the agent deliberately will not do, and some it cannot.

    • It will not write anything without your approval on that specific change.
    • It will not claim a change it cannot show you a tool result for.
    • Destructive or wide-reaching actions are described with their impact before it asks.
    • Each turn has a bounded number of steps, so a task cannot loop indefinitely.

    It is also not a substitute for review. It is fast and it verifies its work, but on a production instance you should read what it proposes before approving it — exactly as you would a change from a colleague.

    Troubleshooting

    A few things account for most problems.

    • It cannot see a table or field — the account it authenticates with may lack the role. ACLs apply to the agent exactly as they would to that user.
    • A write was approved but nothing changed — check whether the instance rejected it; the agent will report the error rather than assume success.
    • It says it cannot verify something — it is telling you the truth. Treat that as work not finished, not as a formality.
    • Answers describe the wrong configuration — confirm it is connected to the instance you think it is.

    Still have a question?

    The fastest answer is usually the agent itself — point it at a developer instance and ask.

    Open the agent