Agentic labor compression on the desktop is bounded by reach

The thesis

There is a category of business writing on AI agents that goes: pick a knowledge job, list the tasks, multiply hours by people, declare that one agent replaces 0.7 of a person, ship the slide. The number is satisfying because it is concrete. It is also wrong in a specific way: it assumes the agent can reach all of the work. In practice, the fraction of headcount you can compress equals the fraction of your team’s real apps the agent can drive, minus the fraction of the work that is judgment-heavy enough that no model is going to pick it up this year.

That changes how you size the impact. You stop asking “how good is the model” (which is the same answer for everyone, because the leading models are within a tight band) and start asking “how many of my team’s apps can the agent actually click around in”. The answer to that question is what determines the compression ratio. The answer is also where the products are most different.

Where the work actually lives

A small business or ops team on macOS spends most of a workweek in roughly the same set of surfaces: a browser (gmail, calendar, the CRM, billing portal, bank), a few native apps (Slack desktop, the IDE if there is one, Numbers or Excel, Preview for PDFs, Notes), an Electron grab-bag (Notion, Linear, Figma, design tooling), and a constant stream of small popovers and OS chrome (file pickers, share sheets, signing prompts, keychain dialogs). The browser is one bucket. Everything else is at least four other buckets.

Pull a representative week and you see the same shape: a single repetitive task usually crosses two or three of these buckets. “Onboard a new customer” means a CRM update, a calendar invite, a contract sent through a signing app, a Slack ping to the channel, and a row in a spreadsheet. “Reconcile yesterday’s sales” means the bank web app, the spreadsheet, an export from the POS desktop client, and a pasted summary into Slack. None of that lives in a single tab.

The compression formula, written down

Here is the calculation that survives a finance team:

compressible_hours_per_week =
  Σ (task_minutes × tasks_per_week) / 60
  for each recurring task that is
    (a) repeatable, and
    (b) well-defined, and
    (c) lives in an app the agent can drive.

agent_recovered_hours =
  compressible_hours_per_week
  × reach_factor          # share of those apps the agent reaches
  × (1 − supervision_haircut)

headcount_compressed = agent_recovered_hours / 40

Two terms in that formula are usually skipped on slides. reach_factor is what the agent can actually open and click. supervision_haircut is what the human still has to look at. Skipping them is how you get the “one agent equals four FTE” quote that does not survive a quarter of real usage.

Why surface area is a product decision, not a model decision

Three real product choices set reach_factor, and they are all things the user buys, not the model produces.

One: where the agent looks. A pixel-based agent reads screenshots and infers what is clickable from images. That works on demos and breaks on the long tail: dynamic ARIA-only controls, native menus that pop up below a screenshot, popovers that close before the next frame, dark-mode skins it has not seen. An accessibility-tree agent walks the same data structure VoiceOver uses, gets stable role and label and frame for every element, and can act with a single AX query at sub-50ms latency instead of a 200ms-to-1s screenshot-and-recognize cycle.

Two: which surfaces are wired. Even an AX-aware agent only reaches what the product wired up. Fazm’s bridge gives the model nineteen first-party tools (defined in acp-bridge/src/fazm-tools-stdio.ts), plus four MCP server integrations wired in acp-bridge/src/index.ts: playwright (browser), macos-use (native AX-tree control of any Mac app), whatsapp, and google-workspace. macos-use is the multiplier; it turns “every Mac app that exposes AX” into one tool slot.

Three: who holds the session. If the agent runs in someone else’s cloud, your reach is bounded by what your IT team is willing to OAuth into a third party. If the agent runs locally inside your existing macOS session, your reach is bounded by what you are already logged into on your laptop, which is, by definition, every app you actually use. The two ceilings are very different in practice.

A worked example

One person on a five-person ops team spends roughly the following on recurring desktop work in a normal week:

• CRM updates after calls: 3.5 hours, lives in browser CRM and the calendar app.
• Invoicing and billing reconciliation: 2.5 hours, browser bank + native spreadsheet + native PDF preview.
• Calendar reshuffles for client meetings: 1.5 hours, calendar app + email + Slack desktop.
• Inbound triage and follow-up: 4 hours, gmail web + Notion or Linear + the CRM.
• Document signing chase-ups: 1 hour, docusign web + native PDF + Slack.

Total: 12.5 hours of compressible recurring work per person per week. About 6 of those 12.5 hours live entirely in a browser tab. The other 6.5 cross into native or Electron apps that an AX-tree agent reaches and a browser-only agent does not.

Apply the formula. With a browser-only agent at a 70 percent supervision factor, you compress 6.0 × 0.70 = 4.2 hours per person per week, or about 21 hours across the team, half a person. With an AX-tree agent at the same supervision factor, you compress 12.5 × 0.70 = 8.75 hours per person per week, or about 43.75 hours across the team, just over one full person. Same model, same prompts, same five people. The delta is reach.

Where the framing fails

Compression is not the right lens for everything. Three places it overpromises:

Judgment work. Picking which deal to pursue, which clause to push back on, which candidate to advance. No reach factor saves you here, because the bottleneck is the decision, not the clicks around the decision. The honest framing: the agent compresses the surrounding work so the human spends more of their time on the decision and less on staging it.

One-off and creative work. Compression assumes recurrence. If you write a custom proposal once a quarter, an agent saves you maybe 20 percent on the boilerplate. The headcount math does not move.

Work that depends on tribal knowledge. If the rule for which discount to apply lives only in someone’s head, the agent cannot compress it without a knowledge step first. That is solvable (Fazm has a save_knowledge_graph tool for exactly this), but it is its own project, not a free lunch.

What to do with this

If you are sizing an agent project for a real team, do the boring version of the analysis: write the fifteen recurring tasks, mark which ones cross out of a browser tab, sum the hours, and apply a 30 to 40 percent supervision haircut. If your team’s tasks live mostly inside a browser, a browser-only agent is fine. If they cross into native apps (almost every small ops team), you need an agent that walks the accessibility tree, not pixels, and runs locally enough to be inside your existing logins.

That is the version of the math we built Fazm against. The tools list is in the open repo so you can audit the surface area before you trust the ratio.