If you want AI agents that run on your own machines and stay under your control, Yao Agents is worth evaluating. It fits teams comfortable running pre-1.0 software that they can maintain. Treat this as an evaluation review, not a green light: verify the license, check the open authorization issue before multi-user access, and start from the rc18 release instead of the rc17 snapshot reviewed here.

This is a source and documentation review based on repository metadata, the README, the v1.0.0-rc17 and v1.0.0-rc18 release notes, and open issues collected on September 5, 2026. No local installation, runtime test, benchmark, or production deployment was performed for this review, and claims from the repository or issue reports are attributed to their authors.

Key facts about Yao Agents

What Yao Agents actually is

Yao Agents is the project behind the YaoApp/yao repository: a self-hosted platform written in Go that its maintainers describe as putting all agents and workspaces in one place, with task tracking on a board and access from desktop, mobile, browser, or API. The README explains that agents run on devices you add, each workspace is isolated, and work accumulates into documents that become a knowledge base agents can read from any node.

The problem it targets is operational: once an AI agent does real work, someone has to manage where it runs, what it can access, and how other software calls it. Yao positions itself as that management layer, with an open API offering SSE and WebSocket support and task agents that can connect to your applications or be shared. The maintainers also announce DeepSeek Harness integration across desktop, Android (beta), and browser. In an open issue, a contributor describes Yao as having native MCP support and TypeScript Create/Next hooks; that framing belongs to the issue author. The repository topic list includes mcp, agent-harness, agent-orchestration, local-first, and own-your-data.

What the rc17 and rc18 releases change

The reviewed release, v1.0.0-rc17 published August 22, 2026, contains one merged change according to its notes: an enhancement of DeepSeek V4 configurations and streamlined vision message handling. A newer release, v1.0.0-rc18 published September 3, 2026, adds BuildScript improvements for large payloads and resource handling, loading-message handling and compaction updates with tests, and Baidu OCR support with configuration management.

The cadence matters more than the individual changes: release candidates rc14 through rc18 were published between August 18 and September 3, 2026. That is evidence of active maintenance, but also of a pre-1.0 surface that changes every few days. Adopting Yao means reviewing each release, pinning versions, and rerunning regression tests, because no release candidate observed here is a stable baseline you can ignore.

Who should evaluate Yao Agents

Evaluate Yao Agents if your decision is where to run internal AI agents while keeping their data under your control. That is the scenario the maintainers design for: a self-hosted platform with isolated workspaces, device-based execution, and an API for integrating agents into your own tools. The repository’s own topics point at coding-agent and harness workflows, including Claude Code and DeepSeek, so the practical fit is a developer-led team that already uses agent harnesses and wants a shared board plus API layer across machines.

A solo founder or small operations team can pilot it. The main condition is that someone must own the machines, upgrades, and recovery, because self-hosted agent work is infrastructure, not an app you install once.

Maintenance signals in the evidence

• Active and automated releases: rc14 through rc18 (August 18 to September 3, 2026) were published with dev and production binaries for Windows (amd64), Linux, and macOS on amd64 and arm64, plus sha256 checksums.
• Narrow authorship visible in this snapshot: every release note from rc14 through rc18 credits the same developer, with a GitHub Actions bot publishing artifacts. Release automation looks healthy; a broader contributor or review base is not demonstrated by this data.
• Documented dogfooding: the README states that it was written with DeepSeek Harness in the Yao Agents Android app (beta) and published automatically. That is a maintainer claim, not independent evidence of reliability.

What to check before production

Four items in the evidence need verification before production, and release notes alone cannot settle any of them.

1. License terms. GitHub metadata reports the license as Other with SPDX identifier NOASSERTION. Before commercial use, embedding, or redistribution, read the license file in the exact version you plan to run and confirm it covers your use.
2. Authorization boundaries. Open issue #1553, filed June 15, 2026 and still open at this review, describes a missing membership check on GET /user/teams/:id. The reporter’s reproduction shows an authenticated non-member reading another team’s details with HTTP 200 while the sibling write endpoint returned 403. If your API will serve multiple users or tenants, treat this as unresolved until you confirm the fix in your chosen release and audit similar read endpoints.
3. Container detection on macOS. Open issue #1584 reports that on v1.0.0-rc17 with macOS arm64, YaoEngine does not detect Docker under OrbStack even though the setup screen reports it installed. Test your container environment early if that matches your setup.
4. Release churn. Version naming is still release candidate, and the observed cadence produced five candidates in roughly two weeks. Pin versions and build an upgrade and regression routine before you depend on it.

Who should not use it yet

Do not choose Yao Agents yet if your success criteria include a stable 1.0 release, a license you can rely on from GitHub metadata alone, hardened multi-tenant authorization out of the box, or vendor support. None of those are established by this snapshot. If nobody on the team can own server administration, backups, and release testing, a self-hosted agent fleet becomes a maintenance burden, and a simpler single-device agent tool is the more honest choice until you have that capacity.

Evaluation questions for your decision

• What license terms apply to the version you plan to run, and do they cover your intended commercial or internal use?
• Which release is current on your adoption date, and what changed since rc18?
• Who will authenticate to the API, and has the authorization gap in issue #1553 been fixed in that release?
• How will you back up workspaces, and what happens to a task when its node disconnects mid-run?
• Do your actual workflows need the recent changes, such as DeepSeek V4 configuration, vision message handling, or Baidu OCR?
• Is running agents on your own fleet a deliberate data-control choice, or would a managed platform impose less operational load for the same task?

Verdict

For a technical founder, developer, or operations manager deciding whether to self-host AI agents, Yao Agents is worth a controlled evaluation, but on this evidence it is not yet a proven production platform. Run the newest release in a sandbox with non-production data, confirm the license and authorization behavior, and integrate one real workflow before expanding. If pre-1.0 churn, license ambiguity, or the open authorization issue is unacceptable for your deployment, waiting or choosing a managed alternative is the technically honest decision.

Sources

• YaoApp/yao repository
• Yao v1.0.0-rc17 release notes
• Yao v1.0.0-rc18 release notes
• Open issue #1553: missing team membership check
• Open issue #1584: OrbStack Docker not detected

What I can do next

If you are weighing Yao Agents or a comparable self-hosted agent stack, the practical next step is a controlled evaluation. That is where I can help as AI and automation integration work: I can stand up a staging instance, connect agents to your internal systems through their APIs, and define the upgrade, backup, and patching routine that release-candidate software requires. To scope that work I would need access to your staging environment, the workflows and data boundaries involved, and confirmation of the license and authentication model. I would not promise a production outcome before those checks are done. Custom development and integration of this kind is covered under my software development services, and you can contact me with your use case to start the review.