OpenWorker by Andrew Ng: A Review of the AI Agent That Does Tasks, Not Just Answers

At the end of July 2026, the OpenWorker project was released as open source. Its author, Andrew Ng, is a co-founder of Coursera, led Google Brain and headed Baidu's AI group. When someone with that record puts code in the open, it's worth five minutes to find out what's really there, rather than retelling a headline from social media.

I checked the facts against the repository and independent reviews, because figures that don't match each other have already spread around the release. Here's the honest version: what's confirmed, and what the author of the description slightly rounded.

How OpenWorker differs from an ordinary chatbot

The difference is in one word: outcome. Most AI tools hold a dialogue and expect you to take the answer to a finished state yourself. OpenWorker takes the whole task.

Examples from the project's documentation:

• - you ask it to prepare a customer brief, and you get a finished document, not a draft of talking points;
• - you ask it to sort your Slack inbox, and the agent sends the replies itself instead of offering text options;
• - you ask it to update your calendar, and the entries change, instead of a "what needs to be done" list appearing.

That's the key idea of an agent as a class of tools: an executor, not a chat. OpenWorker is one of the first large open source projects to show this difference at the level of a finished application, not a code sample.

How many connectors there really are: 25+ in the description, 40 in the code

The project's README claims "25+ connectors." An independent source code review (mer.vin, August 2026) gives a more accurate picture: the repository registers 40 connector descriptors, 7 of them marked unavailable, so 34 are actually active, and together they expose 151 separate functions to the agent.

The gap between "25+" in the description and 34 working connectors isn't deception. It's ordinary practice in open projects: authors round down so they don't overpromise while some integrations are still unstable. For you as a user this means one thing: before building a workflow around a specific service (Slack, GitHub, Jira, Notion, Linear, HubSpot, Outlook and Gmail are on the list), check its status in the current repository rather than trusting only an article's headline.

Where the data is stored and whether you can work fully locally

OpenWorker runs as a desktop app: the interface is built on Tauri and React, and all the logic runs on a local server on your computer. By default, data doesn't go to the developer's server.

You pick the reasoning model yourself. You can connect a cloud provider (OpenAI, Anthropic, Google and others through the single aisuite layer, Andrew Ng's own framework), or run everything fully locally through Ollama or your own endpoint such as self-hosted vLLM. In that case data physically never leaves the device, because the model computes on the same computer where the agent sits.

It's the same principle I covered in the article on free open models in 2026: running locally saves on subscriptions, but it needs your own hardware and an hour of setup at the start.

Hardware and platform requirements

Here's another correction to the popular retelling. On social media OpenWorker is sometimes described as a "Mac only" tool. In fact, ready-made builds exist for macOS on Apple Silicon and for Windows 10 and 11 (x64). There's no ready-made signed Linux build, though the repository has a script for installing from source (packaging/bootstrap_linux.sh, docs/linux.md). Linux support remains one of the frequent open requests from users in the project's issues (for example #414, #232, #171).

The app itself is free and open source under the MIT license. You pay only for the model if you chose a cloud provider rather than running locally. With local running, the only expense is electricity and hardware you already bought.

Governance: what the agent won't do without your permission

The project builds in hard limits on operations the agent can't perform without a person's explicit confirmation (the project documentation calls this mechanism Hard floors), and a model of "earned autonomy": the more often the agent handles simple tasks without errors, the more independence it's given at the next level. Every agent action goes into an audit log you can view separately.

For an expert without an engineering department, this matters more than the connector list. An agent that automatically sends real Slack messages or changes calendar entries has to have a clear boundary between where it asks permission and where it acts on its own.

What to do with this if you're not a developer

OpenWorker is still an open beta project on GitHub, not a ready commercial app with an "install and it all works" button. You need to download the build, connect connectors, pick a model and set up access once. For an expert who wants to automate routine work but isn't ready to deal with a repository and API keys alone, it makes more sense to look at the difference OpenWorker shows (the agent does the work instead of just answering) and carry the same logic over to a ready-made system built for your specific task.

That's exactly what I do: I build "does the work, not just answers" systems for an expert's specific niche, without you having to dig into code. If you want to figure out where to start building such an agent for yourself, message the word АССИСТЕНТ to the bot on Telegram, and after you subscribe to the channel «Растём с ИИ» I'll send the free guide "A Personal Assistant in One Evening," with three starting levels and a system instruction for your first agent. And if you need a ready-made system for your whole niche, you can start with a free consultation.