Published on September 25, 2025.

Over the past few months, as I've worked on my various NetSuite AI projects, I've only worked with large language models (LLMs) like ChatGPT and Claude (and their APIs). It didn't matter what the project was — LLMs have been my go-to for everything from invoice coding to variance explanations. They helped me get up to speed with AI and prototype things very quickly.

But lately, I've been paying attention to a new idea: small language models (SLMs). NVIDIA's recent paper — Small Language Models Are the Future of Agentic AI — argues that many tasks we hand to giant models don't need that kind of muscle.

What SLMs Are

A large language model (LLM) is like a massive general-purpose brain. It's trained on an enormous mix of data so it can handle anything — poetry, programming, contracts, you name it. That flexibility comes with cost: they're big, expensive to run, and slower on simple jobs.

A small language model (SLM) is leaner and focused. It's typically under 10 billion parameters (compared to 70–175B for big models).

That means:

They're less expensive to run: SLMs need less compute — 10–30× cheaper to operate in many cases.


They run faster: Millisecond responses instead of waiting several seconds.

They can run locally: Many SLMs can run fully on your own hardware, so sensitive data doesn't have to leave your network.

They're easier to control: They're not trying to be creative; they're tuned for narrow tasks and consistent output.

Think of it as the difference between hiring a PhD to sort mail versus training a reliable mail clerk who knows your specific office.

Why SLMs Might Be a Good Fit for AI Agents

AI agents often do structured, repetitive work:
• Categorizing invoices.
• Formatting and summarizing reports.
• Explaining variances.
• Routing approvals.
• Flagging unusual transactions.

Those tasks don't require the generality of LLMs. They require accuracy, speed, and predictable outputs (often JSON or some structured format).

SLMs shine here because they can be specialized to one job and stick to the script. And as I mentioned above, they can be deployed on-premise, which is important for companies with strict privacy, compliance, or data-sovereignty requirements. If you're in finance, healthcare, or anywhere audits and regulators care where data lives, being able to run the model locally could be a deciding factor.

Future-Proofing AI Agents

In my recent post, NetSuite AI Agents: FAQ, I talk about where the “AI” actually comes in and how the models fit into the bigger workflow. In short, I'm building the AI layer to be modular and model-agnostic.

Right now, the agents I've developed are using LLMs. But the architecture doesn't lock me in. Each AI task — “classify this invoice,” “explain this variance,” “suggest a payment follow-up” — is its own module. If an SLM turns out to be a better fit than an LLM for one step, I can swap it in without rewriting the whole agent. (This also allows me to easily swap LLMs.)

This approach also lets me mix and match: SLMs for narrow, structured steps; LLMs for unstructured or novel problems.

Building an SLM for an AI Agent

As an example, let's discuss how an SLM might be used in the Accounts Receivable (AR) Agent that I described in this earlier post.

Here's what it would take to pull that off...

Define the scope clearly

Decide exactly what the AR model will handle — invoice coding, reason codes, short explanations for late payments, dunning messages, etc. Fix the output schema (e.g., one JSON shape).

Collect real examples

Use your historical AR transactions, notes, and any existing automation logic. Curate high-quality prompt/response pairs that reflect your rules and exceptions. You don't need millions of rows; a few thousand good ones often go far for small models.

Fine-tune a small base model

Start with an open small model (Phi-3, Nemotron, DeepSeek). Use efficient techniques like LoRA/QLoRA to adapt it to your AR data without huge GPU budgets.

Test thoroughly

Unit-test the model's output for consistency, handle odd cases (foreign currency, partial payments), and compare to an LLM baseline on accuracy, cost, and speed.

Deploy behind a router

Let the SLM handle normal AR tasks but fall back to an LLM for rare edge cases or low confidence. Log everything to improve the SLM over time.

I don't see this as a huge research project. I think it's more like development work. The heavy lift is good data prep and schema control, not giant compute clusters.

A Practical Way to Start Exploring SLMs

If you're curious, you don't have to go all in right away:
• Instrument what you already have. Track LLM call frequency, cost, and latency.
• Pick one repetitive, low-risk task. Something easy to measure, like invoice classification.
• Try an off-the-shelf SLM. Evaluate before fine-tuning.
• Compare results and iterate. Look for “good enough” with major savings and more stable output.

Even a single small pilot will tell you if this path is worth deeper investment.

Wrapping Up

I've only just begun exploring SLMs, but I suspect they're going to have a huge impact on how I build AI for NetSuite — especially in cost, speed, and consistency.

For anyone working with NetSuite AI, being able to both create SLMs and plug them into agents feels like a skill worth building. Even if LLMs remain part of the stack, flexibility will matter. I think it'll be important for development teams to be able to pick the right model for the right job — and switch when better options appear.

That's the direction I'm taking with my own agents: keep them modular, keep them model-agnostic, and be prepared and open to using SLMs.