Yao Agents: a self-hosted task board for agents that run on your own machines
✨ All your agents and workspaces in one place, on every device you own. Track tasks on a board, accessible from desktop, mobile, browser, or API. Self-hosted.
At a glance
- What is it?
- Yao Agents puts a shared task board in front of agents that execute on hardware you control, with desktop, Android, browser and API entry points. The README is thin on internals, so the honest picture is a usable shell around a still-moving core.
- Who is it for?
- Adopt Yao Agents if you already run agents on more than one machine and want a single board and API in front of them, and if you can read the docs at yaoagents.com/docs before committing. Do not adopt it if you need a stable release line: the newest tag is v1.0.0-rc21, a release candidate, and the repository's license field is NOASSERTION, so the actual terms have to be confirmed in the LICENSE file rather than assumed from the GitHub label.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 5 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Yao Agents targets: agents scattered across machines
Most agent tooling assumes one host. You install a CLI or a desktop app, point it at a model, and the work lives there. Add a second laptop, a home server, or a phone, and the state fragments. Conversations sit in one place, generated documents in another, and there is no shared view of what is queued, running, or done. Yao Agents is aimed at that split. The README's framing is explicit: "Agents run on your own devices. Every machine you add is another place for them to work, all managed from one place." The intended user is someone with more than one machine who wants agents to keep working across all of them and still see a single board. The self-hosted label and the own-your-data topic suggest the audience also cares about not shipping conversation history to a vendor. That combination, multi-device plus self-hosted, is narrower than the general agent-tooling market, and the product is shaped around it.
What the README actually specifies about the architecture
This is where the material runs out, and it is worth being blunt about it. The README gives four concepts and almost no mechanism. Workspaces are described as isolated, with work staying separate, managed across computers, and accumulating into documents that become a knowledge base. Agents can read from any node while working. A task board turns a conversation into a task. An open API exposes expert and task agents with both SSE and WebSocket support. What is not stated: what a node is in concrete terms, how nodes discover each other, whether there is a coordinator process, how authentication between devices works, or where the documents are stored. The repository layout and the Go language suggest a compiled server binary plus clients, and the DeepSeek Harness integration is mentioned as running in the desktop app, Android, and browser. Beyond that, the architecture diagram at docs/how-it-works.png carries the load, and I have not viewed it. Anyone evaluating this should treat the diagram and the docs site as the primary source, not the README, which is closer to a product statement than a technical one. The README itself notes it was written with DeepSeek Harness in the Android app and published automatically, which explains the promotional register but not the missing detail.
Getting it running: what the README gives you
The install surface in the supplied material is distribution links, not build instructions. For desktop there is a download page at https://yaoagents.com/download. For Android there is a direct APK at https://get.yaoapps.com/yaoagents/cui-android/0.6.37/cui-android-0.6.37.apk, labeled beta. Browser access is implied by the homepage and the API section. There is no docker run command, no go install line, no compose file, and no configuration key documented in the README. That is a real gap for a self-hosted tool, because self-hosting normally means the operator needs to know which port to open, where data is written, and how to back it up. None of that is in the material I have. The API is the one integration point with named transport: SSE and WebSocket. If you are wiring Yao Agents into an existing workflow, those two are what you would build against, and you would need the docs site to get endpoint paths and payload shapes. Note also the version skew: the Android APK is at 0.6.37 while the repository tags are at v1.0.0-rc21. Those are different version lines, and the README does not explain how they relate, so do not assume the APK matches the server you build from main.
The release cadence is the clearest signal about maturity
Three release candidates shipped in five days: v1.0.0-rc19 on 2026-09-05, rc20 on 2026-09-09, and rc21 on 2026-09-10. The last push to main was 2026-09-10. That is an active, fast-moving project that has not yet cut a stable 1.0.0. For an operator, the practical consequence is upgrade churn. If you self-host and pin to a release candidate, you should expect to move between rc tags, and the README offers no migration notes, no schema versioning, and no statement about whether workspace data survives an upgrade. That is the single largest operational unknown in this material. A task board that accumulates documents into a knowledge base is holding state you care about, and nothing in the README describes a backup or export path. Before putting real work into it, the thing to establish is where that state lives on disk and whether it is portable between versions. I cannot answer that from the supplied material.
Where Yao Agents is the wrong tool
If you run agents on a single machine and only from a terminal, the multi-device premise buys you nothing and the board becomes an extra surface to maintain. If you need a stable, versioned platform with a published support window, the rc-only release line is disqualifying today. If your organization requires a clear license before procurement, the NOASSERTION field is a blocker: GitHub uses that label when it cannot identify a standard license, and it means the terms have to be read from the repository's own license file rather than inferred. A permissive license, a source-available one, and a custom one all land under NOASSERTION, and they imply very different things about redistribution and commercial use. I am not giving legal advice, and I am not going to guess which it is. There is also a fit question around the no-code and no-code-adjacent topics: the task board is conversational, so a team that wants agents defined as version-controlled configuration files may find the board abstraction in the way rather than helpful.
How this differs from running a coding agent directly
The obvious comparison is a terminal coding agent such as Claude Code, which the repository's own topics list alongside this project. The difference in approach is where state lives and what coordinates it. A terminal agent is scoped to one working directory on one machine; its session history is local, and coordination across machines is something you build yourself with git, ssh, or a shared filesystem. Yao Agents inverts that: the board is the coordination layer, workspaces are the isolation boundary, and the devices are execution sites. The README's own example of the distinction is that a conversation becomes a task on the board and, over time, grows into an agent purpose-built for that kind of work. That is a different unit of work. A terminal agent runs a prompt; Yao Agents accumulates a task agent. Whether that accumulation is genuinely useful or just a longer conversation thread is not something the README demonstrates. The API claim, standard APIs with SSE and WebSocket, is the part that would let this sit behind an existing product rather than replace your terminal workflow, and that is the integration story worth testing.
Licence and maintenance cost, stated as unknowns
Two costs are visible without running anything. The first is upgrade cost, driven by the rc cadence described above: frequent tags plus no documented migration path means each upgrade is a manual check. The second is the licence. NOASSERTION is not a licence; it is the absence of a recognized one in the repository metadata. For a self-hosted tool where you are running the code on your own infrastructure, that matters less than for redistribution, but it still matters if you embed the API into a commercial product or ship the Android APK internally. The concrete next step is to open the LICENSE file in the repository and read it, and if there is no LICENSE file, treat the default all-rights-reserved position as the starting assumption until the maintainers state otherwise. I am not a lawyer and this is not legal advice; the point is only that the metadata does not answer the question, so the file has to.
Editorial conclusion
Adopt Yao Agents if you already run agents on more than one machine and want a single board and API in front of them, and if you can read the docs at yaoagents.com/docs before committing. Do not adopt it if you need a stable release line: the newest tag is v1.0.0-rc21, a release candidate, and the repository's license field is NOASSERTION, so the actual terms have to be confirmed in the LICENSE file rather than assumed from the GitHub label. Verify the agent execution model first, specifically whether agents run as local processes on each node or through a central service, because the README's phrase about agents running on your own devices is the only description of it.
Community notes