Andrew Ng shipped an AI coworker that works on your machine, and still lets you keep control

Four days ago Andrew Ng released a new repo called openworker. His name alone guarantees attention, and in just a few days it had already picked up over fifteen hundred stars. So I cloned it and read the whole codebase to see what it actually is, and what's worth taking from it.

I've reviewed a few of other people's skill repos before. This one is different. openworker isn't a pile of skills, it's a full platform for something a lot of people are talking about right now: the "AI coworker," an AI that works alongside you rather than just waiting for you to ask.

Upfront, plainly: this is a review from reading the code, not from running it in production for a month. I cloned the repo and read through the architecture and the code. For the things it advertises it can do, I quote what the repo states, and I keep it separate from what I saw directly in the code. Three parts: first what openworker is, then the idea worth borrowing, and finally who it's for and who it isn't.

Part 1What openworker is

The shortest version: an AI that finishes work into a deliverable, instead of just replying with text for you to act on. You give it a goal, like "turn this month's sales into a report," and it breaks the work into steps, opens files, runs commands, reaches into the apps you've connected, and hands back a real, usable artifact. That's the difference from an ordinary chatbot that stops at typing an answer back.

The other half of the idea is local-first. It runs on your own machine as a desktop app; the model keys and your data stay on it. You bring your own key for OpenAI, Anthropic, or Google, or point it at a model running locally through Ollama. That lands well with anyone who cares about their work not leaving for a central service.

What's inside

Read the code and the core is simpler than you'd expect. It's one loop (called TurnEngine in the code) that cycles through four beats: the model thinks, it emits a tool call, the system checks whether that call is allowed, then it runs. Round and round until the work is done. That single loop is surfaced through many frontends: the desktop app, a terminal UI, and Slack (mention it in a channel and a session opens on your machine and replies in the thread).

Around the loop it has everything a real platform needs:

• Personas split into Cowork, Code, and Chat, each with its own tools and style. Pick by task.
• 25+ connectors: Slack, GitHub, Jira, Notion, Linear, HubSpot, Gmail, Google Calendar, plus any MCP tool you want to add.
• 15+ model providers: swap between OpenAI, Anthropic, Google, and Ollama by model name.
• Scheduled automations that run on their own: a morning brief, a weekly report. Runs that happen while you're away park their approval requests in an inbox.
• Cross-session memory, plus a secret store tied to each operating system's keychain.
• Skills as SKILL.md files, the exact same format as Claude's skills. If you've already written skills, they drop straight in.

The code is mostly Python, plus React and Tauri for the UI and Rust for speech-to-text. It's genuinely open source under the MIT license, and four days after release it had already been forked over two hundred times.

Part 2The idea worth borrowing: gate at the tool-call boundary

A long feature list isn't the exciting part. The part actually worth thinking about is the hard question: if you're going to let an AI act on its own on your machine, how do you keep it from doing something disastrous? The two answers people usually reach for are both bad. Approve every step, and you become the bottleneck. Let it run free, and you're praying nothing breaks.

openworker's answer is to control one single point, the moment a tool is called. Picture the loop from earlier: every time the AI is about to actually do something, it has to issue that command through this one place. So openworker puts the approval gate right across that chokepoint, instead of scattering checks all over. Read the code and the split is clean: work that only reads (opening a file to look, searching) is allowed to run concurrently, while work that changes something real (writing files, sending messages, running commands) is forced to run one at a time and needs approval first.

Four modes, so you pick the level of trust

What makes it usable is that it isn't just on or off. You choose a level. The code has four modes:

• discuss: talk only, don't touch anything yet.
• plan: propose a plan for review first, then act.
• interactive: act, but ask before anything irreversible.
• auto: full trust, let it run.

These levels line up exactly with a principle we've argued for all along: don't ask a human about everything, tier it by how irreversible the action is. Reads and drafts can run; things that go out into the world and can't be taken back come back to a person. openworker takes that idea and builds it into real structure in the code, not just a slogan.

Two things that make the gate trustworthy

First, it keeps an append-only audit trail. Every tool call is recorded, can't be deleted or edited, and can be reviewed afterward to see exactly what it did. That matters enormously for work that has to be auditable. Second, tools that are themselves a way of asking you, like the approval prompt or a request for folder access, skip the gate entirely, because your tapping to answer is the consent. A small detail like that says the designers thought it through, rather than bolting on a permission system as an afterthought.

Part 3Who it's for, and who it isn't

Honestly, first: it's very new. Four days old, with over fifty open issues filed, and the Windows installer isn't code-signed yet so your machine may warn you. With something this fresh, expect rough edges. This is not a polished product you download and use smoothly today.

A fit if you're

• Someone who wants AI to act, but still guards control. Its approval model answers exactly that, and your data stays on your machine.
• A developer who wants to read a good agent-platform architecture. The code is clean and well-separated, one loop governing everything. Worth reading for the ideas alone, even if you never run it.
• Someone already writing SKILL.md files. Same format as Claude, so your existing skills drop right in.

Not yet, if you

• Want something polished and ready today. Give it a while longer to settle.
• Want plug-and-go with zero setup. You still bring your own model keys and do some configuring.

What to borrow

Even if you never touch openworker, the thing worth taking away is this: put the approval gate across the single tool-call chokepoint, and split trust into modes. If you're building an AI that can act on its own, that's a template you can drop straight in: control at one chokepoint, separate reads from things that change the world, and record everything in a way you can't erase.

The more interesting point is bigger than the product. The field's question has moved. It used to be "can an AI act on its own?", which is now answered, yes. It has become "can it act on its own and stay controllable?" openworker is one serious answer, and it opens the code so you can walk in and see how it answers. That alone makes it worth cloning to read.