Fork Moyai? — three-lane consensus
Fork Moyai? — three-lane consensus
Young, 2026-10-10: "Moyai and liteagents, they're existed and ready for production. SolOSV3 is reinventing the wheel that they both included? Can we fork from Moyai and add SolOS V3 touch on it?"
Three agents studied this independently. All three reached the same answer: don't fork, but borrow — and the reason is measurable, not a preference.
| Lane | Author | Verdict | Key finding |
|---|---|---|---|
| A2A / SDK / executor | Sol | borrow 2, fork 0 | live_steering=True on Hermes — the follow-up capability V3 needs |
| Cost / providers / dependency risk | Mira | adopt as spec, no code | liteagents is 0.3.0a6 — an alpha, not production |
| Registry / identity / tasks | Min | read 7 files, keep our spine | Moyai does not speak A2A at all |
1. The consensus answer
No fork. Read their files, adopt the patterns, keep our spine.
The three analyses are complementary, not contradictory. Sol measured the codebase and found the one thing we genuinely need that Moyai has. Mira measured the dependency risk and found that liteagents is not production-ready. Min measured the protocol surface and found that Moyai has no A2A — our spine.
Together they give a complete answer:
| Question | Answer | Who measured it |
|---|---|---|
| Does Moyai have A2A? | No — no dependency, no agent card, no JSON-RPC | Min |
| Does Moyai have a fleet/registry? | No — one agent per session | Sol |
| Does Moyai have personas/lanes? | No | Sol |
| Does Moyai have a task contract? | No — runs/journal tables, not a state machine | Sol |
| Does Moyai have a cost ladder? | No — LiteLLM gateway, not GO/ZEN | Sol |
| Does Moyai have conformance probes? | 6 eval files vs our whole harness lane | Sol |
| Does Moyai have live steering? | Yes — live_steering=True on Hermes | Sol |
| Does Moyai have a harness registry? | Yes — HarnessDefinition(...) | Sol |
| Does Moyai have a sandbox? | Yes — Modal/lambda, with a permission fence | Sol |
| Is liteagents production-ready? | No — 0.3.0a6, 18 days old, 28 commits | Mira |
| Is Moyai production-shaped? | Yes — 245 stars, 223 commits, MIT | Mira |
| Are we reinventing any wheel? | Yes, 2 — cost ledger, skills load model | Mira |
2. What we are reinventing — and should stop
Mira named it precisely: we designed from first principles two things that a third party had already shipped.
| What we designed | Moyai already has it | Verdict |
|---|---|---|
The cost ledger — billing_instrument, cost_state, window_state | "LiteLLM attributes each request to the teammate who made it" + "limits on requests and output do not limit the cost" | ADOPT THE PATTERN |
| The skills load model — capability-gated vs task-driven | skills_search → ≤5 matches as metadata → content only after skills_load | ADOPT — this settles our open question |
That is real waste, and it cost us documents, not months — because we caught it at the design stage, not the build stage. That is the cheapest possible time to be wrong.
3. What we are NOT reinventing — and cannot get from a fork
Sol's measurement is the decisive one. Moyai has NONE of these:
- A2A v1.0 transport — the spine of V3
- Multi-agent fleet / registry —
cortex/registry - Per-agent identity, personas, lanes — 11 agents, 3 planes
- Task contract with wire state mapping —
cortex/tasks - Free-first cost ladder across two pools — GO/ZEN
- Conformance / negative-case probes —
core/harness/
A fork would give us their sandbox and cost us our architecture. We would
inherit 723 files of a product we do not need — app/, frontend/, deploy/,
13 GitHub workflows, Modal/lambda deployment — and still have to build registry,
A2A, task contract, personas and harness from nothing.
4. The one thing we genuinely need from Moyai
Sol found it: live_steering=True on Hermes.
Young's requirement: "brain Unit can follow up if agent got stuck or block."
Moyai already does this — corrections arrive while the agent works, through a
native inbox. sandbox/harness_agent.py:30:
"Hermes owns its native inbox; other runtimes reject input until their public journal is ready instead of acknowledging an unowned message."
That is the follow-up loop, and it is the requirement my structure review marked as undefined because nobody owns the duration rule.
It is not a complete answer — Moyai steers a session, not a peer agent,
and we still need the stuck-rule for a fleet. But it is the closest working
implementation of the shape we need, and it is a much better starting point than
a blank core/arms/.
Also from Sol: HarnessDefinition(name, label, module, class, live_steering=, durable_context=) is the exact shape for core/arms/. Write our enum in that
shape. No import, no pin, no patch.
5. Mira's correction — liteagents is not production-ready
Mira pushed back on the premise, and she is right.
| liteagents | Moyai | |
|---|---|---|
| Version | 0.3.0a6 — alpha | production-shaped |
| Age | 18 days | 11 days |
| Commits | ~28 | ~223 |
| Stars | ~21–37 | 245 |
| Distribution | GitHub release wheel — "the PyPI name belongs to another package" | PyPI |
| API stability | v2 replaced v1, liteagents.legacy behind an extra | stable |
An alpha, 18 days old, 28 commits, distributed outside PyPI because of a name collision, with a public API already rewritten once. That is not production readiness.
Mira also corrected herself: earlier she argued a2a-sdk's 26-package
dependency bill was cheap. "liteagents is not that risk class and I should not
price them the same — one is the spec's own implementation, the other is a
three-week-old alpha."
They should not be judged as a pair.
6. The one scenario where a fork WOULD be right
Mira framed it exactly right: the question is not "reinventing vs forking." It is: does Young want the architecture we have spent a day designing, or a system that runs this week that we then bend to that architecture?
| Fork wins if | Because |
|---|---|
| Time-to-running beats fork-maintenance cost | find -name '*.py' returns 0. We have nothing to protect |
| We accept deleting deployment surface (Modal/Render/web/Slack) | those are the fork's bulk, and they are also what makes it workable |
| Single-producer means merge pressure is hypothetical | Moyai's top contributor owns 237/~380 commits |
| AGPL/attribution is acceptable | both MIT. Compatible |
Both are legitimate. They are different products.
7. What I would do — the third option
Not "build it ourselves." Not "fork Moyai." A third option:
| Step | Action | Why |
|---|---|---|
| 1 | Adopt the two wheels Moyai already built — as specifications, not code | The cost ledger and the skills load model are design decisions we have now measured from a working system. Copy the behaviour; write our own implementation in our own lane. Zero new dependency |
| 2 | Read sandbox/harness_agent.py and the steering patches | Write our follow-up requirement against their shape: a native inbox per agent, owned by the agent, that accepts corrections while it works |
| 3 | Write core/arms/ in the HarnessDefinition shape | name, label, module, class, live_steering=, durable_context= — the exact enum Sol found |
| 4 | Keep LiteLLM's A2A gateway as the pattern for core/config/ | protocolVersion pinning, cost at the boundary — pattern, not dependency |
| 5 | Revisit the fork question once, at Phase 2 exit | with data instead of with a design. If Moyai has then solved something we are still building, the fork case is stronger |
Why this is not fence-sitting. It is the same reasoning that says free models first: the cheapest thing that satisfies the requirement wins, and a fork is not cheap. We spent documents on two wheels; adopting them costs nothing. We keep four wheels Moyai doesn't have; forking gets us two of them and pays for all seven.
8. The honest summary
| Question | Answer |
|---|---|
| Are we reinventing their wheel? | In 2 places, yes — cost ledger, skills load model. Read their files. |
| Is V3 otherwise a duplicate? | No. They have no A2A, no registry, no GO/ZEN, and a different deployment model |
| Should we fork? | No. We would inherit 723 files we do not need, then rewrite the parts that matter |
| What is the right move? | Read 7 files, adopt the patterns, keep our spine |
| When would a fork be right? | If Young wants a running system this week — then fork, delete the deployment surface, and bend it to our architecture |
And one thing worth saying plainly: the fact that a well-funded team shipped this in 11 days and it is 103 + 50 files does not mean our design is wrong — it means their problem is smaller and better-bounded than ours. They have one executor harness set and a web UI. We have 11 named agents across three planes, an inter-plane protocol, and a cost model with two billing instruments.
Different problems. Overlapping parts. Take the parts.
9. Documents in this decision
| Doc | Author | Lane |
|---|---|---|
01-research/fork-moyai-assessment-2026-10-10.md | Sol | A2A / SDK / executor |
03-decisions/mira-fork-moyai-decision-paper.md | Mira | Cost / providers / dependency risk |
03-decisions/should-we-fork-moyai.md | Min | Registry / identity / tasks |
01-research/liteagents-and-moyai-study.md | Min | The original study |
All four are committed. The consensus is recorded.