The cost of running agents outside your network

Most enterprise AI evaluations compare feature grids. Which platform has a visual builder, which has guardrails, which integrates with which system of record. These are reasonable questions, and they are also the questions every vendor is prepared for. The variable that decides more of the outcome, and appears on almost no evaluation scorecard, is a deployment question: does the platform run inside your network, or outside it?

That single choice determines how fast your agents feel, how much of your data leaves your control, and how long your security review takes. This paper sets out the mechanics of each.

An agent is not one request

The intuition most people carry from chat interfaces is that an AI request is a single round-trip: you send a prompt, a model answers. Latency is whatever the model takes to generate, and there is not much anyone can do about it.

An enterprise agent does not work like that. A single request against a real business process typically involves retrieval against a knowledge source, a reasoning step, several tool calls against systems of record, a policy evaluation before anything is written, and a write. Each of those is a separate network operation.

What a perimeter crossing actually costs

When the agent platform sits outside your network, every one of those operations crosses your boundary twice — outbound to reach the platform or the system, and inbound with the result. That crossing is not free, and the cost is not only physical distance.

• TLS termination and re-establishment at the boundary.
• Inspection by your egress security stack — the proxy, the DLP engine, the CASB — on the way out, and again on the way back in. This is the security stack doing exactly what it was bought to do; the agent simply pays for it on every hop.
• Physical distance between the vendor's region and your data centre, which is fixed and cannot be optimised away.
• Queueing at whatever egress capacity your network was sized for, which was not sized with agent traffic in mind.

None of these are large individually. Multiplied across every step of every run, across every user, they are the difference between an interface that feels immediate and one that people quietly stop using.

Sequential execution multiplies the same problem

There is a second, independent source of latency that has nothing to do with the network: whether the platform executes independent steps concurrently or one after another.

Many agent tools are conversational path builders. A topic or a dialog runs its nodes in sequence, and a condition node chooses between alternative paths rather than running them together. That model is a good fit for a conversation, where each turn genuinely depends on the last. It is a poor fit for a business process, where several of the steps have no dependency on each other at all.

Consider an agent resolving a delivery exception. It needs the order record, the carrier's tracking status, the customer's service history and the applicable refund policy. None of those four lookups depends on any other. Executed sequentially, the run costs the sum of all four. Executed concurrently, it costs the slowest one.

Treat the workflow as a graph rather than a script, and wall-clock time becomes the longest path through it rather than the sum of every step.

MouRio models each workflow as a directed acyclic graph, sorts it into levels by dependency, and executes each level concurrently under structured concurrency. Combined with running inside the network, the same agent avoids both the perimeter crossing and the sequential wait — two independent savings that multiply rather than add.

The data question is the one that stops programmes

Latency determines whether people use the agent. Data exposure determines whether it is allowed to exist. In regulated industries the second question is where most pilots die, and it is almost never a technical objection — it is a governance one that nobody can answer cleanly.

When the platform is outside your boundary, every prompt and every retrieved document leaves it. That is not an abstraction: if an agent answers a question by retrieving three internal documents, those three documents have been transmitted to a third party. Each of the following then becomes a live question your team has to resolve before go-live.

• Which categories of data are permitted to leave, and who signs that off.
• Where the data is processed and stored, and whether that satisfies residency obligations in every jurisdiction you operate in.
• What the vendor's retention period is, whether the data is used for training, and how you would evidence either to a regulator.
• What happens to data already transmitted if the contract ends.
• Whether every downstream sub-processor is acceptable, and how you find out when that list changes.

These are answerable. Enterprises answer them every day for SaaS. But answering them takes months of legal and security work, and it has to be repeated whenever the vendor changes its architecture or its sub-processor list.

What this does not solve

Sovereign deployment is not a universal answer, and it is worth being precise about its limits.

• If you call a hosted model API, that call still leaves your network. Sovereignty of the platform does not make the model provider disappear — though it does mean only the prompt leaves, rather than the platform having standing access to your systems. Running an open-weight model inside the boundary closes this gap entirely, at the cost of managing it.
• You are responsible for the infrastructure. Someone has to run it, patch it and scale it. A managed SaaS product genuinely removes that work, and for organisations without a platform team it may be the right trade.
• Sovereign deployment says nothing about whether the agent is well governed. Running inside your network and having no audit trail is entirely possible, and common.

How to evaluate this properly

If you are comparing agent platforms, the following questions surface the difference faster than any feature grid.

• For one representative process, how many network operations does a single run perform, and how many of them cross our perimeter?
• Which of those steps are genuinely dependent on each other, and does the platform execute the independent ones concurrently?
• What exactly is transmitted outside our boundary — prompts only, or retrieved content as well?
• Can the platform be deployed inside our own VPC, and has that been done before?
• If we replace the hosted model with one we host ourselves, does anything else have to change?

The answers tend to separate platforms faster than any capability comparison, because they are architectural. A vendor can add a feature in a quarter. Where the software runs is not a roadmap item.