OpenWorker is a framework that builds your work documents, not your chat history

The AI agent race has mostly been a cloud race. OpenAI's persistent agents live in Slack and run on OpenAI's servers. Claude stays in a browser tab, reasoning session by session. Both ask for a monthly subscription and hand you back a conversation thread, not a finished deliverable.

Andrew Ng's OpenWorker, now in open beta, goes the other direction. It is a desktop app that runs entirely on your machine, uses your API keys, and aims to hand back finished work: a polished document, an updated calendar, a triaged inbox. Not a to-do list, not a plan, but the thing itself.

The project is open source under MIT license and lives at github.com/andrewyng/openworker. Its engine is built on aisuite, another Ng project that provides a unified chat-completions API across LLM providers with an agents layer for tools and MCP support. OpenWorker was originally part of the aisuite repo before moving to its own home.

Local first, cloud optional

The architecture is straightforward: a Python agent server running locally communicates with a desktop UI built in React and wrapped in a Tauri shell. Everything, the agent loop, conversation histories, connector tokens, and model keys, lives in the app's local secret store on your machine. The only cloud piece is a small service that brokers OAuth handshakes for connectors.

That design matters for privacy-sensitive users and for anyone who has watched a cloud-hosted agent change a calendar entry without quite understanding the context. OpenWorker gates every consequential action: writes, sends, and shell commands require the user to approve first. Unattended scheduled runs park their requests in an inbox instead of acting autonomously.

Model flexibility as a feature

Where OpenAI and Anthropic lock you into their models, OpenWorker ships with no model at all. You bring your own API key for any supported provider: OpenAI, Anthropic, Google Gemini, DeepSeek, Qwen, Mistral, Grok, and a dozen more, plus open-weight models via Together and Fireworks, and fully local models via Ollama.

The project maintains a curated model list of what it has verified for tool-calling work. Adding any arbitrary model string is possible but comes with a warning. That is a practical concession: tool-calling quality varies wildly across models, and a bad tool call on a desktop agent means more than a wrong answer in a chat window. It means a file system change or a sent message that has to be undone.

For users who want to run fully local inference, xAI's Grok Build open-source release shows a similar commitment to local-first agents, while Unsloth's GGUF quantization makes running large models on consumer hardware more feasible.

25+ connectors and MCP support

OpenWorker ships with over 25 integrations covering the usual productivity stack: GitHub, Slack, Jira, Notion, Linear, HubSpot, Outlook, monday.com, Gmail, and Google Calendar, plus terminal access and local files. Any tool reachable over the Model Context Protocol also plugs in, with per-tool control.

The Slack integration is notable: mention @OpenWorker in a channel, and a session opens on your desktop. The work happens with your tools, and the answer comes back as a thread reply. That design means the agent is visible to the team without living in the cloud or requiring a shared subscription. This approach aligns with Hugging Face's Moon Bot, which also brings AI assistance into Slack channels, though with a cloud twist.

The timing question

OpenWorker arrives at a curious moment. OpenAI's persistent agents, announced in March 2025, run scheduled tasks in the cloud and integrate with Slack, but they are tied to OpenAI's models and infrastructure. Anthropic's Claude remains focused on single-session reasoning with no persistent agent offering.

OpenAI just made workers you can schedule, and the enterprise response has been cautious. Giving an agent access to your calendar and email is one thing when it lives in your browser session. It is another when it persists in the cloud and acts on a schedule.

OpenWorker addresses that caution by making everything local and approval-gated. The trade-off is that the user must manage their own keys, their own infrastructure, and their own updates. The app auto-updates and the macOS build is signed and notarized, but the Windows builds are not yet code-signed, so SmartScreen warns on installation. That gap matters for the enterprise adoption Ng likely has in mind.

Other projects are tackling similar local-first challenges. PraisonAI's five-line deployment offers a lighter-weight alternative for autonomous agents, and Kimi K3's $314 billion shake-up underscores the broader cost dynamics driving local models.

Compared to the alternatives

OpenClaw, another local agent launched on Ollama 0.17, focuses specifically on inbox and email management. OpenWorker is broader in scope but also heavier: it requires Python 3.10+, Node 20+, and for the desktop shell, the Rust toolchain. Running from source is a multi-step process with two terminals. The prebuilt downloads are the intended path.

Where OpenAI's agents are a product you pay for, OpenWorker is a reference you run. The README is explicit: "This repo is a working reference for what aisuite can carry." That framing is honest but limits its reach. A reference implementation that requires a developer workflow to run is not yet a consumer product. OpenCode's tabbed navigation illustrates how developer tooling can smooth out multi-session workflows, a lesson OpenWorker might internalize.

The pitfalls of parallel agent architectures are also relevant here, since OpenWorker's local design sidesteps many of the concurrency headaches cloud agents face.

The bet on finished work

The most interesting design choice is the output format. OpenWorker does not stream tokens. It delivers files: documents, spreadsheets, reports, and web pages that land on your desktop as openable, shareable objects. That is a subtle but important shift in how we think about AI assistants. A chat that ends with "here is a draft" is a conversation. A chat that ends with a .docx file on your desktop is a coworker.

Whether users actually want a coworker rather than a conversation is the open question. Chat interfaces are forgiving: you can refine, ask for changes, start over. A finished document assumes you knew what you wanted when you asked. OpenWorker's approval gates are meant to catch that mismatch, but the user still has to notice that the output is wrong before approving it.

Ng's project is not trying to disrupt OpenAI or Anthropic. It is building a different path: local, open, model-agnostic, and output-focused. The next few months will show whether that path has enough users to sustain development beyond the current MIT-licensed beta.