Reading the frontier
The frontier is moving toward smaller models running closer to your data. In Alaska that is not a cost story, it is a permission story.
The most consequential AI research for an Alaska business in the last two years is not a new frontier model. It is a position paper from NVIDIA arguing that most agent work does not need one.
Written by Kristian Baer, Northtek · Anchorage, Alaska · Updated 2026-08-21
The short answer
What are small language models and why do they matter for a business?
A small language model is one that runs on ordinary hardware - a workstation, a server you own, sometimes a laptop - fast enough to be useful to one person, rather than requiring a data center. In June 2025 a team at NVIDIA Research published a position paper arguing that small models are sufficiently powerful, inherently more suitable, and necessarily more economical for most of what AI agents actually do. Their reasoning is that agents perform a small number of specialized tasks repetitively and with little variation, which is not a workload that needs a general-purpose frontier model. For a business the practical consequence is that the model reading your documents can live on infrastructure you control. Data residency stops being an expensive exception and becomes the default architecture, and per-token cost stops scaling with the exact high-repetition workflows that were worth automating.
The paper
NVIDIA argued against the assumption that bigger is the answer.
In June 2025, the Deep Learning Efficiency Research Group at NVIDIA Research published Small Language Models are the Future of Agentic AI. It is a position piece rather than a benchmark, and its argument rests on three claims: small models are already capable enough for many agent tasks, they are inherently better suited to agentic systems, and they are more economical at the volumes agents actually run at.
The definition they propose is useful because it is operational rather than a parameter count: a small model is one that runs on common consumer devices with responses fast enough for a single user. Anything else is a large model. That framing puts the emphasis where it belongs, on where the model can physically live.
The paper does not argue that large models go away. It argues for heterogeneous systems, where general conversation and genuinely hard reasoning route to a large model while the repetitive specialized steps - the bulk of the invocations - run small. NVIDIA also maintains a public page collecting critiques of their own position, which is a posture worth noticing in a field where most claims arrive without a rebuttal channel.
Why it lands differently here
Three Alaska constraints stop being constraints.
This paper reads as a cost optimization if your business is in a city with fibre and no data governance obligations. In Alaska it reads as a change in what is permitted at all.
- Data residency stops being a premium architecture
- For an Alaska Native corporation, a tribal health organization, or a contractor handling controlled unclassified information, the blocking question has never been capability. It is where the records physically go. When the model that reads shareholder correspondence or a referral packet can run on hardware the organization owns, the question dissolves rather than being managed.
- Connectivity stops being a dependency
- A model running on a laptop in a mechanical room, on a tender at anchor, or at a village clinic does not need a link to be useful. Every workflow this state runs that assumes intermittent connectivity becomes buildable rather than aspirational.
- Cost stops scaling with the thing you wanted most
- Per-token pricing charges you most for the highest-volume, most repetitive tasks, which are precisely the ones with the clearest return. A model running on hardware you already paid for inverts that: volume becomes free after the first deployment.
The honest limits
Small-by-default is an architecture, not an ideology.
A system built entirely from small models will disappoint on tasks that genuinely require breadth: open-ended reasoning, unusual language, synthesis across domains that were never in the training data. The design that works is small by default with a route to a larger model when a step needs it, and the engineering discipline is in the routing rather than in the models.
The other honest point is that a locally deployed model is infrastructure you now own. Somebody updates it, monitors it, and notices when it degrades. For an organization with an IT function that is a small addition. For a six-person office it is a real consideration, and we would rather raise it during scoping than after the hardware arrives.
Why we built for this early
This is the architecture our own research already assumed.
GENOME, the memory server we wrote and benchmarked in public, has an offline mode because we needed one before there was a fashionable argument for it. Kryos, our agent language, was built so an agent’s actions are auditable line by line, which matters far more when the agent is running inside a regulated organization’s own boundary than when it is a hosted service somebody else is responsible for.
That is why a tenant-resident or fully air-gapped deployment is a configuration choice for us rather than a custom engineering project with a custom price. A firm assembling a product from third-party services cannot make that offer, because the answer to where the data goes is set by a vendor they do not control.
Apply it
Five questions worth asking any vendor about this
The answers separate firms that have thought about deployment topology from firms that have only thought about features.
-
01
Which model runs each step, and where does it physically execute?
A vendor who cannot answer per-step has not designed the system, they have wired up one endpoint. Ask for the topology in writing.
-
02
What happens when the connection drops?
In this state that is not a disaster scenario, it is Tuesday. The answer should describe queueing and reconciliation, not an apology.
-
03
Does cost scale with our volume?
If the pricing is per-token and your best use case is high repetition, the economics work against exactly the workflow you most wanted.
-
04
Can this run entirely inside our own boundary if our policy requires it?
Firms that rent their memory layer cannot say yes without renegotiating with a third party. Firms that built one can.
-
05
What is your escalation rule to a larger model?
There should be one, it should be explicit, and it should be a rule you can read rather than a behavior you have to infer.
References
Read the primary sources
Everything asserted above traces to one of these. Where a claim is contested or the evidence is weaker than it is usually presented, we say so on the page rather than in a footnote.
-
01
Belcak, P., Heinrich, G., Diao, S., Fu, Y., Dong, X., Muralidharan, S., Lin, Y. C., Molchanov, P. (2025). Small Language Models are the Future of Agentic AI. NVIDIA Research, Deep Learning Efficiency Research Group. arXiv:2506.02153.
The position paper this page is built on. Worth reading directly - it is short and unusually clear.
-
02
NVIDIA Research (2025). Correspondence on Small Language Models are the Future of Agentic AI. research.nvidia.com.
NVIDIA publishes critiques of their own position here. The disagreements are as informative as the paper.
-
03
Northtek (2026). GENOME - offline memory server. Open source, benchmarked against Mem0 on public datasets.
Our offline memory implementation, with the benchmark harness published alongside the results.
Straight answers
Does a small model mean a worse result?+
On the tasks agents actually spend their time on - extracting fields from a document, classifying an inbound request, drafting from a template with retrieved facts - a well-chosen small model is frequently indistinguishable from a frontier model, and the NVIDIA paper argues that case in detail. On open-ended reasoning the gap is real, which is why the sound architecture routes those steps to a larger model rather than pretending the gap does not exist.
What hardware would we actually need?+
It depends on the model and the concurrency, and the honest answer is that we size it during scoping rather than quoting a machine on a web page. The useful framing is that this is workstation and small-server territory, not a data center, and for many Alaska organizations the hardware cost is smaller than one year of per-seat licensing for a hosted product.
Is this only relevant if we have compliance requirements?+
Compliance is the sharpest case but not the only one. Cost inverts for high-volume workflows, latency improves when the model is local, and connectivity stops being a dependency. An operation with none of those pressures may reasonably stay hosted, and we will say so.
Who maintains a locally deployed model?+
You do, with our documentation, or we do under an agreement. Either way it is a real operational responsibility and we put it in the scope explicitly. A vendor who presents local deployment as free of ongoing work is describing a demo.
Does this conflict with using a commercial AI service at all?+
No, and treating it as a binary is the mistake. Heterogeneous is the design NVIDIA argues for and the one we build: small and local by default, escalating to a larger model where a step genuinely needs it, with the routing rule written down and auditable.
How current is this position?+
The paper published in June 2025 and NVIDIA has been collecting and publishing responses to it since. It is an active argument rather than settled doctrine, which is exactly why we cite the correspondence page alongside the paper instead of presenting one side as consensus.
Keep reading
Why AI pilots fail
The memory architecture problem underneath most disappointing deployments.
Read →
Alaska Native Corporations
Where data sovereignty is the first question rather than the last one.
Read →
Government contracting
What can and cannot run in an environment that has not been assessed for CUI.
Read →