The Week Proximity AI Stopped Being a Pitch

By Bart de Witte, Founder, Isaree 24 June 2026

We shipped our macOS agent harness, integrated openEHR, survived a hackathon, and watched the cloud-vs-on-device debate collapse under its own weight. Here's what happened.

Last week, in the previous post, I argued that the long tail of clinical AI, the n=1 workflows, the personal agents, the stuff nobody commissions from IT, is where the real value lives. I argued that the rental model and "tokenmaxxing" kill the ROI before it ever materializes. And I argued that proximity AI, running on the clinician's own device, is the only architecture that makes the economics work.

This week, we stopped arguing and started shipping.

After having build the worlds first multi-agent orchestrator that runs on a phone, we launched the macOS version of our agent harness, integrated it with one of Europe's largest openEHR providers, tested it with real clinicians at a hackathon, and sat on a panel where the cloud-versus-on-device debate turned out to be asking the wrong question entirely.

Let me walk you through it.

We shipped the harness

The macOS version of the Isaree agent harness is live. If you're a clinician, or anyone, really, you can now download it, open it, and build your first agentic workflow on your own machine. No API keys to rent. No cloud account to provision. No per-token meter ticking in the background while you work.

The harness is exactly what it sounds like: a frame that lets you build, run, and iterate on AI agents locally. You describe what you need in natural language. The harness wires it up. You test it. You refine it. You deploy it. All on your device.

This is the interface I wrote about last time, natural language as the new GUI. The cardiologist who can't write SQL can describe exactly what she needs. The nursing team that has never seen a Python file can build a shift handover agent. The harness is the thing that turns that description into a running workflow.

But a harness is only as valuable as the things it can connect to. So we added two.

Local MCP servers, connecting your agents to the real world

A harness is only useful if it can reach the data and tools a clinician actually works with. That's why we built local MCP servers, small bridges that let your on-device agents connect to the things on your machine, without any of it touching a cloud.

MCP isn't limited to one thing. An agent can connect to your mail, read and sort incoming messages, and draft replies. It can access sensitive files stored on your desktop, clinical guidelines, patient case notes, research papers, in a sandboxed environment where the data never leaves your device. And it can operate as a computer-use or browser-use agent: navigating your desktop applications, opening websites, filling forms, pulling data from a portal, pasting it into a letter, doing what you'd do, on your screen, under your control.

For most people, that sounds like a productivity feature. For a clinician, it's something else entirely. Here's what becomes possible when your agents can reach your local files, your desktop applications, and the web, all on your own machine:

Sandboxed access to sensitive local files. A clinician keeps clinical guidelines, treatment protocols, departmental SOPs, and patient case notes on their desktop, the kind of data that should never be uploaded to a cloud API. An agent that reads those files, cross-references them against a patient query, and drafts a recommendation grounded in the actual protocol the department follows? That only works if the data never leaves the machine. With a local sandbox, it doesn't.

Computer-use agents for your desktop applications. An agent that opens the hospital's EHR, navigates to a patient record, pulls the relevant data, and pastes it into a discharge summary template in your word processor, while you watch and approve every step. The clicking and typing you'd do yourself, done by an agent, on your own screen, with no data routed through a third-party server.

Browser-use agents for clinical research. An agent that opens a clinical reference website, searches for a drug interaction or the latest guideline update, reads the results, and brings the answer back into your workflow, without you leaving your current task and without the page content being sent to an external API.

Mail as one input among many. And yes, an agent can also connect to your inbox, read incoming messages, and draft replies. A clinician's inbox is a war zone of referrals, lab notifications, and admin circulars, buried somewhere in which is a critical value that needs action now. An agent that classifies by clinical urgency and surfaces what actually matters? That's a patient safety intervention. But mail is one connection, not the whole story, and that's the point.

Each of these is an n=1 workflow. Personal. Specific. Built by the person who does the work. None of them requires a cloud API. None of them generates a per-token bill. None of them sends patient data to a server in a jurisdiction the clinician has never heard of.

And this is where it gets interesting, because now the harness can talk to your mail, your local files, and your desktop and browser. It can also talk to the electronic health record.

We integrated with Vitagroup's openEHR

This is the piece I’m proudest of, given how close the openEHR community is to us.

Vitagroup is one of Europe's leading openEHR providers, and this week we officially integrated the Isaree harness with their platform. openEHR is the open standard for electronic health records — built to last and built to interop, regardless of which vendor's system you're running.

What does this mean in practice? A clinician's on-device agents can now work with the EHR directly:

• Query the record — ask in natural language ("every patient on my ward with a specific diagnosis") and get the answer, translated and validated by the agent before it ever runs.
• See what's available — the agent can inspect the structure of your clinical records to understand what data fields, coded values, and relationships exist before building a query.
• Get help writing the query — if you're not sure how to phrase it, the agent guides you through it, grounded in the real templates in your EHR, and checks it for errors before it touches the database.

Now connect the dots. A clinician has the harness on their Mac. The harness can read their mail, access their local files, operate their desktop and browser, and query their EHR. A workflow that reads an incoming referral email, extracts the patient identifier, queries the EHR for existing conditions and medications, checks for contraindications, and drafts a clinical summary for the clinician to review — that's not a roadmap feature. That's an afternoon's work with the tools we shipped this week.

And every step runs on-device or point-to-point. The email stays local. The files stay local. The EHR query goes directly from the device to the EHRbase server, no intermediary cloud, no third-party API processing the data. The agent orchestrates. The clinician decides. The data stays where it belongs.

We went to a hackathon

The same week we shipped, we tested the macOS version with real users at a hackathon organized by Google, PwC, and the largest university hospital in Schleswig-Holstein. Real clinicians. Real problems. Real pressure.

Our Moto: Own your Intelligence

Here's what happened: people built things. Not demos. Not slide-ware. Working agents that did things they needed done. And because the harness is designed to connect to other MCP servers, some of the hackers started adding their own — plugging in data sources, tools, and services that we hadn't thought of. The harness got more valuable with every server someone added. That's the network effect of an open architecture: every new connection makes every existing connection more useful.

This is the thing about giving people tools instead of products. You don't have to predict what they'll build. You just have to get out of the way.

The panel that asked the wrong question

The most interesting part of the hackathon wasn't the hacking. It was the conversations. I participated in a panel on cloud versus on-device AI. I understand that panels need debates. But the premise is false.

The question "cloud or on-device?" assumes a binary. Our proximity AI architecture doesn't ask you to choose. It supports multiple layers, on-device inference for the workflows that need to be local, fast, private, and free of per-token metering, with the ability to reach out to larger models or cloud resources when the task genuinely demands it. The point isn't that everything must run locally. The point is that the default should be local, and the cloud should be the exception, not the other way around.

Here's why that matters, and why the cloud-first crowd is starting to look nervous.

The cost explosion is here, and it's not theoretical

In my last blog, I argued that the rental model kills ROI when the total volume of transactions is high — which it always is in healthcare, where every patient encounter, every lab result, every referral is a transaction. I said that tokenmaxxing, the practice of maximizing token consumption as a proxy for productivity, was unsustainable.

Since then, the data has come in, and it's worse than I thought.

Uber burned through its entire 2026 AI budget in four months. By April. The company that encouraged employees to use AI "as much as possible" and even ranked them on internal leaderboards had to cap spending at $1,500 per employee per month. TechCrunch reported that the glut of token spending "hadn't translated immediately into useful releases."

Atlassian's monthly AI spend tripled — from around $5 million in August 2025 to more than $15 million by May 2026. According to leaked internal communications reported by 404 Media, employees "changed their workflow to maximize AI usage, and now they run out in 2-3 days." Not months. Days. Employees blow through their monthly token allocation in two to three days and then wait three and a half weeks for the meter to reset.

Tesla capped employee AI spending at $200 per week. Coinbase instituted weekly caps ranging from $500 to $5,000. Accenture started warning employees not to deplete token reserves on basic tasks like converting PDFs to slides — the same Accenture that previously threatened employees with losing promotions if they didn't use AI enough.

And the punchline from Sam Altman himself, on stage: "It went from, at the beginning of this year, an issue that never came up — people were totally happy with the amount they were spending — to, all of a sudden, a huge issue."

The ROI isn't coming

A KPMG survey of 2,145 global business leaders found that nearly half, 49%, have already scaled back AI agent deployments because costs outweighed the benefits. Only 7% report established ROI. Let me say that again: 7%. After billions of dollars and years of hype, 93% of organizations cannot demonstrate that their AI investment has paid for itself.

Gartner estimates that AI coding costs will surpass the average developer's salary by 2028. Goldman Sachs predicts a 24-fold increase in global token consumption by 2030, driven by agents. More tokens, more cost, more pressure on a model where every single prompt adds to the bill.

This is the structural problem with renting your agentic performance. In traditional software, the biggest users are the most profitable — the cost of serving them barely rises once the software is built. AI inverts that logic. Every prompt consumes compute. Every agent invocation costs money. The more you use it, the more it costs. And the more valuable it becomes — the more you embed it into daily workflows, the more you depend on it — the more exposed you are to a pricing change that arrives in an email from your vendor on a Tuesday morning.

The healthcare translation

Now apply this to a hospital. Not Uber. Not Atlassian. A hospital.

A 1,000-bed hospital with 500 clinicians running 5 AI agents each per day. Every patient encounter is a transaction. Every lab result is a transaction. Every referral, every discharge summary, every medication reconciliation, all transactions. The volume is enormous, and it never stops.

Under the cloud rental model, that hospital is paying per token for every single one of those transactions. And the cost goes up every time a clinician finds a new way to use the tool, which is exactly what you want them to do. You want adoption. You want the long tail. You want 60,000 agents. But the pricing model punishes you for exactly that.

In the last blog, I modeled the 3-year TCO for a 10-clinician practice running 5 agents per day. Local AI on Apple Silicon: €9,315. Claude 4 Sonnet via cloud API: €75,673. A credit-based orchestration platform: €183,298. The models are good enough. The cloud costs aren't.

And that was before the latest round of price shocks. The gap has only widened.

The long tail wins — but only on the right architecture

Here's the thread that connects all of this — the harness, the MCP server, the openEHR integration, the hackathon, the panel, the cost data.

The long tail is the most important part of the AI revolution. The n=1 workflows. The personal agents. The 14% that sit outside any formal department. The stuff that saves 15 minutes per clinician per day and compounds across 500 people into 7,000 hours a month. The stuff that no vendor will build for you, because the market for each individual workflow is exactly one person.

But the long tail only works if the economics of building and running each agent don't collapse under volume. Off-the-shelf cloud agents don't work for n=1 problems, they're too generic, too expensive per transaction, and too disconnected from the clinical context. And the rental model, where every invocation adds to the bill, kills the ROI before the long tail ever materializes. You can't afford to let 500 clinicians build 5 agents each and run them 30 times a day when every run costs tokens.

This is where proximity AI changes the equation. When clinicians run their agents and their workflows in a harness that acts as a sandbox — on their own device, with their own data, at a marginal cost that approaches zero — the productivity gains are real. They show up in your accounting books, not in a metered dashboard that resets every month. You don't cap usage. You don't ration tokens. You don't build a leaderboard to gamify consumption and then tear it down when the bill arrives.

You just let people build. And they do.

We watched it happen at the hackathon. We're watching it happen with our cohort of clinical innovators. And the data from Uber, Atlassian, Amazon, and the KPMG survey tells us what happens when you bet on the other model.

The fork in the road I wrote about last time? We took it. This week, we shipped the tools that make the choice concrete. The harness is on macOS. The MCP servers connect to your mail, your files, and your desktop. The openEHR integration connects to your EHR. The agents run on your device. The data stays local. The cost is fixed.

We updated the website

Last but not least — we updated isaree.ai. New look, clearer message, same mission: democratizing clinician-empowered, on-device AI. Go take a look.

The week is over. The work continues.

We're onboarding our next cohort of clinical innovators. If you're a clinician who wants to build the agents your hospital needs — on your own terms, on your own device, with your own data — join the waiting list. The harness is ready. The MCP servers are ready. The openEHR integration is ready.

All that's missing is you.

Bart