Running agents on hardware you own

The conversation about self-hosting tends to collapse into two positions: hosted is simpler, self-hosted is safer. Both are true enough to be unhelpful, because the decision is rarely made on either axis alone.

Here is how we see it after watching a reasonable number of these deployments.

The reasons that actually drive the decision

Data that cannot leave. Not preference, obligation. Certain regulated categories and certain contracts simply do not permit processing elsewhere, and no amount of encryption changes that.

Existing infrastructure investment. An organisation that already operates substantial compute has a different cost calculation from one that does not, and the marginal cost of running agents on capacity it owns can be very different from list pricing.

Latency to systems of record. If the agent's work involves constant interaction with systems inside your network, running it outside means every one of those interactions crosses a boundary.

Control over change. A hosted platform updates when the vendor updates. Some organisations need to decide when that happens.

Notice that only the first of these is about safety in the way the usual argument means it.

What does not change

The governance layer is identical. Policy enforced at the moment of action, credentials resolved at runtime from an organisation-level vault, a complete audit trail, evals on every run, spend attributed per agent.

This matters more than it sounds. A common failure in self-hosted deployments of other systems is that the governance was part of the hosted product, and running it yourself means rebuilding it. That trade is not one we ask anyone to make.

What does change

You operate it. Capacity planning, upgrades, monitoring of the platform itself rather than only the agents on it. That is real work, and teams that treat it as a one-off installation are usually surprised in the second quarter.

Scaling is your problem. Agent workloads are spiky in a way that is difficult to predict early, because usage grows with confidence rather than with a plan. Capacity that is comfortable in month one is frequently not in month six.

Some conveniences arrive later. Anything that depends on aggregate behaviour across deployments is, by definition, not available in an isolated one.

Air-gapped is a different thing again

Fully air-gapped deployment is not self-hosting with stricter firewall rules. It changes how models and updates arrive, how support works and how problems are diagnosed, since nobody outside can see the system.

It is entirely workable and we support it, but it is worth going in with the operational reality understood rather than discovered.

A reasonable way to decide

If data residency obligations make the decision for you, the decision is made; plan the operational work properly rather than treating it as installation.

If they do not, start hosted, instrument cost per agent, and revisit once you know your actual usage shape. Self-hosting a workload you cannot yet characterise means sizing for a guess.

Next

The deployment pages cover self-hosted and air-gapped options, and the Trust Center covers residency, subprocessors and compliance. Questions about a specific constraint can go to contact@capconsultor.eu.