10 AI Agent Work Platforms Dissected: Where Should Your Agent Actually Run?

When AI coding enters the "agent era," the core question developers face has shifted from "which model should write my code" to a more structural one: Where should your agent work? And after you hand off a task, what actually survives?

Tali, host of the YouTube channel Flywheel, used a unified set of evaluation criteria — control, execution location, persistence, total cost, and evidence — to systematically examine 10 AI agent work platforms. Her stated principle: "read what they actually ship, not what they say on stage." This article maps out her architecture-layered evaluation to help you think clearly before paying for your next agent tool: what capability are you actually missing?

Four Starting Points: Who Hosts Your Agent?

The central insight of this evaluation is that while integrated environments may look similar on the surface, they make four fundamentally different choices about where work begins — and the starting point itself is the lock-in.

Cursor puts the editor at the center. Files, language servers, remote access, code review, and multi-model capabilities are all consolidated here, with a subscription model where cloud agent work draws from plan credits. It's designed for developers who want the editor to always be the control surface — even when work moves to the cloud, the controls stay in the familiar IDE.

Cognition (Devin) starts from a different premise: developers are transitioning from "pair programming with a single agent" to "managing local and cloud agents as a manager." Tali quotes their position — the best engineers no longer focus on one agent at a time; instead, they scope work, plan tasks, delegate to cloud agents, review progress, and decide what ships. Devin Desktop (the renamed Windsurf IDE) is the command center for local and cloud agents, while Devin itself is a cloud worker running in a managed development environment. The two sit side by side but occupy different architectural layers: one executes delegated backlog work, the other is where you orchestrate and review.

Replit Agent packages the other end: prompts, apps, databases, authentication, hosting, and deployment. Its positioning is the complete workflow from "idea to running application," with no local infrastructure assembly required. The key advantage: the agent can use the exact same hosting services as a human developer — creating databases, connecting front and back ends, even deploying full-stack applications. A subscription unlocks access, but the real cost is driven by effort credits.

Kiro moves the starting point one step further, placing requirements and reusable tasks before code generation. This is Amazon's "requirements-first" workspace, spanning IDE, CLI, and web. It can read codebases, write production-grade code, run automated quality checks, and connect to databases — with all configuration shareable across teams via Git. It's built for teams that want specs, hooks, custom agents, and org-level alignment.

These four products are not four versions of the same editor: Cursor is development-environment-centric, Devin is delegation-centric, Replit is running-application-centric, and Kiro is specification-centric. Where your work begins determines where you're locked in.

Lock-in carries a specific technical meaning here: when your workflows, configuration files, permission systems, and historical context accumulate in a platform's proprietary format or private storage, the friction of migration makes switching practically infeasible. For AI coding tools, lock-in is more granular than traditional SaaS — it's not just data formats, but also the agent's "memory" of your codebase (project-level rules, custom instructions), accumulated workflow scripts, and the operational habits your team has internalized. When choosing a starting point, it's worth asking upfront: if you need to switch platforms in three months, what can you take with you via Git, and what stays behind?

Attention Orchestration: When Terminal Tabs Become a Seating Chart

Tali notes that a fifth category of failure only surfaces after the agent has done its work — your attention is the first thing to break down. When parallel terminal tabs multiply into something resembling a seating chart, waiting and reviewing themselves become quantifiable work.

The tools in this layer (herder, Orca, cmux, ccmux) don't replace coding agents — they organize sessions, terminals, work trees, dependencies, and notifications.

herder turns three agent terminals into a queue you can actually supervise. It tells you when an agent needs input, when it's ready, and when it's blocked. With a background server, sessions survive disconnection, waiting states become queues, and an operator can reconnect from any machine. Free for local use; cloud pricing undisclosed.

Orca centers on repositories and work trees, combining isolated workspaces, managed terminals, visible diffs, skills, automation, computer operations, and supervised coordination. Its philosophy: every task should have its own isolated space — its own files, its own branch, its own terminal — with agents running in parallel without interfering with each other, preserving results and moving forward after completion. Work trees are the product's boundary, not an implementation detail. Public pricing unavailable.

cmux starts from the terminal itself — a native Mac terminal built for multi-task coding agents, with agent workspaces, notifications, a browser panel, Socket API, and optional cloud machines. The local terminal is free and open source. You can embed a browser (WebView Safari) in a split panel, and when Claude stops, a prompt appears immediately on the left.

ccmux makes the opposite choice: rather than replacing the terminal, it observes agents already running in tmux, tracking wait states, preview panels, and managing handoffs. One rebuilds the terminal interface (cmux); the other adapts to your existing terminal (ccmux) — two fundamentally different philosophies within the attention orchestration layer.

Work Tree is a built-in Git feature (git worktree) that allows the same repository to check out different branches in multiple directories simultaneously. Each directory has independent working-area state while sharing the same commit history and object store. In parallel multi-agent scenarios, this mechanism becomes especially valuable: each agent can modify files and run tests in its own work tree without file conflicts or frequent stash/pop operations. Both Orca and ccmux use work trees as their core abstraction precisely because isolated work trees naturally map to the parallel engineering model of "one task, one space, one branch."

tmux is a terminal multiplexer that allows maintaining multiple sessions, windows, and panes within a single terminal connection, with sessions persisting even after SSH disconnects. ccmux adds an agent-state awareness layer on top of tmux without replacing it — a design philosophy of "adapting to existing workflows" rather than "rebuilding workflows."

Context and Evidence: What Must Survive the Handoff?

The sharpest question in the entire evaluation is the "handoff test": after switching agents, ask it four things — What is the goal? Who owns this work? Why did the plan change? What has been validated?

If your Git history, documentation, and issue tracker can answer those four questions, nothing needs to be added. Only when the answers exist solely within a session does a scoped context service deliver measurable value.

The Breathe MCP Tali mentions provides a catalog of 27 operations across five categories: memory, work, coordination, evidence, and operations. A handoff moves from "capture" to "claim" to "evidence" to "restore." But she's explicit about its limits: Breathe MCP doesn't generate agents, doesn't own terminals, doesn't create work trees, doesn't deploy software, and doesn't provide models. Pricing and public licensing are unavailable; hosting, storage, backup, and connected models remain part of your bill.

Shared tools don't equal shared judgment, and shared memory doesn't make two agents safe in the same code checkout. This is the final category of failure — once agents can hand work off to other agents, you still need to hire the person who stands above the entire stack. Tools can show you what happened, but how do you confirm an engineer understands live systems, can judge handoff quality, and verify work outputs? That's a hiring problem.

MCP (Model Context Protocol) is an open protocol proposed by Anthropic in late 2024, designed to standardize how AI models connect with external tools and data sources. MCP servers expose "resources" (data) and "tools" (callable operations) through a unified interface; model clients dynamically discover and invoke these capabilities through the protocol without needing to hard-code separate integrations for each external system. Breathe MCP is built on this protocol — it encapsulates memory, task state, and evidence as MCP tools, callable by different agents at different stages of the same task lifecycle. Understanding MCP's boundaries helps clarify Breathe's boundaries: it's a context service at the protocol layer, not an agent framework at the execution layer.

Six Selection Questions and the Subtraction Principle

Tali's practical advice: before buying yet another agent, first identify which capability is actually missing, then run through six questions:

1. What is it selling? A model, harness, workspace, managed computer, orchestrator, or context service?
2. Where does it run?
3. What can it control? Chat, browser, accounts, terminal, repository, or deployment?
4. What survives when the session ends?
5. What's the total bill? Including credits, model costs, hosting, and review time.
6. What evidence is returned before sign-off?

Her core argument is the subtraction principle: start with one execution path and one real task, and only add a new product when quantified failure gives you a reason to.

This produces four reasonable starting points: a solo repository needs only one harness plus Git; an "idea to URL" project may need an integrated builder; a managed backlog might justify a cloud workspace; parallel engineering should start with isolated work trees, adding attention orchestration only when waiting becomes the bottleneck.

If Git can answer the handoff questions, skip the memory infrastructure. If one agent owns the task exclusively, skip the orchestration. If the workspace itself can publish the app, keep its stack.

Tali's final verdict lands squarely: The winner is the smallest verifiable stack — not the one with the most agents or the flashiest launch event. Choose the stack whose limits you understand, whose bill you can explain, and for which there's a named human to verify and be accountable. Sound architecture contains only the failures you can see — and recover from.