In brief: Yao Agents (YaoApp/yao) is a self-hosted, Go-based system for running AI agent workspaces across machines you own. The current build is a release candidate, v1.0.0-rc25, published 2026-09-28. It fits a technical owner who wants local-first agent orchestration and is prepared to run and maintain the stack. It is not yet a turnkey production platform: confirm the license, the engine-versus-app-bundle install path, and the rc25 authorization fix before you commit.

review snapshot

the buyer problem this review addresses

The decision in front of a technical founder, operations lead, or internal platform owner is narrow: should agent work run on infrastructure you control, or stay inside a managed SaaS product? The stage is evaluation, and often replacement. A team already has scripts, a task tracker, and a few model API keys, and now wants agents doing recurring work across its own laptops and servers without shipping its data to a closed platform. The blocker is confidence. Yao Agents is self-hosted and model-agnostic, but the package you would adopt today is labeled a release candidate and ships as a two-part distribution rather than a single finished appliance.

what yao agents is, in one decision

According to the repository and the maintainers’ own positioning, Yao Agents puts all your agents and workspaces in one place, on every device you own. Agents run on machines you add, work is organized into isolated workspaces, tasks move across a board, and results land in an inbox, all reachable from desktop, mobile, browser, or API. The runtime is a single Go binary; the maintainers state it does not require Node.js or Python. Model providers are bring-your-own, including OpenAI, Anthropic, DeepSeek, Google, Ollama, or any OpenAI-compatible service, and the open API exposes SSE and WebSocket endpoints for wiring agents into existing applications.

The critical distinction for a buyer is that the downloadable product and the runtime are separate artifacts. The repository is the engine; the application bundle carries the AI Experts, board, inbox, and settings UI. The maintainers explicitly warn that a source build or a bare Linux engine starts but has no AI Experts and no board, so it looks broken. That one fact changes how you plan an evaluation and a rollout.

what changed in v1.0.0-rc25 and rc24

The rc25 release notes are written as one entry covering rc24 and rc25 since rc23. For an operator, the changes worth noting are:

• Bundled DeepSeek Harness (DSH) upgraded to upstream 0.1.7-rc.2, with multi-route provider configuration (PiAiRoute), reasoning levels and token budgets, and a built-in skill system including an Office skill for Word, Excel, and PowerPoint. The notes also flag a configuration migration: apiKeyEnv moved to dsh-llm-deepseek-api-key.
• Inline file diffs in agent output via a new FilePatch type, so execution messages can carry the file changes an agent made.
• Board and store changes: a SkipDefaultColumn option for board creation and a GetRecentMessages store method implemented for MongoDB and Redis.
• OpenAPI scope additions: tai resource aliases (tai:all, tai:all:own, tai:all:team) plus scopes for tai/proxy and tai/vnc.
• CUI chat UI work: per-tab model selection, draft and input caching, cancellation handling, inbox tasks-from-messages, a collapsible sidebar, and kanban task-detail fixes.
• A security fix for a missing membership check, covered in the next section.

The release notes were generated and published automatically by Yao Agents, and the maintainers list the underlying pull requests, so the details are attributable. This review did not reproduce any of them at runtime.

the rc25 fix operators must verify

The most consequential line item is issue #1553: the OpenAPI endpoint GET /user/teams/:id authenticated the caller but did not verify that the caller belonged to the team, so any logged-in user who knew a team_id could read another tenant’s team name, description, owner id, and settings. The issue reporter demonstrated the asymmetry, showing that sibling write and member endpoints correctly returned access denied, and noted that the most reliable path was a former member who still knew the team_id.

The rc25 notes state the fix landed: the endpoint now calls teamGet directly, verifies membership, and returns distinct team-not-found and access-denied errors. Two cautions for a buyer. First, the issue is still shown as open in the snapshot even though the release note describes it as fixed, so reconcile the tracker state against the shipped artifact during your own review. Second, this review is a documentation read, not a penetration test; treat the fix as documented, not independently confirmed.

deployment concerns before production

If you move past evaluation, these are the operational realities the evidence supports:

• Two artifacts, one install. Follow the official installer path rather than building the engine from source, and confirm which bundle version accompanies which engine version, because the maintainers list them as independently versioned.
• Self-hosting is the default. You own the machines, the data, and the upgrades. That is the appeal and the cost.
• Remote execution is a security surface. The maintainers describe a tunnel feature, Tai Link, as connecting spare machines, home servers, and cloud VMs and giving agents a real desktop, shell, and file system remotely. Anything that reaches a shell on another machine deserves a scoped review.
• Model spend is yours. Because providers are bring-your-own, cost and data handling depend on the vendors you configure, not on Yao.
• Release cadence is fast. The repository moved from rc21 through rc25 between 2026-09-10 and 2026-09-28. Rapid pre-1.0 churn is normal but means you need a real upgrade-and-rollback routine.
• License needs a legal read. GitHub reports NOASSERTION, while the maintainers describe a modified Apache 2.0 license. Have someone confirm the terms for commercial use before you build on it.

limitations and unknowns

Several things cannot be settled from this evidence. There is no runtime, benchmark, or failover test attached, so throughput, stability, and upgrade behavior are unverified. The Jev decision-model figures circulating in the press, describing several-hundred-fold speed and cost improvements, originate with TypeSafe AI and its press coverage rather than with an independent test performed here; treat them as vendor claims. Open issues include OrbStack and Docker detection on macOS (#1584) and a request for an optional agent threat-rule scan on MCP tool calls (#1551), which is a proposal rather than shipped functionality. The license string is unresolved. And the in-one-place, on-every-device promise depends on network, tunnel, and per-machine setup that this review could not exercise.

who should and should not use it

Consider it if you are a technical owner, such as a founder who codes, an ops engineer, or a small platform team, who wants agents running on your own hardware, needs to keep data local, and is comfortable operating a Go binary plus an application bundle while tracking pre-1.0 releases. The model-agnostic design and open API make it a reasonable fit when existing systems must call the agents directly.

Wait or look elsewhere if you want a managed product with a support contract, need a stable GA release with predictable upgrades right now, or cannot perform the license, security, and backup work yourself. A non-technical buyer should not treat the current release candidate as a drop-in replacement for a hosted agent platform.

evaluation questions and alternatives

Before committing, get honest answers to these:

1. Can we install and operate both the engine and the application bundle on our target macOS, Windows, or Linux machines?
2. Which model providers will we configure, and where do our data and our prompts actually go?
3. Who owns backups and recovery of workspaces and the accumulated knowledge base?
4. What is our upgrade and rollback process between release candidates, and who tests it?
5. What is the security model for remote execution to other machines, and who reviews it?
6. Does our legal team accept the repository’s license terms as published?

Alternatives to weigh honestly: building a narrower in-house automation with a workflow engine you already run, adopting a managed agent platform, or self-hosting a different orchestrator. Yao Agents’ differentiator in this evidence is the combination of self-hosting, model-agnostic providers, and multi-device execution, not any verified performance edge.

verdict

Yao Agents is worth a structured pilot, not a production commitment, at v1.0.0-rc25. The architecture matches a real need: running agents across machines you own with the models you choose, and the rc25 notes show active maintenance and a security fix landing quickly. But this is a release candidate over a rapid rc cadence, distributed as two artifacts, with an unresolved license string and no runtime evidence in this review. Adopt it where you can absorb churn and roll back; keep it out of the path of anything that cannot tolerate a pre-1.0 dependency. A pilot that covers installation, the authorization fix, remote-execution security, and an upgrade drill will tell you more than any release note.

sources

• YaoApp/yao repository
• Release: Yao v1.0.0-rc25 (notes also cover rc24 since rc23)
• Issue #1553: missing membership check on GET /user/teams/:id
• Issue #1595: A Guide for AI Agents
• Yao Agents documentation

If you are weighing a self-hosted agent platform like this, I work on custom software development and system integration, with a focus on AI agent development, deployment, and production maintenance. To make that concrete, I would first need your target machines and OS mix, the model providers and data boundaries you must respect, and read access to a staging copy of whatever you already run; from there I can scope installation, authorization-fix verification, remote-execution review, and an upgrade plan. If that matches your situation, start here: tell me what you are running. I would not promise a working setup before I have seen your environment and confirmed the license terms.