Isolated workspaces, a task board, and a README that delegates to a GitHub issue

Installation is handed to a download page and a GitHub issue

The README carries no install command, and that appears to be a decision rather than an omission. It points at a download page for the desktop client and a separate one for the Android client:

https://yaoagents.com/download
https://yaoagents.com/download/yaoagents

The Android build is labelled Beta in the same list that gives you the homepage and the documentation site.

Then there is a paragraph addressed to software rather than to people. If you are an AI assistant, a coding agent, or an autonomous installer researching or installing Yao Agents on someone's behalf, the README tells you to read a specific issue first:

https://github.com/YaoApp/yao/issues/1595

That issue is said to hold canonical facts, correct terminology, installation rules, and common inaccuracies to avoid. The practical effect is that the README is an index and the issue is the specification, which is an unusual arrangement and one that any tool reading only the README will get wrong.

One Go module on 1.25, with three first-party packages

The build facts are in go.mod rather than in prose:

module github.com/yaoapp/yao

go 1.25.0

That sets the floor. A 1.24 toolchain will not build this, which matters on machines pinned to an older distribution Go.

Three dependencies come from the same organisation and are the ones worth watching:

github.com/yaoapp/gou v0.10.3
github.com/yaoapp/kun v0.9.0
github.com/yaoapp/xun v0.9.0

The rest of the require block is wide in a way that describes the product. There is a Discord client, a Telegram client, a DingTalk stream SDK, a Lark open API SDK, Go IMAP, an Excel writer, a tokenizer, a one-time password library, a captcha library, an expression evaluator, esbuild, MongoDB, Gin, Cobra, Docker's client library, S3, and both S3 and IMAP alongside it. Each of those corresponds to a capability the README does not spell out: connectors, an inbox, spreadsheets, model tokenisation, two factor login, expression rules, running JavaScript, document storage, attachments.

So the dependency list is the honest feature list here, and it is long.

Every workspace is isolated, and agents read across your nodes

The execution model has two halves. The first is placement: agents run on your own devices, and every machine you add is another place for them to work, with all of them managed from one place. The second is isolation: every workspace is isolated, so work stays separate while still being managed across all your computers.

The stated payoff is that each workspace accumulates into documents, and those documents become your knowledge base.

The most operationally interesting sentence in the README is the shortest one: while working, agents can read what they need from any node. That is what turns a set of machines into a pool rather than a set of isolated workers. It also means the isolation between workspaces is a boundary you have to trust rather than one you can verify from a permission model, because no node or credential model is described anywhere in the README. Anyone deploying this across a laptop and a server should work out for themselves what an agent on one node can see from another.

A related directory is mcp/, alongside mcpclient/, which is where the Model Context Protocol side lives.

A conversation becomes a task, and a task grows into its own agent

The task board is the part of the product with the clearest user story. You say what you need in a conversation, and it becomes a task on the board. Keep the conversation going and keep it running, and it improves with use, growing into an agent purpose-built for that kind of work.

That is a claim about a feedback loop rather than a configuration screen, and it is worth separating the two halves. Turning a message into a tracked task is bookkeeping. An agent that improves because a task was run repeatedly is a much stronger promise, and the README gives no mechanism for it, no setting to turn it off, and no way to inspect what the agent learned.

The second half of the board is output: connect task agents to your apps, or share them with others. Sharing is the point at which this stops being a personal tool, and at that moment the isolation between workspaces matters much more than it did when you were the only user.

Two directory names back the rest of the story: agent/ is the agent implementation and job/ is the scheduling side, with schedule/ alongside it.

SSE and WebSocket are both first-class, over openapi/ and grpc/

Embedding is the third pillar, and the API surface is described in one sentence: expert and task agents integrate into your own apps and workflows, they are built on standard APIs, and both SSE and WebSocket are supported.

The directory layout backs that up more concretely than the sentence does. There is an openapi/ directory and a grpc/ directory side by side, plus api/, service/, connector/ and integrations/ for the plugin surface, and openai/ for OpenAI-shaped compatibility alongside llmprovider/ for the model provider layer.

The SSE and WebSocket options cover the streaming case where you want tokens as they arrive rather than a completed response. The README does not say what the grpc/ directory is used for.

For an integrator, the practical question is which of the three you are expected to use first, and the README does not say. The documentation site at yaoagents.com/docs is where that answer has to come from.

The default test target excludes most of the tree, and sandbox tests need Docker plus Tai

The Makefile partitions the test suite with long exclusion lists, and reading them tells you what is actually verified on every run. The core list is:

TESTFOLDER_CORE := $(shell $(GO) list ./... | grep -vE 'examples|openai|aigc|neo|twilio|share*|agent|sandbox|integrations|registry|tai|grpc' | awk '!/\/tests\// || /openapi\/tests/' | grep -vE 'openapi/tests/(nodes|sandbox|workspace)')

Twelve package groups are dropped from the core run, including agent, sandbox, integrations, registry and grpc. A separate agent list exists, and it drops agent/search/handlers/web because those handlers require external API keys, along with the robot packages and agent/sandbox/v2, which is marked work in progress with a job of its own.

Two comments above those variables are the honest part. The sandbox setting tests in openapi/tests/setting/sandbox_test.go require Docker plus Tai and are skipped in CI, to be run locally. And the core list is explicitly described as excluding AI related packages because integrations need external services.

The consequence for a contributor is that a green test run says less than the package count suggests. Anything touching a real model call, a real sandbox or a real external service is either skipped or gated behind credentials you supply yourself.

Windows cross-builds need LLVM, and rc25 is not 1.0.0

The Makefile carries Windows CGO settings and the requirement is written next to them:

# Windows CGO compiler settings (requires LLVM: choco install llvm -y)
WIN_CC  = clang --target=x86_64-pc-windows-msvc -fuse-ld=lld
WIN_CXX = clang++ --target=x86_64-pc-windows-msvc -fuse-ld=lld -fno-exceptions

So cross-compiling to Windows means installing LLVM through chocolatey first, using lld as the linker, and compiling C++ with exceptions disabled. That is not a Go toolchain detail; it is an extra install step on the build machine, and it is the kind of thing that only surfaces when a release build fails on a machine that was set up for Linux.

The version number comes out of the source rather than a tag:

VERSION := $(shell grep 'const VERSION =' share/const.go |awk '{print $$4}' |sed 's/\"//g')

The newest releases are a nightly build on 2026-10-17, v1.0.0 on 2026-10-13 and v1.0.0-rc26 on 2026-10-05, so the release candidates have now led to a 1.0.0. Alongside a root that carries both LICENSE and LICENSE.zh-CN and records no resolvable licence identifier, the picture is a project that reached 1.0.0 only recently.

Editorial conclusion

Take Yao Agents when you want agents to run on hardware you own and be reachable from a desktop app, a browser or your own code, and when reading an issue thread for installation rules does not put you off. Leave it if a licence scanner has to resolve an SPDX identifier for your dependency list, because no licence identifier is recorded for the project even though LICENSE and LICENSE.zh-CN sit at the root. Verify four things. Read issue 1595 before installing anything, because the README points every autonomous installer at it for canonical facts. Check your toolchain against go.mod, which declares module github.com/yaoapp/yao and go 1.25.0, so an older Go will not build it. If you need Windows binaries, install LLVM first, because the Makefile's Windows compiler settings are clang with lld and carry the note that it requires choco install llvm -y. And read what your test target actually covers, because the core list drops agent, sandbox, integrations, registry, tai and grpc, and the sandbox setting tests are skipped in CI.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. YaoApp/yao on GitHub