FastAgent: The Kanban-Driven Agent Framework for Research and Computer Use
HKUDS splits planning, execution, and review into separate roles, then uses a shared board to keep the whole system legible, recoverable, and easier to debug.
- FastAgent turns agent orchestration into a visible Kanban system, which makes state recoverable instead of hidden in chat.
- Host, Grounding, and Eval divide planning, execution, and review into separate jobs, so failures have clear boundaries.
- BLOCKED is a replan signal, not a dead end, which lets the framework recover without thrashing on the same step.
- The grounding and memory layers keep long workflows practical by narrowing tools and compressing history.
A Kanban board is the brain
Most agent frameworks hide task state inside a chat log. FastAgent puts that state on a board. That one move changes the product from a clever prompt wrapper into workflow software you can inspect, hand off, and repair when something breaks.
HKUDS frames the project as a bridge between intelligent research and computer operation, but the board is the sharper idea. Once work becomes cards with states, the system stops feeling like a one-shot conversation and starts feeling like a team that knows where the blockers are.
That matters because long workflows fail in boring ways. A browser tab changes. A desktop element moves. A step succeeds once, then fails twice. A board gives those failures names, and names are easier to manage than vibes.
Host, Grounding, Eval: three jobs instead of one giant prompt
FastAgent splits the work into three roles. The Host plans and updates the board. The Grounding Agent executes the step. The Eval Agent checks the result against the original intent.
That separation is not just tidy architecture. It makes failure easier to localize. If a result is wrong, the problem is usually one of three things: the plan was off, the execution went wrong, or the output did not match the plan.
The Grounding Agent also carries the backend scope that decides whether the work goes through shell, GUI, web, or MCP. In other words, the model does not need to hold every capability in its head at once. It asks for the right surface at the right moment.
When a card gets blocked, FastAgent replans
The most revealing detail in the repo is that BLOCKED is not treated as failure. It becomes input for a replan context. The Host can revise the route instead of hammering the same broken step again.
That is the difference between automation that thrashes and automation that manages itself. A blocked task can trigger a new path through the board, which is much closer to how a real team handles a dependency that moved or a website that changed underfoot.
The board also behaves a bit like a lightweight DAG. Tasks depend on earlier tasks, so the system keeps enough structure to recover without turning every mistake into a full reset.
How FastAgent reaches into the world
This is where the repo stops being only about planning and starts being about reach. Shell, GUI, web, and MCP are different drawers in one cabinet. The interesting part is not that FastAgent can touch many tools. The interesting part is that it can treat them as one execution layer.
The repository also points toward dynamic tool retrieval, which matters more than it sounds. Instead of flooding the prompt with every possible tool, the grounding layer can narrow the surface area to what the subtask actually needs. That keeps attention focused and the context window cleaner.
The platform adapters for Windows, macOS, and Linux make the computer-use story feel serious rather than speculative. The sandbox hooks also suggest the authors understand the risk of letting a model touch a live machine.
Memory is the quiet problem
Long-running agent jobs usually fail because context balloons. FastAgent’s summarizer tries to keep the decisions and the structure while pruning repetitive operations and stale noise. That is not flashy, but it is exactly the kind of mechanism that keeps a workflow alive after step twenty.
This is also where the project becomes practical. If the system can remember the important turns without carrying every failed click or redundant retry, it can stay legible to the Host and useful to the next step.
FastAgent versus the usual agent stacks
The quickest way to place FastAgent is by contrast. It is not trying to be a generic chat agent, and it is not just an MCP wrapper. It is trying to make orchestration visible enough that a complex workflow can be recovered when one piece goes wrong.
| Dimension | Linear chat agents | Generic multi-agent frameworks | MCP-only stacks | FastAgent |
|---|---|---|---|---|
| Coordination model | Single conversation thread | Role split, but often hidden in prompts | Tool registry without a task model | Kanban board with explicit states and handoffs |
| State representation | Implicit in messages | Distributed across agents and logs | Mostly tool metadata | Shared board plus dependencies |
| Failure recovery | Retry the same prompt | Agent-to-agent retries | Pick another tool | Replan from BLOCKED state |
| Tool loading | Whatever the chat sees | Often a long prompt of tools | MCP is the main abstraction | Tool retrieval narrows the surface area |
| Human readability | Low once the thread grows | Moderate, but scattered | Good for tools, weak for workflow | High, because the board is the system of record |
| Best fit | Single-turn helpers | Broad experimentation | Tool access only | Research and computer-use workflows |
The bigger idea
FastAgent’s larger argument is simple. Do not ask one model to be planner, worker, reviewer, and historian at once. Give each role a board, give the work a state, and give failure a path forward.
That is why the repo feels like workflow software with AI inside it, not an AI demo with a few tools attached. The board is not decoration. It is the mechanism that makes the whole system debuggable.
