Custom NetSuite AI: agents that are safe to be wrong

What it does

A Claude-based agent, loaded with our own NetSuite knowledge base, watches the Freshservice queue our helpdesk runs on. We built it for ourselves and we run it on ourselves. That is the strongest form of evidence we can offer: the queue it gets wrong is our queue, and every bad draft costs our own engineers time before it could ever cost yours. For every ticket, it drafts a proposed fix or automation plan and posts it as a private note on the ticket — visible to the team, never to the requester. It does not act on that plan. A person has to read it, then approve it or change it, before anything in NetSuite moves.

Read-only by default

The NetSuite integration behind it runs under a read-only role. The agent can look at anything that role can see; it cannot write, post, or delete anything in NetSuite on its own. Every change that eventually happens goes through the same human-approved path as any other request.

Ticket arrives Freshservice queue Held until picked up Survives a restart Agent drafts plan Read-only NetSuite role Private note Visible to team only Human approves or rewrites Required before any change NetSuite updated Only after approval
A ticket reaches an agent holding a read-only NetSuite role, which drafts a plan and posts it as a private note, and a human approves or rewrites it before anything reaches NetSuite.

It can't lose your place

Work in flight survives a restart. A deploy, a crash, or a scheduled restart doesn't mean a ticket silently disappears; it means the same ticket gets picked back up where it left off. That is a property we designed for, because an agent that quietly drops one ticket in fifty is worse than no agent at all.

Knowledge that updates without a release

The runbooks and NetSuite-specific knowledge the agent reasons from are maintained separately from the agent itself. When someone corrects a runbook or adds a new one, the next ticket that comes in uses the correction immediately, with no rebuild and no waiting for a release window. The people who know the answer can fix the agent without an engineer in the middle.

What happens when it's wrong

An early build of one of its maintenance steps would have destroyed 65 uncommitted files of an engineer's working code. It never ran against real work, and the reason it never ran is worth being precise about: a person caught it by reading the actual diff instead of trusting the summary of what the change would do. The tool did not catch itself. What came out of that is a hard rule still enforced in the code today, that the agent will only ever reset something it created itself. Anything a human made, it treats as a human's working copy and leaves alone.

We are telling you this because "what happens when it's wrong" is the only question about agents that matters, and most answers to it are theoretical.

If you're weighing whether an agent like this is the right investment before you build one, that's the conversation on the advisory page.

If you want one of these

A useful first message is short: which queue or system the work sits in, what an agent would have to read to be any good at it, and what you would let it change without a person in the way. Send us that and we'll tell you what building it would take — or where we would tell you not to bother. Contact us, or book a call and we'll walk through it.