A Trillion-Parameter Model Now Fits on a Desk. That Changes How You Adopt Agentic AI.

Agents are arriving at the desk and at the edge

Most of the conversation about agentic AI still assumes an office worker with a browser open. That was accurate for about eighteen months and it is now too narrow.

The desk-based version is real and it is the version most organisations will meet first. An agent that watches a shared inbox, drafts responses, files them correctly, chases the three that went unanswered, and reports back on Friday is a well understood pattern at this point. What has changed is duration. The current generation of agents runs continuously, which means it accumulates context about how your organisation works instead of starting cold every time someone opens a chat window.

The edge version is the one leadership teams underestimate. A factory line, a retail floor, a hospital ward and a field maintenance crew are all environments where the useful action happens away from a reliable connection to a data centre, on a latency budget measured in milliseconds, with data that legal would prefer never left the site. Those constraints have historically ruled out anything but the smallest models. That is the constraint that moved this year.

A robot is an agent with a physical presence

It helps to collapse a distinction that gets treated as fundamental and is not. A robot is an agent that has been given a body. The perception, planning and action loop is the same loop a software agent runs. The difference is that the action step moves an object in the world rather than a row in a database, which raises the cost of being wrong and shortens the time available to catch it.

That framing is useful for governance because it means you do not need a separate robotics policy and an agent policy. You need one policy about autonomy tiers, and a clear statement of which tier applies when a mistake has physical consequences. The autonomy gate I wrote about last week applies without modification. A picking robot that can injure someone belongs at a lower autonomy tier than a scheduling agent that can annoy someone, and the reason is the blast radius.

The personal agent frameworks that made long-running agents practical

Three open frameworks did most of the work of turning this from a research topic into something a competent internal team can stand up.

OpenClaw started as a weekend project by Peter Steinberger in November 2025, went through two renames, and by late August 2026 had passed 389,000 stars on GitHub. It runs on the user’s own device and connects to the messaging channels people already use, including WhatsApp, Telegram, Slack, Signal and iMessage. Critically for this discussion, it works with hosted and local model providers interchangeably, so the decision about where the model runs is a configuration choice rather than an architecture rewrite.

Hermes Agent, released by Nous Research in February 2026, took a different bet. Its defining feature is a learning loop: it completes a task, writes a reusable skill document describing what worked, stores the outcome in persistent memory, and approaches the same task differently next time. Over months, that produces an agent with an accumulating model of how your organisation does things.

NemoClaw is NVIDIA’s answer to the obvious objection. Announced in March 2026, it wraps the OpenClaw agent platform in a security stack: a sandboxed execution environment called OpenShell, local Nemotron models, a privacy router that decides which requests are allowed to reach a cloud provider, and default-deny network policies. It installs in a single command on RTX PCs, workstations, DGX Spark and DGX Station.

The point is not that any one of these will win. It is that the capability of running a long-lived, context-gathering, tool-using agent on infrastructure you control is now available, open source, and hardened enough that a large hardware vendor has built a security layer for it.

The hardware caught up faster than most adoption plans did

The reason this matters commercially is memory. A model has to fit in memory to run at all, and no amount of processing speed compensates for a model that does not fit.

In October 2025, DGX Spark shipped at a launch price of $3,999 with 128GB of unified memory, enough for inference on models up to roughly 200 billion parameters. NVIDIA’s own guidance now covers clustering two to four of those units over a high-bandwidth link, reaching 256GB of unified memory for models around 400 billion parameters, and 512GB across four nodes for large mixture-of-experts models. In May 2026 NVIDIA announced DGX Station for Windows, with up to 748GB of coherent memory and 20 petaflops of FP4 performance, explicitly positioned as capable of running frontier models of up to one trillion parameters locally, shipping through the usual OEM channel from the fourth quarter of this year.

Read that sequence as a trend line. In roughly twelve months, the ceiling on what a single deskside box can hold went from the mid tens of billions of parameters to a trillion. Whatever number you used in your 2025 infrastructure assumptions is wrong now, and it will be wrong again in 2027.

Free tool

Data Architecture Decision Tool

Seven inputs and one recommendation on how to structure the data your agents will read, before you decide where any of them run.

→

Where a workload runs became a cost decision

Here is the claim you will hear from anyone selling this, and it is worth taking seriously and then testing. A developer running ten agents continuously against a frontier API can be spending thousands of dollars a day. Move those agents onto hardware they own and the marginal cost per token goes to roughly the price of electricity, with break-even on the hardware in as little as three months.

That arithmetic is correct under specific conditions and badly wrong outside them. I went through the full break-even model in an earlier piece on local hosting economics, and the short version is that the case rests almost entirely on utilisation. Cloud inference is a variable cost that scales with use. Owned hardware is a fixed cost that scales with nothing. The switch pays when volume is high, continuous and predictable. It does not pay when your agents run in bursts, when your workload is seasonal, or when you would be buying a trillion-parameter-class machine to run a task an eight-billion-parameter model handles fine.

Three placements, and what each is good for:

Most organisations that get this right end up with all three, deliberately assigned. The mistake is choosing one on principle. I have watched a client commit to cloud-only on a security team’s blanket rule and then pay for it in a latency budget that a control loop could not meet, and I have watched another buy hardware on a vendor’s break-even slide for a workload that ran four hours a week.

Adoption is a people journey before it is a technology one

Everything above is the easy half. The technology has a roadmap and a price list. The adoption does not.

The single highest-leverage move I know is to identify your super users early and give them real room. A super user is not your most technically capable person and it is usually not the person who volunteers first. The profile is narrower than that: deep institutional knowledge of how a process works, including the exceptions and the workarounds that never made it into any documentation, combined with genuine openness to changing that process.

Those two traits rarely sit together. Deep institutional knowledge often comes with a stake in the current design. Openness to change often comes with a shallow understanding of why the current design exists. The people who have both are your fastest route from pilot to production, because they can tell an agent builder what the process is really for, and they can tell a sceptical colleague that the change is survivable. Find them, name them, protect a meaningful share of their time, and make sure their manager knows the reassignment is a promotion in substance if not in title.

The failure mode here is well documented. Organisations pick a pilot team on availability rather than on this profile, the pilot produces something technically sound that nobody uses, and the conclusion drawn is that the technology is not ready.

Free tool

Human-AI Interaction & Decision Quality Dashboard

Benchmark how well your people and your systems are working together, adjusted for your industry and decision type.

→

The economics need a plan before the first pilot

The second decision is to treat this as an investment with a shape.

Three numbers are worth establishing before anything gets approved. What the workload costs today, measured properly, including the staff time it consumes rather than only the software licence. What it will cost at the volume you expect in eighteen months, which for a successful agent deployment is usually a much larger number than the pilot suggests. And what the placement alternatives cost at that same volume, which is where the local versus cloud question gets answered.

Most cost surprises in this area are not price rises. They are volume rises that nobody modelled, because a pilot that ran fifty tasks a day gets rolled out to a department that runs five thousand. Model the successful case instead of the pilot.

Free tool

AI ROI Calculator

Four inputs and sixty seconds to see how much operational time your team is leaving on the table, with a three-page roadmap at the end.

→

The operating model is where the value sits

The third decision is the one that separates organisations that get a productivity bump from organisations that get a step change.

Adding agents to your existing operating model produces exactly what you would expect: the same processes, running somewhat faster, with the same approval chains, the same handoffs and the same reporting lines. That is a real gain and it is worth having. It is also a small fraction of what is available, and it is fully available to every competitor who buys the same tools.

The larger question is what the business would look like if you designed it now, knowing that a capable agent can hold context for weeks, act across systems, and run continuously at near-zero marginal cost. Which approval steps existed only because a human could not be trusted to remember? Which handoffs existed only because two teams used different systems? Which reports existed only because nobody could query the underlying data directly? Those structures are load-bearing right up until they are not, and the organisations that rethink them are the ones that get a durable advantage.

This is slow, political work and it does not fit inside a pilot. It is also where the difference between a 5 percent gain and a 30 percent gain lives. I have argued the fuller version of this case in Stop Treating AI as an Add-On, and it has only become more true since.

What to do in the next ninety days

The technology story here is settled enough to plan around. A trillion-parameter model on a deskside machine, open frameworks that give it a persistent body, and a security stack from the largest vendor in the category all landed inside six months. What has not settled is whether your organisation has the people, the cost discipline and the appetite for structural change to do anything useful with it. Those three have always been the constraint, and none of them are downloadable.

Where to go next on this site

---

Deciding where your agents should run, and who in your organisation should own them? That is exactly the conversation my consulting work begins with.