Kimi Work Can Run 300 Agents. I Want the Receipts.

Kimi Work launched in beta on June 3, 2026 with a wide job description. Kimi says the desktop app can mount local folders, operate a browser through WebBridge, run Python or shell tasks, schedule work, and coordinate up to 300 sub-agents. It is available for Apple silicon Macs running macOS 12 or later and Windows PCs running Windows 10 or later.

I understand the appeal. A useful desktop agent should be able to find the quarterly PDFs, clean the spreadsheet, research the missing context, and leave a finished deck in the right folder. But once that agent can keep the computer awake and work overnight, intelligence stops being the only product question. I want to know exactly what it touched.

Quick answer

What Kimi Work promises	What I would check before relying on it
Local file access	Folder scope, version history, and a recoverable record of every write
Scheduled Python and shell tasks	Run history, environment boundaries, failure alerts, and a reliable stop control
Browser automation	Credential boundaries and a trace of pages visited and actions taken
Up to 300 sub-agents	Ownership of each subtask, collision handling, and clear incomplete-work flags

Kimi is selling a worker, not another chat tab

The product page calls Kimi Work a "system-level digital employee." That phrase is marketing, but it also describes the change accurately. Kimi's web app waits for a prompt. Kimi Work can connect a prompt to files, a browser, code execution, recurring schedules, and finished office documents on the same machine.

Kimi's help center overview makes the ambition more concrete. Work mode can create and organize folders, call tools, use uploaded skills and optional plugins, and switch between a single agent and Agent Swarm. Kimi also advertises long-running work of up to 13 hours and more than 4,000 autonomous tool calls. Those figures describe capability claimed by Kimi, not an independent reliability result.

If this works consistently, the obvious beneficiaries are people whose jobs already span messy files and browser tabs: analysts reconciling reports, researchers working through papers, operators assembling recurring reviews, and consultants turning source material into decks. The value is carrying one task across applications without making the user supervise every click.

Permission is not an audit trail

Kimi says its "Ask before acting" safeguard requests authorization before the agent modifies or overwrites local files or runs code. The help center also documents a second setting, "Allow all," which lets the agent act without asking. Both modes make sense. Constant prompts defeat the point of scheduled work, while unrestricted execution is a serious amount of trust to hand a beta product.

I still need to know what happened after the permission decision. A prompt can tell me that an agent wants to edit a file. It cannot tell me whether ten sub-agents later worked from the same stale copy, whether a browser step submitted a form, or whether an incomplete research branch quietly flowed into the final deck. An audit trail should answer those questions without making me reconstruct the run from scattered outputs.

The skeptical case is about operations

Public commenters focused on ordinary operational questions. In a Reddit thread about Kimi Work, they asked whether Python runs are sandboxed, whether scheduled jobs produce inspectable logs, and how a swarm handles shared file locks. One commenter put the adoption test plainly: the feature that decides whether people leave the agent running is the audit trail.

An independent TechRadar review of the broader Kimi platform reached a related concern during one Agent Swarm research task. The reviewer said a few subtasks returned incomplete results without flagging that clearly, so the output needed manual verification. That is one review, not a benchmark, and it was not a dedicated Kimi Work test. Still, the failure mode is relevant. Parallel work becomes harder to trust when partial failure looks like completion.

What I would want in the morning

My minimum record would show the task plan, every tool invocation, files read and written, browser actions, permissions granted, sub-agent ownership, failures, retries, and the final path from source to deliverable. File changes should be diffable and reversible. Scheduled runs should have spending and runtime limits. A collision should stop the affected branch instead of letting the last writer win.

I would also separate approval from review. "Allow this folder" is a scope decision made before work begins. "Accept these changes" is a quality decision made after the evidence is visible. A strong desktop agent needs both. Otherwise the user chooses between interrupting automation with prompts and trusting a black box for hours.

My take

Kimi Work is pointed at the right problem. Knowledge work rarely lives in one prompt, and a desktop agent can remove the awkward handoffs between chat, folders, browsers, scripts, spreadsheets, and slides. The scheduled-work feature interests me more than the 300-agent headline because it changes when supervision happens.

That is why I would judge Kimi Work by the receipts. A swarm can finish a difficult task and still leave me unsure about one weak branch or a bad file change. I would trust it when I can inspect the run, undo the mistake, and see why the final file deserves approval. For an agent that wants the keys to the desktop overnight, the log is part of the product.