Theoretical New Coding Agent

Methodology

This analysis is based on code inspection of all 16 agents in this field guide: Pochi, Neovate Code, Mux, Crush, Kimi CLI, Qwen Code, OpenHands, Claude Code, DeerFlow, Hermes Agent, Codex CLI, Pi Mono, Wintermolt, Zaica, Open Claude Code 2.0, and the now-archived hermes-agent.

For each agent, I identified: core architecture, tool implementations, provider integration patterns, context management approaches, permission systems, and extensibility mechanisms. The goal: extract patterns that appear across multiple agents — these are likely essential, not optional.

The Universal Agent Loop

Every coding agent implements some variant of this fundamental loop:

The variations come in how each step is implemented:

• Async generator (Open Claude Code) — yields events, recursive continuation
• Callback-based (Claude Code, Crush) — handlers for stream events
• Thread-based (Zaica, Wintermolt) — worker threads, message passing
• Graph-based (DeerFlow) — LangGraph nodes and edges

Essential Features — Must Include

These features appear in every coding agent in this set. Omitting them would make the agent incomplete.

Near-Universal Features — Include Unless Deliberately Omitting

These appear in 12-15 of 16 agents. Include them unless you have a specific philosophical reason not to.

Code Distribution — What Takes Up The Most Space

Based on file sizes and line counts across these agents, here's approximately where the code goes:

Common Architectural Patterns

Across all these agents, certain patterns repeat. These are tried-and-true approaches that multiple agents have validated.

Unique Innovations — Consider Including

These features appear in only 1-3 agents but represent genuinely good ideas worth considering.

Minimum Viable Coding Agent

If you wanted to build the smallest possible functional coding agent, here's what you'd need:

Agents That Add Then Remove Code

An interesting observation from this analysis cycle: which agents seem to be in a state of flux, adding features then pruning them?

DeerFlow's citation removal is particularly notable — they had a full citation parsing system (SafeCitationContent, use-parsed-citations, citation utilities) and removed it entirely. This suggests they found citations weren't worth the complexity for their use case.

Interesting Insights

Recommendations for New Agent Builders

1. Start with Pi Mono's minimal kernel approach. Ship a working core, then add extensions. A 10-file agent that works is better than a 500-file agent that doesn't.
2. Use tool registry pattern. Tools should be discoverable, composable, and swappable. Don't hardcode tool calls in the loop.
3. Implement two-tier compaction from day one. Micro-compaction (truncate old tool results to 100 chars) is cheap to implement and saves tokens constantly.
4. Build permission as middleware. Don't mix permission logic with tool execution — wrap the tool call, check permissions, proceed or deny.
5. Support MCP from the start. It's the standard for extensibility. stdio transport is simplest to implement first.
6. Don't skimp on Bash. It's the tool users care about most. Handle timeouts, background jobs, output limits, and at least basic injection detection.
7. Plan for checkpointing. File before-write checkpoints enable undo. Even a simple backup-copy before edit catches most disasters.
8. Use existing patterns. The agent loop, tool registry, middleware chain, and provider abstraction have been validated across 16 agents. Don't innovate on architecture — replicate what works.

Bottom Line

Building a coding agent from scratch? Focus your energy on:

1. Bash tool — most code, most user impact
2. Permission system — safety-critical, often under-engineered
3. Two-tier compaction — token efficiency is existential for long tasks
4. MCP integration — extensibility standard, not optional

Everything else — skills, slash commands, sub-agents, multi-provider — can be added later. The core loop + 6 tools + LLM provider + compaction is a working agent on day one.