Why Your Agent Can't Walk and Chew Gum

There's a class of agent behavior that almost every product wants, and almost every framework expresses badly.

User asks a question. Agent says "let me check X, Y, Z." X takes 5 seconds. Y takes 2 minutes. Z takes 30. The user might change their mind, ask something else, or want a status update at any moment. The agent should keep talking while the work runs, and proactively push updates the moment anything finishes.

This is not exotic. It's customer support. It's recruiting. It's any operations console. It's how humans actually work.

But try expressing it in the major frameworks.

OpenAI Agents SDK and Swarm: handoff() is serial. You hand control over; you don't run in parallel. LangGraph: doable, but you're hand-rolling interrupts, checkpoints, and a state graph that doesn't want to be one. Claude Code's Task tool: blocks the parent — that's the whole point. AutoGen's GroupChat: turn-based; doesn't know what to do when X finishes at a random moment mid-conversation. CrewAI: assumes a team executing a process, not a conversation interleaved with background work.

Every one of these frameworks is solid for what it was designed for. None of them was designed for this.

The underlying issue: the main conversation and the background work are temporally asymmetric.

The main conversation is a passive consumer. It waits for input — from the human, or from a finished task — and reacts. Background tasks are active producers. They decide when there's progress, when there's a result, when something goes wrong.

Every framework above models agents as a single timeline because they descend, philosophically, from chatbots — turn-taking machines. The asymmetry has to be smuggled in via interrupts, schedulers, special handoff semantics.

There's an older, simpler abstraction that fits exactly: the actor model's mailbox. One queue. One consumer. Multiple producers. The consumer doesn't care who sent the message.

That's the entire idea behind agentcon.

The main loop has exactly one job: await inbox.get(). It doesn't know — and doesn't care — whether the next item came from a human typing or from a background task that just finished a two-minute web search.

Background tasks run as asyncio tasks. They emit events at four importance levels. PROGRESS is a UI update only and does not wake the main loop. ALERT wakes the main loop because something needs a decision. RESULT wakes the main loop because something finished. FAILED wakes the main loop because something broke.

The PROGRESS channel is what makes "report progress without interrupting the conversation" possible. The user can see "researching candidate 47 of 200…" on a progress bar while the agent talks to them about something completely different. The LLM only gets woken — and only ever between turns, never mid-turn — when something is actually worth its attention.

Writing a multi-agent framework, the easy mistake is to add. Graphs, roles, processes, handoff DSLs, state machines, retry policies. The hard work is subtracting until only the load-bearing wall is left.

agentcon's load-bearing wall is the inbox plus the four-level emit protocol. That's the entire abstraction. Everything else — sub-agent lifecycle, history trimming, persistence, human-in-the-loop, cost accounting — is built on top, and most of it is optional.

The core is around 1000 lines of Python. Zero required dependencies in the kernel. You can read the whole thing in an hour and debug it confidently in production, which is the actual reason small frameworks matter.

Some short, honest negatives, because every "look at my framework" post should have these.

If you need strict workflows or DAGs, use LangGraph. If handoff is your core pattern, use the OpenAI Agents SDK or CrewAI. If you need distributed workers across processes, agentcon is single-event-loop on purpose; bring your own message queue. If you want role-and-team metaphors, use CrewAI.

agentcon is the right tool for one specific shape: a long-running conversation interleaved with multiple asynchronous background workers that need to push updates on their own schedule. If that's not your problem, the right answer is a different framework.

The full design notes — including the six implementation details that make or break this kind of small runtime — are in the repo: github.com/Rumonthebeat/agentcon

If you've hit this exact pain, I'd love to hear how you worked around it before. If you think the abstraction is wrong, I'd love to hear that even more.