Local AI agents, on your own iron.

Apollo, Outreach, Gong, ChatGPT, Claude, every modern AI workflow you have seen sells the same thing under the hood. You push your data to their endpoint, their model runs on their hardware, the answer comes back. The contract says they will not train on it. The architecture says it left your network. For most teams that trade-off is fine. For a meaningful slice of the market it is a hard stop.

A private equity firm cannot send LP statements to a third-party API. A regional bank cannot push customer transaction histories to an endpoint in a different jurisdiction. A hospital cannot route patient charts through a vendor that signed a BAA last quarter but has not been audited yet. A defense contractor cannot let proprietary CAD files traverse the public internet at all. A law firm cannot push privileged communications through an LLM that logs requests for thirty days. The list is long and the answer the cloud vendors keep giving (enterprise tier, SOC2, data residency in your region) does not solve the core issue. The data still leaves your machines.

The other answer is local. Install the agent on your hardware, inside your network, behind your firewall. The model never sees a public endpoint. Your data never leaves. The compute happens on iron you own. We have been shipping this configuration for two years across regulated clients in Hong Kong, Singapore, and the EU, and it is now a productized engagement. If you want to understand whether your workload fits the shape, the AI Strategy Audit is the front door.

Compliance is the loudest reason teams come to us for a local install. GDPR Article 28 processors, HIPAA BAA chains, MAS guidelines on outsourcing in Singapore, HKMA cloud-risk circulars, the EU AI Act provisions for high-risk systems. None of them outright ban cloud AI. All of them make it expensive to defend. Local installs collapse the compliance argument to a single sentence: the data never left the controlled environment. That sentence is worth a lot of legal hours.

Custody is the second reason. When your agent runs on an external API, the vendor controls model behavior, model availability, and pricing. They deprecate a model and you have a migration. They raise prices and you pay. They have an outage and your workflow stops. Owning the model and the compute means the workflow keeps running when OpenAI is down, when Anthropic rate-limits you, when the vendor pushes a behavior change that breaks your prompt chain. The agent answers to you, not to a roadmap somewhere else.

Cost is third and only matters at volume. A team running 10 million inference calls a month on a hosted API is paying real money per call. The same workload on a properly sized local GPU rig amortizes to a fraction of that within twelve months and stays flat after. For teams below that volume, cloud is cheaper and we will say so. For teams above it, local pays for itself. We size the hardware against the workload before we quote anything.

A regional bank in Asia uses a local install to run a copilot over ten years of internal credit memos. The model reads underwriting history, recent transactions, and customer correspondence to draft new memos that a credit officer reviews. Every document stays on bank infrastructure. The model never sees a public endpoint. Officers cut memo drafting time from forty minutes to six minutes per file. Compliance signed off on day one because nothing left the network.

A hospital group runs a local agent over patient charts to draft clinical summaries for physicians. The model is fine-tuned on de-identified internal data and runs on a GPU server in the same data center as the EHR. Physicians get a structured summary, citations to the source notes, and a confidence score. The hospital did the same project on a hosted API two years ago and shut it down after legal review. The local install moved past legal review in a week.

A defense contractor uses an air-gapped install (no internet connection at all) to run code review and document classification over classified material. The hardware sits in a SCIF. The agent reads, classifies, and summarizes without ever touching a network that touches the outside world. This is the extreme case but it works because nothing about OpenClaw or Hermes requires phoning home. For teams thinking about a fractional AI Ops Department but needing on-premise execution, this is the hybrid pattern we end up running.

These are not pilots. They are production workloads moving real money and real clinical decisions through agents running on hardware the customer owns. The reason these workloads exist now is that the models are good enough and the runtime makes the install repeatable. Three years ago you could not run a 70B model on a single GPU. Now you can, and the use cases catch up fast.

Most teams do not run pure air-gap. They run hybrid. The local agent handles anything touching sensitive data and the cloud handles everything else. We set up routing rules so the agent decides per request which path to take. A query about a customer record goes local. A general research question can call out to a cloud model if your policy allows. The policy is yours to write. We implement it as written.

For data sources, the agent reads from internal Confluence, internal SharePoint, on-prem databases, internal Git repos, file shares, anything inside the network that speaks HTTP, SMB, or SQL. RAG indexes get built and refreshed locally on a schedule you control. For identity, we integrate with whatever you run: Okta, Entra ID, Active Directory, custom SAML. The agent inherits your permission model so users only retrieve documents they were already allowed to see.

For observability, logs and metrics ship to your existing stack (Splunk, Datadog on-prem, ELK, whatever you have racked). We do not run a parallel monitoring stack. For backups, model weights and indexes go to your backup system on the schedule your DR plan calls for. The local agent behaves like any other internal service. It plays by the same rules as your other internal services.