DeepSeek's Open-Source Super Agent: Why Still Can't Tap Your Apps?

DeepSeek has open-sourced a new architecture called Super Agent, and the idea is straightforward: if one person can't handle everything, give the AI a team. One acts as the dispatcher, deciding what needs to be done; the others do the actual work. These two roles are called Router and Worker.

Sounds like a good approach, but the question is: what kind of work is the dispatcher actually sending out?

The Dispatcher Design: Why Router Can't Do the Work Itself

The most thought-provoking design in Super Agent is that Router is deliberately designed to be unable to do the work itself. The reason isn't complicated: if the dispatcher could get hands-on, it would inevitably start doing things itself, and once it does, all tasks have to queue up waiting for it.

This constraint actually addresses a common "dispatcher bottleneck" in multi-agent systems—once the scheduling layer gets bogged down in concrete execution, the entire system's parallelism degrades to single-threaded operation. DeepSeek^Ad chose to avoid this problem through architectural constraints, and the approach is clear.

But architectural elegance cannot replace scrutiny of task types. That's where the real issue lies.

"Dispatcher bottleneck" is a typical anti-pattern in multi-agent systems: when the node responsible for task distribution also has execution capabilities, it tends to handle some tasks personally, leaving other Workers idle and degrading the system to serial execution. In traditional distributed systems, a similar approach is reflected in "scheduler-executor separation"—for example, Kubernetes' scheduler only binds Pods to nodes and doesn't participate in actual container execution. Super Agent's architectural constraint that strips Router of execution capability essentially trades "capability isolation" for "scheduling focus," which parallels the design philosophy of operating systems separating interrupt handling from user-space tasks.

The Work Being Dispatched: What Router Can Actually Mobilize

According to a breakdown by a Bilibili creator, Super Agent's demo examples focus on scenarios like group chats, GitHub, email, and CI. Their common thread: all are things programs can directly call—send a request, get a response.

This boundary is clearly drawn. If there's an API, AI can call it; if there's no API, AI can't. And the things you actually need to get done each day—WeChat, banking, medical appointments—fall squarely into the latter category. They don't accept programmatic requests; they only provide an interface for humans to look at.

So Super Agent's capability radius essentially depends on whether the target system has open interfaces. This isn't a question of model capability; it's a question of system ecosystem.

Here, "API" broadly refers to programmatic invocation interfaces exposed by systems, including RESTful APIs, GraphQL, gRPC, command-line tools, SDKs, and Webhooks. Whether a system can be "called" depends on whether it provides machine-readable invocation conventions and structured returns. Mobile apps typically only provide GUIs for human vision, and their interface elements lack semantic programmatic interfaces, so Agents cannot operate them through request-response patterns. This is exactly the dividing line between "has API" and "no API": the former is a system ecosystem issue, while the latter requires screen understanding and simulated interaction technologies to bridge the gap.

The Three Types of Workers, and the One Being Overlooked

Based on the above analysis, Workers can actually be divided into three categories:

• Type 1: Another program. Works through command lines and interfaces—this is what the vast majority of Agent projects are doing today, and the ecosystem is the most bustling.
• Type 2: A mobile app. Interface only, no API—almost no one touches this.
• Type 3: Another device. Completes tasks through device-to-device collaboration.

Types 1 and 3 both have mature paths, but Type 2—the apps in most ordinary people's phones—is being skipped. And this is precisely the scenario with the strongest user perception.

Andy's Solution: Reading the Interface as a List, Not Calculating Coordinates

The Bilibili creator mentioned Andy, which tackles the Type 2 Worker. Its approach: don't rely on APIs—look directly at the screen.

Specifically: it reads the screen as a list, numbers each clickable element; instead of calculating coordinates, it overlays a grid on the screenshot and reports which cell. This is fundamentally different from traditional coordinate-based tapping—coordinate tapping relies on precise pixel positioning and easily fails when the interface changes; the grid-plus-numbering approach has higher fault tolerance and is closer to the human behavior logic of "see a button, tap it."

There's also a safety rule: if it pokes the same spot three times, it stops. Because repeatedly poking the same location means it's actually guessing. Rather than tapping blindly, it's better to ask the user first. This "three strikes and stop" mechanism is a pragmatic response to the common "blind retry" problem in automated systems.

Traditional coordinate tapping relies on screen resolution, window position, and pixel-level positioning. Once the interface layout changes, a popup appears, or device resolution differs, coordinates become invalid. The grid-plus-numbering approach divides the screen into regular cells, maps each clickable element to a cell number, and the model only needs to output the number rather than precise coordinates—thus reducing dependence on pixel-level precision and improving robustness across devices and resolutions. This approach is close to "spatial discretization"—replacing continuous coordinate space with finite grids, shrinking the decision space from infinite pixels to finite numbers, which both reduces model output difficulty and improves fault tolerance.

Password Handling: The Field the Model Can Never Access

Another design worth mentioning is passwords. The model never gets the password; it can only request the device to input it. The model only knows that 12 characters were entered, but not what those 12 characters are.

This design strips sensitive information handling from the model layer to the device layer, architecturally cutting off any possibility of the model coming into contact with plaintext credentials. For scenarios where AI needs to operate real accounts, this is a necessary isolation.

The design that "the model never gets the password" follows the Principle of Least Privilege: the model is only granted the information necessary to complete the task, not all information. In implementation, password input is handled by controlled components on the device side; the model can only initiate a "request input" action and learn metadata such as input length, but cannot read plaintext content. This isolation confines sensitive credential handling within a trusted execution environment—even if the model is subjected to prompt injection attacks or hallucinates, it cannot leak passwords. This is similar to the "tokenization" approach in payment systems—replacing real credentials with proxy credentials to architecturally cut off exposure paths for sensitive data.

Can Call vs. Can't Call: The Real Boundary of Agent Capabilities

Back to the question in the title. DeepSeek's Super Agent architecture solves "how to organize multiple Agents to collaborate," but doesn't solve "whether the target system is willing to be called."

Some things can be called—systems with APIs, command lines, or open protocols. Some things can't—the apps in your phone that only have interfaces basically all fall into this category. If AI wants to do things for you, it has to learn to look and tap on its own. This is the problem that solutions like Andy aim to solve.

Multi-agent collaboration architecture design and real-world interface operation capability are two independent battlefronts. The former already has relatively mature paradigms; the latter is still in early exploration. Super Agent's Router/Worker division provides an extensible skeleton, but beneath that skeleton, the absence of Type 2 Workers means it still can't reach ordinary users' daily work for now.

The real barrier isn't in the scheduling logic—it's in those interfaces that don't accept requests.