How AgentNexus runs thousands of AI agents across every plant, serves and improves the models they use, and works with the AgentMesh pod at each site — without ever controlling equipment.
AgentNexus is a single rack of small servers in a central cabinet. It runs thousands of software agents in sealed sandboxes, serves the language model those agents use, and improves that model over time with small, tested add-ons. It works alongside the AgentMesh pods at each plant, which keep the fast loop next to the machines; AgentNexus works at business speed across all of them and never moves plant equipment. Numbers marked "estimate" have not been measured yet.
AgentMesh pods sit next to the machines at each plant and react within milliseconds. Some work doesn't need to be that fast but needs more room: agents that look across several plants, write reports, check work orders, or wait for days for a person to reply. AgentNexus is where that work runs. It answers within about half a second.
Every agent runs in its own sealed sandbox. Agents that are idle are saved to disk and put to sleep, then woken when someone needs them. That lets one rack hold far more agents than it could keep running at once.
One open-weight model, the Unovie Reasoning Model, answers every request. Small add-ons (adapters) specialise it for particular jobs; they're trained on the rack itself, tested, and switched on without restarting anything. A small companion model, the Unovie embedding model, handles search.
One cluster runs everything. Data is copied so that losing a server, or a whole shelf of four servers, doesn't lose work that was saved. Nothing depends on the internet.
Plants keep their own AgentMesh pods. AgentNexus sits above them in a central cabinet and talks to them over encrypted links. It sends finished results, such as work orders, to business systems. It never sends commands to plant equipment.
The rack is split by kind of chip. The processors (CPUs) run agents. The graphics processors (GPUs) do model work. Every server has both, so every server takes part in both. A shared platform underneath keeps them running.
| Part | What it does | Where it comes from |
|---|---|---|
| Agent tasks | Lets people describe an agent task in a short file (what to run, what code to fetch, how much memory) and start, pause or stop it. | Unovie Agent Runtime |
| Unovie Agent Runtime | Runs each agent in a sealed sandbox. Saves idle agents to storage and wakes them on demand. Controls what each agent can reach on the network and keeps passwords out of the agents' hands. | Unovie platform, built on open source |
| Unovie Model Router | Looks at each request and decides which model, and which adapter, should answer it. | Unovie platform, built on open source |
| Unovie Decision Models | Small models that answer typed questions (pick one of these options, yes or no, score from 1 to 5) with a probability for each answer, without writing text. The smallest helps the router choose; larger ones grade training attempts and check new adapters. | Open weights; the smallest already runs in AgentMesh |
| Unovie Runtime | Runs the language models on the graphics processors and answers requests. | Already used in AgentMesh |
| Kiln | Trains small adapters that change how the model behaves for a task, using examples and scored attempts. Training runs as a job on one server at a time. | Unovie, extended from AgentMesh's nightly Kiln |
| Unovie embedding model | Turns text into numbers so that similar meanings can be found: used by the router and by agents searching their notes and documents. | Open weights |
| Mesh Arbiter | Our own failover service. Notices when a server or shelf stops and moves its work. | Unovie, extended from AgentMesh |
The rack standardises on two open models from Google, plus the router project's decision models, so that everything is trained, tested and served the same way. Using another model is a deliberate, recorded decision.
| Job | Model | How it's used |
|---|---|---|
| Answering requests (agents, chat, tools) | Unovie Reasoning Model (open weights) | A compressed copy on 24 GPUs for speed; the full-precision copy on 12 GPUs, where adapters can be applied. Already proven on the AgentMesh servers. |
| Specialised behaviour for a task | Adapters on the Unovie Reasoning Model, trained by the Kiln | Each request can name its adapter. Up to 8 are active per server at once and 64 kept ready. New ones are switched on without restarting anything. |
| Search and similarity | Unovie embedding model (open weights) | Turns text into vectors (lists of numbers) so that similar meaning can be found. Used by the router and by agents searching their notes and documents. |
| Typed decisions (routing, grading, checks) | Unovie Decision Models (open weights) | The smallest helps the router choose on every request. Larger ones grade training attempts and test new adapters. The largest (26B) is too big for one server and isn't used. |
A. An agent asks a model. The agent sends its request to one address. The router reads it, asks a small decision model which option fits, and sends it to the Unovie Reasoning Model: the compressed copy for general work, or the full copy with a specialised adapter. The router's own work is meant to take under a tenth of a second.
B. A plant talks to an agent. Most agents are asleep most of the time, saved to storage. When a request arrives, the agent is loaded onto any free server and woken. The target for waking is under half a second; we haven't measured it on our hardware yet.
C. A model gets better. Once a week for each adapter, if enough new results have come in, a training job starts on one of the 12 training servers. The Kiln asks the model to attempt tasks, has the attempts scored by test environments and larger decision models, and adjusts the adapter. The new adapter is then tested on cases it has never seen, tried quietly on a small share of real requests, and switched on only if it does better than the current one. The scoring code runs in the same sealed sandboxes as the agents.
Every server is the same small machine already used in AgentMesh. Four of them sit on one shelf (three rack units). Twelve shelves fill the rack. Using one model of server everywhere means one spare-parts kit and one software image, and any server can take over from any other.
| Item | What it is | What it's used for |
|---|---|---|
| Processor | AMD Ryzen AI Max+ 395, 16 cores | Agents, plus the system itself |
| Graphics processor | Radeon 8060S, built into the same chip | One model server or one training job |
| Memory | 64 GB, shared by the processor and graphics | About 30 GB for models, about 10 GB for agents, the rest for the system |
| AI accelerator (NPU) | XDNA 2, about 50 TOPS (measured 51) | Working, but idle for now: our models can't yet be converted to run on it. We'll test small helper models on it. |
| Storage | Six 2 TB solid-state drives (four on an add-in card) | System, fast scratch space, and copies of agent data |
| Network | Two 10 Gb/s ports, plus fast cables to the other three servers on the shelf | One port to each switch, so a switch can fail without loss |
How each kind of data is protected depends on how much it would hurt to lose it.
| Kind of data | How it's protected | What can be lost |
|---|---|---|
| Records of all agents and tasks (the database) | Every change is written on two servers in the same shelf, and also copied straight away to a standby in another shelf | Nothing |
| Saved (sleeping) agents, trained adapters | Split into pieces and spread across all 12 shelves, so any 4 shelves can be lost | Nothing |
| An agent's work while it's awake | Saved when the agent goes to sleep | Work since it last slept, if its server fails. Agents should send results out as they go. |
| Search indexes (embeddings) | Stored with the agents' data; each records which embedding model made it | Nothing; if the embedding model changes, indexes are rebuilt |
| Training progress | Saved to shared storage every few steps | A few steps of training |
| Settings and configuration | Kept in version control | Nothing |
| What fails | What happens | Who handles it |
|---|---|---|
| A drive | Its copy is rebuilt on another drive. Nothing stops. | Storage software |
| A network switch | Every server moves to the other switch in about a second. | Each server, automatically |
| A server | Model requests go to the other servers in the same pool. Sleeping agents wake elsewhere. Awake agents on that server restart from their last save. | Router, Unovie Agent Runtime, Mesh Arbiter |
| A whole shelf (four servers) | As above, for four servers. The rack loses one twelfth of its capacity until the shelf is back. | Same |
| A training server | Its training job restarts on another training server from the last save. | Training job runner |
| The database server | The standby in another shelf takes over. | Mesh Arbiter |
| Up to two shelves holding cluster control | The cluster keeps working; control is spread over five shelves. | Cluster software |
None of this affects the plants' own fast loop. AgentMesh pods keep running if AgentNexus is unreachable; only the slower, cross-plant work waits.
These figures are estimates built from measurements on single AgentMesh servers and from the open-source projects' own claims. They'll be replaced with measured numbers after the bench tests.
| Resource | Per shelf | Per rack |
|---|---|---|
| Processor cores | 64 | 768 |
| Memory | 256 GB | 3 TB |
| GPUs serving the reasoning model (compressed copy) | 2 | 24 (about 2,250 tokens (word pieces) per second in total, estimate) |
| GPUs serving the same model at full precision, with adapters | 1 | 12 |
| GPUs training adapters (the Kiln, one job each) | 1 | 12 |
| Embedding service | — | 3 copies, on processors first |
| Raw storage | 40 TB | 480 TB |
| Reused from AgentMesh | New for AgentNexus |
|---|---|
| The server, its drives and the add-in storage card · network switches and fast shelf cables · the operating system image · the cluster software · local storage software · the model server (Unovie Runtime) · the Unovie Reasoning Model · the decision server and Unovie Decision Models · the Mesh Arbiter failover service | the Unovie Agent Runtime (agents) · the model router · the Kiln (training) · the embedding model · a database · shared file storage across shelves · a local image store · replicated storage for the most important data |
Apart from three small pieces of our own (the job that switches adapters on, the service that starts training jobs, and the link between the router and the decision model), everything new is open source. The rack runs without internet access: software, models and updates are brought in and checked before use.