NetSuite AI Development: What You Can Build with the N/llm Module, Custom Tools, and the AI Connector

AI inside NetSuite has moved from slideware to shipping features. As of the 2026.1 release there is a SuiteScript module for calling language models, a new script type that lets external AI agents act inside your account, and an AI assistant that writes SuiteScript for you. The question for anyone who owns a customised NetSuite account is no longer whether AI is coming, it is which of these is worth building on, and which is a demo waiting for a real use case.

This guide is the developer's view. It covers the three ways AI shows up when you build on NetSuite, what each one actually does, the constraints that matter, and where the genuine value is today. Every version-specific claim is cited to Oracle's documentation, because this area is moving fast and the details change release to release.

The three ways AI reaches a NetSuite developer

It helps to separate three things that all get called "NetSuite AI", because they solve different problems and carry different constraints.

There is also a layer of end-user AI, such as Text Enhance for drafting and refining text in the UI, and Prompt Studio for managing the prompts behind it. Those matter to administrators, but the three above are where development work happens. Take them in turn.

1. Calling AI from your scripts: the N/llm module

The N/llm module lets your SuiteScript send a prompt to a large language model and use the response. It is SuiteScript 2.1 only and is available once the Server SuiteScript feature is on, in supported regions.

Behind the module, NetSuite routes the request to the Oracle Cloud Infrastructure (OCI) Generative AI service. If you do not name a model, the default is Cohere's Command R; the available model families are exposed through llm.ModelFamily, and the set grows over time (2026.1 added an OpenAI GPT-OSS option). Because the model list changes by release and region, confirm the current options against Oracle's docs rather than hard-coding assumptions.

The methods you will use most:

• llm.generateText(options) sends a prompt and returns the generated text. There is a streamed variant, llm.generateTextStreamed(options), and promise versions of both.
• llm.embed(options) turns text into vector embeddings, which is what you need for semantic search, classification, clustering, or a recommender.
• llm.evaluatePrompt(options) runs a prompt you have defined and versioned in Prompt Studio, so the prompt lives as configuration rather than buried in code.
• llm.getRemainingFreeUsage() tells you how much of the monthly free usage is left, which you should check before a batch job leans on it.

A minimal example: summarising an inbound customer message into a field when a case is saved.

/**
 * @NApiVersion 2.1
 * @NScriptType UserEventScript
 */
define(['N/llm'], (llm) => {
  const beforeSubmit = (context) => {
    if (context.type === context.UserEventType.DELETE) return;
 
    const message = context.newRecord.getValue({ fieldId: 'custbody_customer_message' });
    if (!message) return;
 
    const result = llm.generateText({
      prompt: `Summarise this customer message in two sentences:\n${message}`
    });
 
    context.newRecord.setValue({ fieldId: 'custbody_ai_summary', value: result.text });
  };
 
  return { beforeSubmit };
});

Two constraints decide whether this is a good idea in a given script.

Governance and usage. Calling the LLM does not consume SuiteScript governance units, but it is not free either: requests draw from a monthly free usage pool, where each generate or evaluate call costs one unit and embeddings have a separate quota. NetSuite does not publish a fixed free figure and it can vary, so design around getRemainingFreeUsage() and treat the model call as a metered resource, not a loop body you call ten thousand times in a map stage.

Trust and data. NetSuite positions the OCI route as keeping data inside Oracle's infrastructure rather than handing it to a third party for training, but you should confirm the current terms for your account and region before sending anything sensitive. And the model is generative: it can be confidently wrong. Oracle is explicit that you must validate AI output and that it is not liable for how the content is used. Treat a model response as a suggestion to check, never as a posted result.

N/llm earns its place for summarising, classifying, extracting, and drafting, as long as a human or a downstream rule still checks the output. It is the wrong tool for anything that has to be exactly right every time with no review. For the methods, models, RAG, and usage limits in detail, see calling AI from SuiteScript with the N/llm module.

2. Letting external AI act in NetSuite: the Custom Tool script type

The N/llm module puts AI inside your code. The Custom Tool script type, new in 2026.1, is the inverse. In Oracle's words, "custom tool scripts let you build NetSuite tools that external AI clients can invoke through the NetSuite AI Connector Service. With these scripts, you can retrieve data, trigger actions, or perform most SuiteScript-supported operations, all from natural language prompts in your AI client."

This is the piece that turns an AI assistant from something that can read your data into something that can act on it. The AI Connector Service adopts the Model Context Protocol (MCP), the emerging standard for connecting AI clients to systems, so a supported client such as ChatGPT or Claude can call your tools through natural language while staying inside NetSuite's own security model and role-based permissions. NetSuite ships an MCP Standard Tools SuiteApp with pre-built tools, and the custom tool script type is how you add your own.

How it is built differs from a normal script:

• You deploy custom tools only through the SuiteCloud Development Framework (SDF), as a SuiteApp or an account customisation project. There is no "upload in the UI" path.
• Each tool is defined in a JSON tool schema that states its name, description, and input parameters. The AI client reads that schema to decide when the tool applies and what to pass it, so the description is functional, not decoration.
• Entry-point functions are declared asynchronous, and from 2026.1 you can view a custom tool's execution logs on the Script Execution Logs page.
• Some modules are deliberately unavailable. Oracle states that "the N/http, N/https, N/llm, and N/sftp modules are not supported in custom tool scripts." The exclusion of N/llm is the giveaway for the design: the language model lives in the client, the tool just does the NetSuite work.

The shape of a tool, illustratively:

/**
 * @NApiVersion 2.1
 * @NScriptType CustomTool
 */
define(['N/record'], (record) => {
  // Invoked by an AI client through the AI Connector Service.
  // The matching JSON tool schema (name, description, parameters) is an SDF object.
  const createSupportCase = async (params) => {
    const supportCase = record.create({ type: record.Type.SUPPORT_CASE });
    supportCase.setValue({ fieldId: 'title', value: params.title });
    supportCase.setValue({ fieldId: 'incomingmessage', value: params.message });
    const id = supportCase.save();
 
    return { caseId: id };
  };
 
  return { createSupportCase };
});

Oracle publishes worked examples in the MCP sample tools on GitHub, which are the right starting point for the exact tool schema and entry-point contract.

What needs careful design here is the blast radius. A tool that can "trigger actions" can change records based on a natural-language prompt that a model interpreted. The permission model is your friend: the tool runs as a role, so scope that role tightly, prefer read and well-bounded writes over open-ended ones, and log everything. This is the same discipline that keeps an integration from failing silently, applied to a caller that is, by design, non-deterministic. A full build, with the script, the JSON tool schema, and the SDF deployment, is in building a custom tool for the AI Connector.

3. AI that helps you build: the SuiteCloud Developer Assistant

The third strand is AI pointed at the development work itself. The SuiteCloud Developer Assistant is an AI coding assistant that runs in Visual Studio Code through the Cline extension. It generates SuiteScript 2.1 from natural-language prompts, including unit tests, creates SDF custom objects, and explains or refactors existing code while following SuiteScript API standards and the SDF schemas.

For a practice that spends much of its time reading and modernising other people's SuiteScript, this mostly accelerates the tedious parts: scaffolding a script, drafting tests, explaining an unfamiliar 1.0 script before you rewrite it. It does not remove the need to understand what it produced, and on a customised account the cost of shipping plausible-but-wrong code is high. It is a faster way to do the work, not a replacement for knowing the platform. It pairs naturally with a disciplined 1.0-to-2.1 modernisation, where understanding the old code is most of the job.

What is worth building now

Where the value is genuinely there today:

• Summarisation and drafting with N/llm, where the output is reviewed: case summaries, draft responses, condensing long notes.
• Classification and routing: tagging, triage, and categorisation where a wrong answer is cheap to correct.
• Semantic search and matching with llm.embed: finding similar records, deduplication, recommendation, where embeddings beat keyword search.
• Agent-driven actions through custom tools, for well-scoped, permission-bounded operations where a human is still in the loop for anything consequential.

And where to wait, or to be careful: anything that must be exactly correct without review, anything that sends regulated or sensitive data before you have confirmed the terms, and any design that calls the model in a tight loop and ignores the usage pool. The technology is ready for the first list. The second list is where AI projects in NetSuite go wrong.

Prerequisites and where to start

Three things have to be true before any of this is worth scoping:

1. You are on SuiteScript 2.1. N/llm and custom tools are 2.1 only, so if your account still carries 1.0 or 2.0 scripts, that migration is the real first step.
2. Your integration foundations are sound. AI agents acting through MCP are a new kind of integration consumer, and they need the same error handling, alerting, and permission discipline as any other. The NetSuite integration guide covers that groundwork.
3. The feature is available in your region and account. Generative AI features are region-gated, so confirm availability before you promise anything.

Get those right and the AI features become what they should be: a useful new capability on a platform you already control, rather than a demo bolted onto a system that was not ready for it.

Frequently asked questions

Does using AI in NetSuite cost extra? NetSuite does not charge a separate licence fee for the generative AI features, and N/llm calls do not consume SuiteScript governance units. They draw from a monthly free usage pool instead: each generate or evaluate call uses one unit, embeddings have a separate quota, and you can check what is left with llm.getRemainingFreeUsage(). Confirm the current allowances and any platform fees for your account against Oracle's docs.

Do I need to be on SuiteScript 2.1 to use the AI features? Yes. The N/llm module and the Custom Tool script type are SuiteScript 2.1 only. If your account still runs 1.0 or 2.0 scripts, modernising to 2.1 is the prerequisite for any of this work.

What is the difference between the N/llm module and the Custom Tool script type? N/llm calls an AI model from inside your SuiteScript, so your code drives the AI. A custom tool is the reverse: it exposes a piece of NetSuite logic that an external AI client, such as ChatGPT or Claude, can invoke through the AI Connector Service. One puts AI inside your scripts; the other lets AI act on NetSuite from the outside.

Is my data sent to a public AI service? N/llm routes requests through Oracle Cloud Infrastructure's Generative AI service rather than a public API. NetSuite positions this as keeping the data inside Oracle's infrastructure rather than third-party model training. Confirm the current data-handling terms for your account and region before sending sensitive data, and always validate AI output before acting on it.

Sources

• Oracle NetSuite, N/llm Module and SuiteScript 2.x Generative AI APIs.
• Oracle NetSuite, Usage Limits and Concurrency Limits for N/llm Methods.
• Oracle NetSuite, SuiteScript 2.1 Custom Tool Script Type and Creating Custom Tools for the NetSuite AI Connector Service.
• Oracle NetSuite, AI Connector Service FAQ and AI-Powered Customizations.

If you want to build an AI-backed feature into NetSuite, or work out whether one of these fits a problem you actually have, that is one of the core services I offer. It starts with a short technical review of your account and the use case.