Local AI workbench
A local AI assistant that runs tasks, remembers, and automates — with one gateway for every model.
GoWork is a local-first AI workbench built around a resident assistant: an LLM-driven agent that understands a task and works through it step by step with real tools — reading and writing files, running commands, searching the web, generating images — or delegates the coding to Codex and Claude Code. It keeps long-term memory, runs scheduled jobs, and reaches you over IM. Underneath sits a unified model gateway that fronts your coding CLIs and API clients.
Positioning
For developers and small teams who want a private, always-on AI assistant that actually does the work — not just chats — with a single, controllable gateway in front of every model and coding CLI they already use.
Capabilities
GoWork
01
Runs a resident ReAct assistant: it reasons, calls tools, reads the results, and keeps going until the task is done — or until it needs your confirmation.
02
Acts directly on your machine: read and write files, run shell commands, search and fetch the web, generate images, and read PDF/Office documents — all inside a guarded workspace.
03
Delegates the coding to runtimes: hand a task to Codex or Claude Code, then stream, continue, or cancel the run.
04
Remembers across sessions: four-scope long-term memory — you, project, conversation, and run — that you can promote into reusable Skills.
05
Schedules and automates: declarative once / daily / weekly / monthly tasks that either remind you or wake the assistant to act.
06
Reaches you anywhere: DingTalk, Feishu, and Telegram (WeChat is experimental), pushing back text and images.
07
Stays safe and local: a default-deny tool policy with approval governance, plus one model gateway with account pooling and usage tracking — credentials and records stay in ~/.gowork.
Built for specific operators
AI-first developersCoding-agent power usersSmall teams and studiosAutomation and ops builders
Product
Supported surfaces and platforms
Model providers
Channels
Assistant capabilities
Related reading
GoWork — Getting started
Install GoWork, connect your models and coding CLIs, and put its resident assistant to work.
Core concepts
How GoWork works — a resident assistant on top of a local model gateway, everything running on your own machine.
Assistant capabilities
What GoWork's resident assistant can do — run tasks, use tools, remember, automate, delegate, and reach you over IM.
Model gateway
One local endpoint that fronts your models and coding CLIs — with account pooling, key management, model mapping, and usage tracking.
Channels
Reach the GoWork assistant over IM — DingTalk, Feishu, Telegram (WeChat experimental) — and keep tasks running from your phone.
Reference
Where GoWork stores data, the local port, account commands, and environment variables.
AI assistants vs chatbots: the execution gap
The real difference between an AI assistant and a chatbot is not tone or fluency. It is whether the system can keep task state, use tools, survive interruptions, and actually finish work. This article explains that execution gap through the lens of GoWork.
ReadWhy a refresh button matters in skill discovery for GoWork
A refresh button in GoWork’s skill list is not cosmetic. It turns “wait for cache expiry” into a deliberate request to rebuild discovery now, which makes newly added skills easier to validate, debug, and trust.
ReadWhy timeout propagation must reach the lowest executor
A timeout that stops only the assistant layer is not enough. Commands, child processes, and desktop actions may keep running underneath. Here's why execution-oriented AI assistants need deadline propagation and graceful shutdown instead of blind kill-first behavior.
ReadWhy runtime status is not the same as a chat summary
Task status cannot be inferred from a conversation summary alone. Reliable progress reporting needs runtime state, recent events, waiting reasons, and real execution evidence. This article explains the difference.
ReadWhen structured clarification forms beat a simple chat question
Learn when GoWork should use a structured clarification form to collect multiple concrete fields, and when a single natural-language follow-up is the better choice for execution-oriented AI assistants.
ReadWhy long tasks need continuation rounds
Learn why GoWork pairs assistant continuation rounds with handoff summaries: when to declare continuation, what a usable handoff must contain, and why this is more reliable than merely saying “I will continue next round.”
ReadWhy assistant systems need a global concurrency gate
Parallel tasks do not mean every action should run at once. This article explains why execution-oriented AI assistants need a global concurrency gate to separate safe parallel work, exclusive resources, course corrections, and read-only status requests.
ReadWhen to parallelize read-only tools and serialize long tasks
Read-only tools are often safest in parallel, while desktop actions, state-changing edits, and dependency-heavy execution chains should stay serial. This article explains the real boundary between tool parallelism and long-task serialization in GoWork.
ReadWhy a newly added skill may stay invisible until cache refresh in GoWork
If a new GoWork skill exists on disk but does not appear in the UI, the problem is often discovery cache, refresh timing, or directory traversal semantics rather than the skill itself. Here is how cache TTL, manual refresh, and full rescan fit together.
ReadWhat to do when the desktop is busy: resource holders and queues
When another task already owns the desktop, GoWork should not cancel parallel work by default. This article explains how resource holders, desktop queues, and concurrent orchestration fit together, and why waiting in line is safer than grabbing the mouse.
ReadStatus questions and stop commands are not the same
When a user asks where a task stands, an AI assistant should answer from read-only run state. When the user says stop, it should actually cancel the running task. Treating both as the same kind of message creates duplicate work and false control.
ReadWhy assistants should explain intent before tool actions
A one-line intent note before a tool call makes an AI assistant more auditable, easier to correct, and far more trustworthy. This article explains why pre-action intent matters and how to write it without turning chat into noise.
ReadWhy long-running AI tasks need progress heartbeats
When an AI assistant runs a long multi-step task in silence, users stop trusting it. This post explains why periodic progress heartbeats matter, what they should contain, and how to send them without spamming.
ReadWhy “I’ll do it next” is not task completion
AI assistants often present the next planned action as if the task were already done. This article explains the boundary between assistant_done and continuation, and why GoWork treats future intent very differently from finished work.
ReadWhy historical screenshots should use view_image first
When a user asks about an earlier screenshot, you should inspect that historical evidence with view_image before taking a fresh screenshot; this matters for GoWork task continuity, desktop forensics, and reliable troubleshooting.
ReadWhy agents should transcribe key text from screenshots immediately
In desktop automation, a screenshot is only a momentary observation. If an agent does not turn the key text into reusable notes right away, the next turn may lose the exact facts that should drive the workflow.
ReadRecall before clarification: when assistants should remember before they ask
When an AI assistant seems to be missing information, the safest default is not to question the user immediately. This article explains when GoWork should recall memory and history first, and when clarification is truly necessary.
ReadWhy multi-step tasks need plans that persist across runs
The hardest part of long AI tasks is not making a plan once. It is keeping that plan alive across continuation, retries, and verification. This article explains why GoWork treats update_plan as persistent task state, not temporary narration.
ReadWhy assistants should check run archives before probing live systems
When a user asks what happened last time, the safest move is usually to inspect the run archive first, not to probe the live system again. This article explains why execution archives answer historical questions better, and how GoWork turns that into a practical workflow.
ReadRuntime approvals vs assistant confirmation vs auto-approve
A practical explanation of how GoWork separates runtime approvals, assistant confirmations, and auto-approve: one governs execution-layer permission, one guards high-impact semantic boundaries, and one removes low-value prompts for routine steps.
ReadWhy a status question should not retrigger the task
When a user only asks where a task stands, the safest response is to read the current run summary and recent events instead of rerunning the workflow. Here is why that boundary matters.
ReadDesktop task queues are not the opposite of parallelism
Seeing desktop tasks queue up in GoWork does not mean the whole system is serial. Only the exclusive desktop resource must be serialized; status reads, file work, web research, and many background commands can still run in parallel.
ReadDelegate or Execute Locally? GoWork's Boundary
Task delegation and local execution are not the same thing. This article explains when GoWork should hand work to a runtime, when the local assistant should finish it directly, and why that boundary affects speed and reliability.
ReadWhen to use structured clarification forms in Web chat
Learn when GoWork should switch from natural-language follow-up questions to structured clarification forms in Web chat, and why form-based prompting only works when the missing information is truly field-like.
ReadWhy reminder lists are global by default in GoWork
Learn why GoWork usually answers reminder-list questions with a global scope, when current conversation is the right filter, and why query scope should not be confused with notification delivery.
ReadInterval monitors vs daily reminders in GoWork
Learn when GoWork interval tasks should watch for changing conditions and when daily schedules should land on fixed clock times, so “every N hours” does not turn into drifting reminders or fake monitoring.
ReadWhy conditional scheduled tasks should cancel themselves
In GoWork, monitoring-style scheduled tasks should cancel themselves once the condition is met. Otherwise they keep polling, waste runs, and turn a one-shot watcher into recurring noise.
ReadWhat to do when your AI assistant remembers wrong
The hard problem with AI memory is not storing more facts. It is handling stale or incorrect memory safely. This article explains why execution assistants need recall checks, evidence, user correction paths, and real memory updates.
ReadWhy agent systems should separate the brain from the hands
Agent architecture gets fragile when one loop must both reason and execute. This article explains why separating the assistant brain from deterministic hands improves reliability, auditability, and task completion.
ReadHow scheduled tasks should report results back
Learn how GoWork scheduled tasks should report results after a run: when a one-line reminder is enough, when to send a conclusion with key observations, when to use a structured run report, and when silence is the better default.
ReadAuto-approve does not mean unlimited authority
GoWork's auto-approve mode removes low-value confirmation prompts for routine execution, but it does not erase boundaries. Deleting data, formal publishing, external messaging, and form submission still require explicit authorization or a clear in-run preauthorization.
ReadWhere do GoWork scheduled-task notifications go?
In GoWork, a scheduled task is not the same thing as a notification target. Whether a result returns to the current conversation, appears in a global reminder list, or stays silent in the background depends on notify targets, query scope, and task type.
ReadWhy ops teams need assistants with memory, not just bots
In ops work, an AI that only replies in the moment quickly breaks down during handoffs, follow-ups, retries, and scheduled checks. What teams actually need is an assistant with memory, task history, and replayable execution context.
ReadScheduled publishing vs interval tasks for content ops
Learn when to use scheduled publishing and when to use interval tasks: one is for known publish times, the other is for repeated checks and condition-based follow-up in content operations.
ReadSchedule a full content pipeline with GoWork
If your content work still depends on people remembering to write, publish, submit for indexing, and cross-post, the weak point is not writing quality but execution continuity. This article explains how GoWork can run a timed content pipeline from topic pickup to website publishing and distribution.
ReadChat context vs runtime context for AI assistants
Chat context tells an AI assistant who is speaking, in which conversation, and through which channel. Runtime context tells it which task, run state, verified facts, and execution constraints apply right now. This article explains why execution systems need both layers and why treating them as the same thing causes errors.
ReadResume AI tasks after failure instead of restarting
When an AI task fails, the efficient move is not to restart everything. It is to continue from the last verified checkpoint using task state, run history, and concrete evidence. This article explains why post-failure continuation is a core capability for execution-oriented AI assistants, and how GoWork is designed around it.
ReadWhy AI assistants should answer task status in chat
When users ask “where is that task now?”, they do not want vague reassurance. They need a factual progress answer grounded in real task state, recent execution history, and the next blocking point. This article explains why in-chat task status is a core capability for collaborative AI assistants.
ReadWhy AI assistants need memory and task history
An AI that only answers the current prompt quickly breaks down in real operations. To support follow-ups, continuation, retries, and retrospection, an assistant needs memory, task history, and replayable execution records — which is exactly why systems like GoWork are built that way.
ReadApproval bots vs execution assistants
Approval bots are useful when work is mostly about routing a yes-or-no decision, but once a task needs context, real execution, retries, and results returned to the same chat, teams usually need an execution assistant such as GoWork instead.
ReadScheduled follow-ups in DingTalk with GoWork
If you want AI in DingTalk to do more than send reminders, you need scheduled tasks that can check status, follow up automatically, and return results to the same chat. This article explains that workflow with GoWork.
ReadHow to connect GoWork's assistant to Feishu
Connecting AI to Feishu is not only about replying in chat. The real value is keeping conversation context, running tasks, scheduling follow-ups, and returning results to the same thread. This article explains that workflow with GoWork.
ReadHow to connect GoWork's assistant to Telegram
Connecting AI to Telegram is not only about replying in chat. The real value is keeping conversation context, running tasks, scheduling follow-ups, and returning results to the same thread. This article explains that workflow with GoWork.
ReadTelegram bots vs resident AI assistants
Many teams start with a Telegram bot when they want AI in chat. But once the job needs context, tool use, scheduled follow-ups, and proactive delivery, what they really need is a resident AI assistant like GoWork.
ReadDingTalk bots vs resident AI assistants
Many teams start with a DingTalk bot when they want AI in chat. But once the job requires context, tools, scheduling, and proactive delivery, what they really need is a resident AI assistant.
ReadScheduled ops workflows with GoWork
Reminders are the easy part. Real operational scheduling means checking status, summarizing results, and following up automatically. This article explains how GoWork turns scheduled tasks into an execution layer for ops teams.
ReadA resident AI assistant on DingTalk, Feishu, and Telegram
Connecting AI to DingTalk, Feishu, or Telegram is not just about replying in chat. The real value is keeping context, running tasks, scheduling follow-ups, and sending results back. This is where GoWork's assistant fits.
ReadWhy teams need one model proxy instead of per-CLI API keys
Once Claude Code, Codex, and compatible clients multiply across a team, the real problem is not model quality. It is scattered keys, model names, routes, and quota handling. This article explains why teams need one model proxy first.
ReadOne localhost endpoint for all your coding CLIs
Learn how GoWork's model proxy gives Claude Code, Codex, and other coding CLIs one localhost endpoint with account pooling, key management, model mapping, and usage tracking.
ReadMeet GoWork's assistant: a local AI that does the work, not just the talk
GoWork's resident assistant runs real tasks on your own machine — using tools, remembering, automating, and delegating to Codex and Claude Code. It is more than a chatbot.
Read