UFO³: Microsoft's Multi-Device Agent Orchestrator Splits the Difference Between Desktop Automation and Cross-Device DAGs
UFO³: Weaving the Digital Agent Galaxy
At a glance
- What is it?
- Microsoft's UFO³ project pairs a stable Windows-only desktop agent (UFO²) with a newer Galaxy layer that decomposes tasks into DAGs and coordinates agents across Windows, Linux, and Android. The README positions Galaxy as the recommended path, but the documentation is thin on operational details.
- Who is it for?
- Adopt UFO³ if you need to automate a workflow that spans multiple heterogeneous devices and you are comfortable with a moderate learning curve and active development churn. Do not adopt it if you only need single-Windows automation: UFO² is the stable LTS path and can serve as a Galaxy device agent later.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Python, 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
What UFO³ actually is: two products in one repository
The repository contains two distinct layers. UFO² is a stable, long-term-support desktop agent for Windows that uses a sequential ReAct loop with a HostAgent and AppAgents to operate GUI and API actions. UFO³ Galaxy is the newer, recommended layer that coordinates multiple device agents across Windows, Linux, and Android. The README is explicit: UFO³ equals Galaxy plus UFO². Galaxy can use UFO² as its Windows device agent. That means you are not choosing one or the other; you can start with UFO² and later plug it into a Galaxy constellation. The project is aimed at engineers who need cross-device automation, not at end users who want a single click-to-automate tool. The learning curve is stated as moderate for Galaxy versus low for UFO², and the setup difficulty is 'moderate' for Galaxy. This is a developer-facing framework, not a polished product.
The Galaxy mechanism: declarative DAGs that rewrite themselves
Galaxy's core idea is that a user request is decomposed into a directed acyclic graph of TaskStars, each with dependencies. The README calls this 'Constellation', and the graph is not static. It evolves during execution based on feedback, through 'controlled rewrites and dynamic adjustments'. That is a meaningful departure from UFO²'s sequential ReAct loop. Instead of a single agent reasoning step by step, a ConstellationAgent plans at the device level, and a TaskOrchestrator schedules execution. The graph can be edited dynamically, which suggests you can intervene mid-task. Execution is asynchronous and parallel, with 'safe locking' to prevent conflicts. The README claims 'formally verified correctness', which is a strong claim that I cannot verify from the supplied material. There is no formal proof in the README, only the phrase. Treat that as a marketing statement until you see the actual verification artifacts.
AIP: the WebSocket coordination layer that makes multi-device work
For agents on different devices to cooperate, they need a common protocol. Galaxy defines the Unified Agent Interaction Protocol (AIP), a WebSocket-based coordination layer with fault tolerance and automatic reconnection. The README says AIP enables 'secure agent communication', but it does not specify the security mechanism, whether TLS, token-based auth, or something else. That is a gap you need to investigate before using it across untrusted networks. The design choice to use WebSocket is practical for bidirectional, low-latency messaging, and automatic reconnection is essential for long-running automations where a device might drop off. However, the README does not describe how the protocol handles message ordering or idempotency, which are critical for DAG execution. If two parallel tasks depend on the same device, the safe locking mechanism is supposed to prevent conflicts, but again, the details are not in the README. You will need to read the source in the galaxy directory to understand the actual semantics.
Getting it running: what the README actually tells you
The README does not include a single installation command or configuration key. It points to the online documentation at microsoft.github.io/UFO/ for a 'Galaxy Quick Start', and it links to a galaxy/README.md inside the repository. The root README only says that Python 3.10 or 3.11 is supported and that the license is MIT. For actual setup, you must follow the quick start guide, which is not in the material I have. That is a limitation of this review: I cannot give you the real commands because the README omits them. What I can confirm is that the project has recent releases (v3.0.8 from August 2026) and the default branch is main. The migration path for UFO² users is described: keep using UFO², or gradually adopt Galaxy by using UFO² as a Windows device agent. That suggests the setup for Galaxy involves configuring device agents, not just installing a single package. Expect to edit configuration files for each device and for the AIP connection, but you will need the online docs for exact keys.
Where it is the wrong tool: single-device automation and stability concerns
If your task runs on one Windows machine, Galaxy is overkill. The README explicitly says UFO² is 'STABLE & BATTLE-TESTED' and has LTS status, while Galaxy is in 'Active Development'. That is a warning. The latest release v3.0.8 is from August 2026, and the last push was September 2026, so development is active, but active development means breaking changes. The README also says device support includes 'Windows, Linux, Android (more coming)'. That parenthetical suggests the current set is incomplete. If you need macOS or iOS automation, this project is not for you yet. Another failure mode is the complexity of the DAG model. The README says Galaxy handles tasks from 'Simple to Very Complex', but a simple task on a DAG orchestrator adds overhead. For a quick task, you are better off with UFO². The 'formally verified correctness' claim, if not backed by actual proofs, could give a false sense of safety in production. Verify that yourself.
Alternatives: from single-agent ReAct to full orchestration frameworks
The most direct alternative is UFO² itself, which is in the same repository. It uses a sequential ReAct loop, not a DAG. That is a fundamental difference in approach: UFO² reasons step by step, while Galaxy plans a graph and executes it in parallel. If you need cross-device orchestration but want a more mature ecosystem, consider a general workflow orchestrator like Apache Airflow or Prefect, which also use DAGs but are not agent-based. They do not have built-in GUI automation or device agents. Another alternative is a multi-agent framework like AutoGen or LangGraph, which also coordinate LLM agents but typically assume all agents run on the same host. UFO³'s differentiator is the device-level matching and the AIP protocol for heterogeneous platforms. The README mentions 'capability-based device matching', which means Galaxy can choose which device can perform a task based on its declared capabilities. That is a design choice you will not find in a generic DAG orchestrator. Evaluate which layer of abstraction you need: task scheduling or device control.
Maintenance, license, and the cost of adopting a moving target
The project is MIT-licensed, which means you can use, modify, and distribute it freely, including in commercial products, as long as you preserve the license notice. That is a low legal barrier. The maintenance picture is mixed. UFO² is LTS, so it will receive long-term support. Galaxy is in active development, with releases roughly every two months (v3.0.6 in June, v3.0.7 in June, v3.0.8 in August 2026). Frequent releases can mean frequent fixes, but also frequent changes to configuration and APIs. The README does not mention a deprecation policy or a migration guide for Galaxy versions. The documentation is hosted separately, and the root README is more of a landing page than a manual. If you adopt Galaxy, budget time for reading the online docs and the source code. The 'template-driven MCP-empowered device agents' part suggests you can build custom device agents using templates and MCP (Model Context Protocol) integration, but again, the details are not in the README. You will need to inspect the galaxy directory to understand the template structure.
Editorial conclusion
Adopt UFO³ if you need to automate a workflow that spans multiple heterogeneous devices and you are comfortable with a moderate learning curve and active development churn. Do not adopt it if you only need single-Windows automation: UFO² is the stable LTS path and can serve as a Galaxy device agent later. Before committing, verify that your target platforms (Windows, Linux, Android) are actually supported in the current release, because the README says 'more coming' and the Galaxy docs are not yet detailed. Check the v3.0.8 release notes for known issues with the AIP WebSocket layer and DAG rewriting, and test with a small two-device task before scaling. The project is MIT-licensed, so you can fork it, but the real cost is integration effort, not license friction.
Community notes