Replace OS vs Lindy: cloud breadth vs. local depth

Lindy made an early, well-executed bet: the cloud is where work happens. Thousands of SaaS integrations, a polished shared inbox, a managed sandbox where agents can keep working overnight without your laptop being on. For inbound customer ops — leads landing in HubSpot, tickets landing in Zendesk, replies landing in Gmail — the cloud is exactly the right place to be.

Replace OS made the opposite bet: the laptop is where the unreleased, sensitive, half-finished material lives. Repos that haven't been pushed. Design files that haven't been shared. Writing that isn't done. Internal tools that should not be turned into SaaS integrations to satisfy an agent's appetite for surface area.

Neither bet is wrong. They produce very different products because they are aimed at different surfaces. The question is which surface your work actually lives on.

When Lindy needs to act on a file the file goes to the cloud. When it needs to run code the code runs on a cloud sandbox VM. That is the right architecture if the file was already in the cloud and the work was already happening there — the SaaS integrations make it cheap to reach.

When the file is on your disk the round trip is the friction. Upload, wait, sync, copy the result back, repeat. For the work that already lives in the cloud the round trip is free; for the work that lives in your repo or your /Documents folder it is most of the cost.

Replace OS skips the round trip. Each employee has a capability-scoped view of your file system and a curated shell — enough to act on the folder you point them at, without copying the folder to a cloud sandbox first. Destructive actions pause for your OK. Nothing leaves the machine unless an employee uses a tool that explicitly does — and most of the curated tools don't.

Lindy's connector library is the breadth play. Thousands of integrations means almost any SaaS your business already uses is reachable from an agent with very little setup. That is genuinely powerful — and it is something Replace OS deliberately doesn't try to match.

Replace OS ships a curated tool set: file system, shell, web search, web fetch, GitHub via MCP, and a small set of extensions wired in through MCP servers. The catalog is intentionally finite so the defaults are trustworthy. If your work touches a SaaS we don't ship — Notion, Linear, your CRM — the path is the same as Claude Desktop or any other MCP-aware app: install the MCP server, wire it once, the tool shows up.

The trade is real. Lindy gets you to “my agent can read every email and act on it” faster. Replace OS gets you to “my agent can read my repo and act on it” without the file ever leaving the machine.

Lindy's design center is asynchronous. You wire an agent to a trigger — a new email, a new lead, a new row in a sheet — and the agent acts when the trigger fires. The interaction model is closer to Zapier with an LLM than to ChatGPT.

Replace OS's design center is interactive. You DM the CEO, the work fans out to specialists, and you see the work happening (or come back later to see what shipped). There is also a scheduler — employees can run routines on a cadence and surface results when you next open the app — but the headline interaction is DM-driven, not trigger-driven.

The practical implication: if your use case is reactive (“when X happens, do Y”), Lindy is closer to the right shape. If your use case is proactive (“I need to plan this, build this, write this”), Replace OS is closer to the right shape.

Lindy's agents are a flat directory. You hire each one, you wire it to a trigger, you tune the prompt, and it runs when the trigger fires. The mental model is automations — small, reactive, individual agents that watch for an event and act on it. For inbound customer-facing workflows that is the right model.

Replace OS's agents are a hierarchy. A CEO routes; specialists report; peer review is on demand. You don't pick which agent to ask — you describe the outcome and the routing does the rest. For internal builder workflows — the kind that span roles, where the answer to “who should do this?” is “a couple of different employees in sequence” — the org chart is the more honest shape.

Several beta teams run both products. Lindy for inbound customer ops; Replace OS for internal builder workflows. The two solve adjacent problems and the surfaces don't really overlap.

Lindy's cloud posture is responsible — SOC 2 in place, data residency configurable, sensible defaults. For the long tail of SaaS-resident work, that is the right level of care.

Replace OS's local-first posture is a different thing. Conversations, per-employee memory, and any sandboxed files persist in local SQLite on your machine. The shipped binaries carry no provider keys; the only network calls are the ones you make to the model you chose. If you turn the model off, the app still runs against a local model.

The shape of the privacy story matters more than the absolute level. Cloud agents — even careful, well-audited cloud agents — require trusting an additional party with the material they touch. Local agents do not require that trust because the material does not leave the machine. For pre-release code, unannounced launches, draft contracts, and customer data that has not been anonymized, that posture difference is the load-bearing reason to pick a local product.

The shape of the answer for most teams: Lindy lives on the customer-facing edge — inbound email, leads, tickets, anything that already lives in cloud SaaS. Replace OS lives on the internal-facing edge — repos, design files, writing, internal tools, anything that lives on a laptop and has a reason to stay there.

The two surfaces hand off rather than overlap. A lead comes in through Lindy, gets qualified, gets routed to a humans-in-the-loop CRM action; the resulting internal work — a launch plan, a doc, a code change — happens on the laptop in Replace OS. Different products owning different parts of the workflow, which is what we keep seeing in practice.