Cloud Agents Still Start as a Network Problem

Chuck Benedict — Thu, 12 Nov 2026 16:23:35 +0000

The local model or document tool may already work. Connecting a cloud agent to that named capability can still become a network project.

A developer has a useful model running on a GPU under the desk. A cloud agent could use it for a task right now. The model works. The agent works. Getting one to call the other is where the afternoon goes.

The same problem appears with a local document suite or an MCP server that can work on the files people actually use. The capability is already there. The cloud agent needs a path to it.

So the work becomes construction: make a local service reachable, bridge a stdio server to HTTP, configure a tunnel, decide who can call the endpoint, and maintain the arrangement after the demonstration is over.

None of that runs the model or edits the document. It makes those jobs possible.

The tool arrived before the path

People are already building MCP servers for LibreOffice Writer, Calc, and Impress. Local model servers are similarly easy to start. An available tool, though, is not necessarily a reachable tool. When the agent runs in a cloud service and the capability runs on a private machine, someone must connect the two.

There are sound ways to do that. Anthropic has documented an outbound MCP tunnel for its platform. Cloudflare Tunnel and ngrok can carry requests to a local service without an inbound firewall rule. A proxy can adapt a stdio MCP server for a remote client.

These are useful answers. They also leave an operator to assemble the route, fit it to the agent’s host, and work out which caller should be allowed to use which local tool.

That is the part I keep noticing. The person who wanted to use a GPU has become the integrator of a small network service.

Reachability is only one decision

An outbound connection solves an important problem: the machine with the tool need not accept unsolicited inbound traffic. It does not, by itself, decide who may invoke the tool, how long that permission lasts, or which local capability the caller can reach.

Those decisions matter when the tool can read a document, change a spreadsheet, or consume a GPU. They also matter after a successful demo, when a temporary arrangement begins to look permanent.

Running the tool locally does not mean its data never leaves the machine. A cloud agent may receive prompts, tool arguments, and results. The useful distinction is that the local application and its resources need not be moved to a public host merely to make them callable. What crosses the connection should be understood and governed.

A smaller job for the operator

Suppose the first step were to name the local capability and authorize a particular caller to use it for a particular purpose or window. The machine could establish outbound connectivity, and the operator could spend their time on the model or document rather than building its route.

Some environments will still need custom integration. Some organizations will choose a tunnel they already operate. Those are reasonable choices.

But tunnel assembly should not be the assumed price of using a tool on a machine you control.

The question is why a working cloud agent and a working local tool still need a network project before they can do useful work together.

Cloud agents need tools on machines you control?

See Marketplace · Start a conversation

Sources

This piece first appeared on thirp.net.

What It Costs to Get to the Service

Chuck Benedict — Wed, 11 Nov 2026 13:46:55 +0000

A support ticket can stay open all day before an engineer gets ten minutes with the failing service. What would it be worth to change that?

Suppose an overnight batch misses its window. The vendor’s engineer wants to know whether the transaction service is still making progress. The customer sends the overnight log. It tells the engineer when the batch started. What the engineer needs now is a look at the live queue.

The customer has someone who can run the query. She’s available after lunch. By then the queue may have cleared on its own, which is good news for today’s batch and less helpful to the person who will be on call tomorrow.

In the last field note I wrote about what it costs to take custody of a customer’s diagnostic files. There’s another cost in this exchange. Two organizations have people qualified to answer a fairly simple question, and they spend part of the day arranging for one of them to ask it.

What the ticket clock can tell you

Say the engineer spends twenty minutes reviewing the log and writing instructions, then another twenty on a call walking the customer through the query. Four hours pass between the request and the answer. If the engineer worked other cases in the meantime, charging four hours of labor to this ticket would overstate the cost. The customer still waited four hours. And a live observation that was possible at eight in the morning may be impossible at noon.

I’d keep both figures. Engineer time tells a support director something about staffing. Elapsed time tells the customer something about the service they received. For a missed batch, the more consequential question may be whether anyone got an answer in time to rerun it.

Putting a price against the hours

Thirp Cloud for Support is live now, so there’s an actual price to put against that example. Assume, for the sake of arithmetic, that an hour of support engineering time costs the vendor $100 fully loaded. Substitute your own figure. Here’s how much engineering time a team would have to recover each month to cover the subscription on labor alone.

Published monthly pricing

Customer environments	Monthly subscription	Time to recover across all environments
3	$99	About 1 hour
10	$274	About 2 hours 45 minutes
30	$749	About 7 hours 30 minutes

At thirty environments, two escalations a month that each save four hours would cover $749. The same two escalations saving forty minutes apiece would recover about $133 of engineering time. Both are plausible on paper. Which one resembles your ticket history?

Recovered time matters if the team can use it. Payroll may be exactly the same next month. The benefit might show up as a senior engineer getting through two more cases, or as a customer getting the batch rerun before the next shift starts. I wouldn’t assign a dollar value to either without asking the people who did the work.

The quiet sites count, too

The subscription covers environments through their quiet months. If three customers account for most of the difficult cases, those three may justify enrollment quite readily. The other twenty-seven deserve their own arithmetic. Some may already give the vendor a prompt, approved way to reach the service. Some may need help only once a year. It is entirely reasonable to arrive at different answers for different customers.

There’s also work on the customer’s side. Someone has to review the agent, agree on which service the vendor may reach, and decide who can approve and end a session. A fair comparison includes that person’s time alongside the calls and log collection the existing process asks of them.

Try it against a closed ticket

For the 30-day trial, I’d start with a case both sides remember. Reproduce it in the vendor’s own environment first. Then, with one willing customer, have their approver grant access to the named service, let the support engineer run the diagnostic, and have the approver end the connection. Check the access record together.

How customer approval works

Now put the old ticket next to what you just did. Which calls or handoffs would have disappeared? Which steps would still have taken just as long? Above all, would the engineer have seen the queue while there was still something in it to see?

Support software in customer-controlled environments?

Thirp Cloud for Support is paid, customer-authorized access to one named private Service—without inbound ports, VPN exchanges, or uncontrolled diagnostic bundles. Every plan starts with a 30-day free trial.

See how Support works · Start a free trial