Why we think AI development will become multi agent

There is a tempting assumption in AI software: eventually one model becomes so good that the rest of the stack disappears.

Maybe.

We are building Horme around a different possibility. Even if one model becomes the overall leader, developers may still choose different agents for different jobs.

One agent may be preferred for implementation. Another may be preferred for review. Another may be faster. Another may have better tool use. Another may be cheaper. Another may be deliberately independent so it can challenge the first agent's work.

The interesting problem then stops being access to models. The problem becomes coordination.

The developer is currently the orchestration layer

Today, a multi agent workflow often looks like this:

ask Claude Code to implement
wait
read the output
copy the context
open Codex
ask it to review
read the findings
copy them back
ask Claude Code to fix them
check both terminals
remember what is still open

That is a strange place for human attention to go. Developers should spend their judgment on architecture, product decisions, risk, tradeoffs, and whether the result is actually good. They should not have to remember which terminal finished eleven minutes ago.

Better models can make orchestration more important

As agents become more capable, developers can delegate larger pieces of work. That sounds like it should reduce coordination. In practice, it can create a different kind of coordination problem.

If one agent can work for thirty minutes instead of thirty seconds, then several agents can also be doing substantial work at the same time. Now the questions become:

• What is running?
• What finished?
• What failed?
• What depends on what?
• Which result should another agent review?
• Which findings were fixed?
• What needs a human decision?
• What happened while I was away?

Those are operational questions. They require state, not another chat window.

We do not think every agent should live in one giant conversation

A single conversation is convenient, but it is not always the right abstraction for software work. Real development has structure. Features have dependencies. Reviews produce findings. Runs fail. Files change. Tests produce artifacts. Humans approve some decisions and reject others.

A useful orchestration layer should model those things directly.

workflow
  ├── task
  │     └── run
  ├── dependency
  ├── artifact
  ├── handoff
  ├── review
  └── intervention

Heterogeneous agents are the interesting case

Horme starts with Claude Code and Codex because they are separate agent systems with their own execution behavior. The point is not simply to support two brands. The point is to let them take part in connected work.

Today the Horme private beta runs real tasks on Claude Code and Codex through one run model. Connecting them into workflows like this one, with automatic handoffs, is what we are building next. The details are in How Horme works.

The interface should move up one level

Traditional development environments are centered on files. Agent driven development changes the center of gravity.

centered on files

open file
edit code
run command
debug

centered on work

define work
assign responsibility
watch execution
handle intervention
review result
approve

That is the larger idea behind Horme.

The bet

Our bet is not that developers need a prettier dashboard for several terminals. Our bet is that as agents do more real work, developers will need a control layer above them.

That layer should understand tasks, dependencies, handoffs, artifacts, interventions, reviews, and provenance. It should let different agents work together without forcing the developer to become the message bus between them.

The better the agents become, the more valuable that coordination layer could become.

That is what we are building Horme to explore. If you want to see the model in detail, start with What is AI agent orchestration?