A truly local computer use agent in the EU is local execution plus EU-region reasoning, not magic

What “local” actually means for a Mac desktop agent

A desktop agent is not one thing. It is a stack of four data layers, each of which makes its own residency decision. The word “local” only makes sense once you know which layer is being described.

• Screen content. What the agent reads off the screen to know what is there. In Fazm this is an accessibility-tree query against the focused app: roles, labels, values, hierarchy. Stays on the Mac.
• Voice input (optional). If you talk to the agent. Default Fazm transcription routes through Deepgram (cloud, US-based). Disable voice or swap to an on-device model if voice is part of your compliance scope.
• Model reasoning. Where the next-token decisions happen. Claude family by default, hitting api.anthropic.com unless you point the agent elsewhere. This is the layer the EU residency conversation is about.
• Working memory. The agent's knowledge graph, file index, AI user profile, and chat history. Local SQLite on the Mac. The schema is in Desktop/Sources/FileIndexing/KnowledgeGraphRecord.swift if you want to read it.

The reasoning layer is the one with a US default

This part trips most evaluators. People hear “local agent” and assume the model is local too. In 2026 that is rarely true on consumer hardware: frontier model quality on long-horizon agentic workloads still lives in cloud-hosted endpoints. The honest pitch is local execution plus configurable EU-region reasoning.

The implication for an EU shop running a Mac agent: the direct Anthropic API is not your EU path. AWS Bedrock has Claude models in eu-west-1 (Ireland), eu-north-1 (Stockholm), and via cross-region inference profiles in eu-central-1 (Frankfurt) and eu-west-3 (Paris). Vertex AI exposes Claude models across ten EU regions with regional endpoints. Either of those is a valid EU residency path. The trick is wiring your desktop agent to talk to them.

The wiring is one Swift file and one text field

Fazm exposes the swap as a setting. Open the app, go to Settings > Advanced > AI Chat, scroll to Custom API Endpoint, paste an Anthropic-compatible URL, hit return. The bridge restarts automatically and the next message goes to that URL.

The Swift wiring is small enough to read in one sitting. The setting is declared at Desktop/Sources/MainWindow/Pages/SettingsPage.swift:885 as a SwiftUI @AppStorage("customApiEndpoint"). The injection happens in Desktop/Sources/Chat/ACPBridge.swift:467-470:

Anything that speaks the Anthropic message protocol works on the other end: an Anthropic-compatible shim in front of Bedrock-EU, the same in front of Vertex-EU, a corporate proxy, or a local model server with the same surface. The agent on your Mac never has to know the difference. The full source is at github.com/m13v/fazm; verify the snippet, then verify the rest.

Three EU-friendly destinations, one variable. The clicks, typing, file ops, and AX-tree reads on the left side never change shape regardless of which destination is live. That is the whole point: the layer that handles the user's screen and apps is local; only the reasoning hop is configurable.

EU endpoints, ranked by setup effort

The four practical paths for keeping the model layer EU-resident, in roughly increasing order of work to set up.

None of this requires changes to Fazm itself. The agent does not care which Anthropic-compatible endpoint serves it; it just sets ANTHROPIC_BASE_URL on the subprocess and continues.

Why an accessibility-tree agent fits the EU story better than a screenshot agent

Two architectures dominate the computer-use category. Screenshot agents read the screen by capturing pixels and sending them to a vision model on every step. Accessibility-tree agents query a structured representation of UI elements that macOS already exposes for screen readers. Under an EU residency lens, the two architectures differ a lot, even if both point their model calls at the same EU region.

• Data minimization. A screenshot agent transmits the entire visible window on every step: chat threads, customer records, browser tabs, anything that happens to be on screen. An AX-tree agent transmits only the structured slice the model needs to decide the next action, and only at decision points.
• Volume of cross-border calls. Screenshot agents make one model call per click, per scroll, per keystroke decision. AX-tree agents make most action steps with no model call at all (find element by role, click, type, read response). Even when both call out to an EU endpoint, the AX-tree path moves an order of magnitude less user data.
• Audit surface. Pixel uploads are hard to reason about for a DPO. Structured element data is auditable: you can log exactly which fields were read, which elements were acted on, which strings the model saw. Open source widens the audit further; the AX-engine code is in Fazm's repo and reads like documentation.

Both architectures can be deployed against an EU model endpoint. The accessibility-tree path is the easier compliance story because it sends less data, less often, in a more legible format.

A practical EU setup for Fazm in 30 minutes

For a small EU shop that wants the model layer kept in-region. Order matters: the bridge picks up the new endpoint on its next restart, so flip the toggle last.

1. Pick the EU model path. AWS Bedrock in eu-west-1 (Ireland) or eu-north-1 (Stockholm) for direct Claude access; Frankfurt and Paris work via cross-region inference profiles. Vertex AI works the same way across its EU regions. Pick whichever your organization already has a contract with.
2. Stand up an Anthropic-protocol shim in front of that endpoint. Open-source proxies exist that translate between Bedrock's InvokeModel API and Anthropic's message format; one of them deployed inside your EU VPC is enough. The shim's URL is what you paste into Fazm.
3. In Fazm, open Settings > Advanced > AI Chat. Toggle Custom API Endpoint on and paste the shim URL. Hit return. The ACP bridge restarts. Verify with lsof -i -p <agent-pid> that traffic is going to your shim, not api.anthropic.com.
4. Decide on voice. If you need it and EU residency on audio matters, disable Deepgram-based transcription in Settings or swap to an on-device model. If voice is not part of your workflow, leave it off.
5. Document the configuration. The architecture decision your DPO cares about is: screen pixels do not leave the Mac, model traffic terminates in the EU region, working memory is local SQLite. All three are inspectable in the Fazm source on GitHub.

What separates an honest EU-friendly agent from a marketing claim

Three checks I would run on any desktop agent that markets itself to EU users. None of these require an NDA or a procurement call.

1. What does the agent read from the screen? If the answer is “screenshots,” pixel data leaves the machine on every step. If the answer is “the accessibility tree,” structured element data leaves only at decision points. Read the source, do not trust the architecture diagram.
2. Can the model endpoint be changed without a rebuild? A user-facing setting that injects a base URL into the agent subprocess counts. A hard-coded SDK call does not. Fazm passes this with one text field; many agents do not.
3. Is the source readable? You cannot audit either of the above on a closed agent. Open source is the only way to verify the EU swap path is a real piece of code and not a slide.

Fazm passes all three by construction: AX engine, customApiEndpoint setting, MIT-licensed source on github.com/m13v/fazm. That does not eliminate every cross-border data question; it shrinks the surface area to one configurable hop and makes the rest verifiable from the repo.