Running AI agents locally for business workloads

Recommending an architecture you have not run is guessing. Before proposing local AI to a client, the reasonable thing is to operate it — so agents run locally on a Mac Studio as an internal working environment rather than as an experiment.

Public discussion of local AI tends to be either enthusiasm or dismissal, and both are usually based on benchmarks. Benchmarks answer how fast a model produces tokens. They do not answer whether the thing is pleasant to rely on for actual work, what breaks, or what it costs in attention.

I use it as my default environment for real work and pay attention to where it disappoints me. I route workloads deliberately — sensitive or routine work locally, heavy or non-sensitive work hosted — and let the boundary emerge from experience rather than from a principle I decided in advance.

A working local environment used daily, with an honest boundary between what belongs on local hardware and what does not — which is the input that makes client recommendations credible.

1. 01Latency is not the interesting variable. Whether the setup is reliable enough that you stop thinking about it matters far more than tokens per second.
2. 02Privacy is the strongest argument for local, and it is an architectural argument rather than a compliance one. Running on-premise does not by itself satisfy any regulation.
3. 03Hardware has an operational cost that local-versus-cloud comparisons routinely omit — somebody owns the machine, its updates and its failure.
4. 04There is a ceiling. Local models are excellent for a large class of work and worse for another, and being honest about which is which is the useful part.