A Desk, Not a Chat: Why Working With AI Agents Needs Tasks, Not Threads
The agent that actually knows how to do your work already lives on your local machine. It understands the repository, the local build setup, and the way you like to work. Yet the moment its work needs to touch another agent or another teammate, everything breaks down. The engineer is forced to play context broker, copying briefs, questions, and outputs from one window into another.
I felt this friction first on my own machine. I use distinct models and harnesses for architecture, implementation, code review, and testing because each model has different strengths. As agents gained the ability to run autonomously for hours, my job stopped being about writing every prompt by hand and became about making decisions when an agent hit a fork in the road. Running those agents across separate chat windows meant critical decisions were scattered across terminal tabs and scrolling message logs.
Before I wrote any code for Debo, I ran my agents on Todoist as a makeshift workspace. A task was the brief, the comment thread was the conversation, and an agent reassigned the task back to me only when it needed a decision. That simple loop changed how I worked. When I started building Debo, I was codifying a workflow I already relied on every day.
Every tool engineers use as a substitute today leaves a gap in that loop:
Standalone harnesses like Claude Code, Codex, and OpenCode do the right job for the model side of the work. They optimize session memory, token efficiency, and long-horizon execution. Making each agent stronger on its own, however, still leaves the engineer ferrying requirements and feedback between sessions by hand.
Single-user meta-harnesses like T3 Code wrap those harnesses into a desktop window with parallel threads. That improves the solo developer experience, but it misses where agents are heading: always-on entities with persistent identity, long-term memory, and personal adaptation. Once agents have distinct identities, collaboration across models has to center around a shared task record, not isolated threads on one laptop.
Issue trackers and team chat like Linear, Asana, and Slack sit on the other side of the divide. Trackers host embedded agents inside the ticket system, cut off from the personalized local agents that hold deep codebase context on an engineer's machine. Slack was built for human messaging, which means someone still has to transcribe the room's discussion back into an agent session.
Identity-first chat bots like xAI's Grok Bot and OpenAI's dots recognize that engineering is shifting from managing context to making decisions. They give bots persistent memory and bot-to-bot coordination. Yet they operate on walled-garden terms, preventing you from bringing your existing subscriptions or pairing agents from competing providers. Even then, their primary interface remains unstructured chat. When an agent runs autonomously for hours, a decision request sent as a chat message gets buried under noise.
Every one of these approaches treats the chat window as the primary workspace. Chat made sense when AI was a prompt-and-response tool. It fails when you manage multiple ongoing jobs that rarely need real-time supervision, where the workspace must surface only the work requiring human judgment while letting autonomous execution proceed unimpeded.
Ashu Garg has argued that the record should come from the work rather than from documentation. The question I've been living with is what the work surface has to look like for that to be true.
Orchestrating agents requires a structured desk, not a chat room.
On a desk, the task is the core unit of work and its comment thread is the shared conversation space. Sitting a layer above tools like Claude Code, Codex, and OpenCode, Debo lets you keep your existing agent ecosystem. You create agents with your preferred models and harnesses, assign a task from your desk, and let it move off your plate. The agent executes the work and logs updates directly in the thread. When a second agent steps in to review code or verify a claim, it inherits the full thread, briefs, answers, and prior decisions without manual copy-pasting. When an agent hits a decision point, it posts a query and reassigns the task to you with a priority level. You review the context, reply in line, and return the task to the agent.
Meanwhile, the boundary stays clean: your agent's personal context stays private on your machine, and only what it does on a shared task is visible to the team.
Companies tempted to build this in-house run into the same trap teams faced before Jira standardized agile workflows. Jira did more than track tickets; it gave software teams a shared operating rhythm. Human-agent collaboration requires a new operational paradigm whose rules are still being written in daily use. Building custom internal tools forces companies to manage approval chains, audit logging, data boundary isolation, and harness API churn as permanent overhead.
What a company should own sits below the desk: its models, its token spend, and its data. As teams consolidate their agents onto a single desk, every brief, decision, and solution is recorded on the tasks automatically. New teammates can read how senior engineers brief their agents. With consequential actions held for human approval, organizations get clarity on who took which action, who approved it, and which model was used. That record is what a company needs before it trusts an agent with more, and before it trains anything on how its own people decide.
Sources: The compounding asset enterprise software never had; Context graphs, one month in (Foundation Capital).