Software factories
How many agents collaborate in Harmony without colliding: shared versioned artifacts, an auditable protocol, and provenance for every contribution.
A software factory is the idea that software production can be industrialised: repeatable steps, work that composes, and a record of what was produced and by whom. The term predates AI agents. Agents are what made it urgent, because writing code stopped being the bottleneck.
The bottleneck is coordination. Ten agents pointed at one repository do not behave like a team of ten. They behave like ten people editing the same file at the same time.
The mistake: treating a repo as the collaboration medium
The obvious approach is to give every agent the codebase and let them work. This fails immediately and in two directions:
- Share one checkout and agents overwrite each other, or produce merge conflicts nobody asked for.
- Give everyone an isolated worktree and you have traded collisions for divergence. Ten branches that never saw each other's reasoning still have to be reconciled by a human at the end.
Isolation is necessary when agents actually change code, and Harmony supports it (see Worktrees). But isolation is not collaboration. It is just deferred conflict.
How real teams do it
People do not collaborate by typing into the same buffer. They converge on shared work products: a specification, a plan, a ticket, a review, a decision record. Those documents are where disagreement gets resolved, before anyone touches code.
Harmony gives agents the same substrate.
Artifacts
An artifact is a file backed Markdown document with structure the daemon understands. Agents create, read, comment on and revise them over the same protocol they use to talk to each other.
Kinds
specification, plan, story, ticket, review, decision, note, runbook
Every artifact carries
| Field | What it gives you |
|---|---|
status | draft, ready, in_progress, blocked, in_review, done, cancelled |
assigneeAgentId | Which agent owns it right now |
parentArtifactId | A plan decomposes into stories, a story into tickets |
taskId | The work it belongs to |
version + contentHash | Revisions are tracked, and identical content is not duplicated |
Because artifacts are documents rather than simultaneous edits, contributions stack. Two agents adding sections to a specification is a normal Tuesday. Two agents editing the same function is a conflict.
nala artifacts list # what exists
nala artifacts get <id> # read one
nala artifacts export <id> # take it out of nala
Provenance
When ten agents contribute to one plan, "who decided this and why" becomes the expensive question. Every artifact records the answer:
- the creating agent, session, provider and model,
- the source inputs it was derived from, with digests,
- parent artifacts it descends from,
- revision number and a SHA-256 content digest.
So a decision made by a Grok agent at 2am, from a specification a Claude agent wrote, from a ticket you filed, is a chain you can walk. That is the part that makes this a factory rather than a pile of output.
nala artifacts provenance <id>
The protocol that ties it together
Agents coordinate over Harmony's agent to agent protocol. Messages are durable, acknowledged and idempotent, and they carry artifact references directly: a message can announce that an artifact was created or updated (artifact_notice) and list the artifactIds it produced or relied on.
That linkage is what keeps conversation and work product in sync. An agent does not say "I finished the plan" into a chat log that nobody can query. It updates the artifact, and the notice points at it.
The protocol is also honest about delivery, which matters more than it sounds:
- a send returns a delivery state, not a boolean;
- when Harmony cannot observe that a message was submitted, it reports unknown rather than success;
- an idle looking agent whose read path has degraded is reported as unknown, never as "idle, queue empty", because a blank read is not evidence of idleness.
An agent that received your instruction and an agent that never got it look identical unless something tracks the difference. See Delivery lifecycle.
State that survives
Sessions live in a daemon that is not the app. Close the window, reboot, come back: terminals, tasks, artifacts and agent state are still there. Suspended sessions persist for seven days. See Session survival.
What we are not claiming
We are not going to tell you a throughput multiple. Harmony is a new product, we publish no invented numbers or customer logos, and any figure we quoted would be one you could not check.
What we will say is that the mechanisms above are shipped and verifiable in about ten minutes:
nala artifacts list # the shared work product
nala artifacts provenance <id> # who produced what, from what
nala doctor # read and write reachability, per agent
nala agent list # model, provider and quota state, per agent
Then close the app, reopen it, and confirm your work is still there.
Where to start
- Your first workspace
- Your first orchestration run
- The A2A protocol
- Worktrees, for when agents do need to change code