For now, after taking a look at the ZYR3 side as well:
I think the architecture makes a lot more sense when the public pieces are separated into a few layers.
From what I can see, there is already a fairly concrete ZYR3.1 behavior/training specification: planning, decomposition, specialist delegation, progress tracking, failure recognition, verification, repair, replanning, final review, and completion judgment are all explicit targets. It even explicitly treats things like claiming that tests passed without verification, or claiming that code was executed when it was not, as unwanted behavior.
Then there is the current public ZYR3.1 orchestration runtime, which is still a relatively compact V1 path around routing, scheduling, specialist runs, ACN/ATP context collection, and final generation.
And separately, the main ZYR3 repository already has a zyr3 build agent that edits a real workspace, runs shell commands/tests, reads the actual output, and iterates on that feedback.
So one possible next milestone looks especially interesting to me: connect those ideas into one small, observable end-to-end run before making the example larger.
For example:
user task
↓
ATP creates/updates the plan
↓
MeO/router selects the needed specialist(s)
↓
specialist proposes/creates work
↓
real executor runs it in the workspace
↓
structured result comes back
↓
ATP sees actual success/failure
↓
Critic/Coder/etc. repair if needed
↓
real re-run
↓
verification
↓
ATP decides whether the task is actually complete
A single trace where the first test run genuinely fails, the failure is observed, the work is sent back, it is repaired, and the second real run passes would demonstrate a surprisingly large part of the idea behind:
plan → monitor → detect failures → replan → verify → send work back → keep going
without needing a huge benchmark first.
It would also make the boundary between the trained “team behavior” and the external runtime very clear. The current model card already makes this distinction helpfully: the team-chat style is trained behavior, while the MicroVM test counts shown in the showcase are currently simulated in model output rather than actual test executions.
Depending on what you want V1 to demonstrate first
I think there are several valid paths here, and they test different things.
If the main target is ATP / orchestration
The smallest useful demonstration is probably the end-to-end failure/recovery trace above.
The important part would not be how impressive the task is. A deliberately tiny repo with one reproducible failing test may actually be better, because then it is easy to see whether ATP is really doing the coordination:
PLAN
→ ASSIGN
→ EXECUTE
→ OBSERVE FAILURE
→ CLASSIFY / REVIEW
→ REPAIR
→ RE-EXECUTE
→ VERIFY
→ COMPLETE
For comparison, Microsoft’s Magentic-One uses a central orchestrator with task/progress tracking and replanning when progress stalls. I do not mean that ATP needs to copy Magentic-One, but its Task/Progress Ledger idea is a useful reference for making orchestration state observable rather than leaving it implicit inside generated text.
A lightweight ATP event log could already be enough:
TASK_CREATED
PLAN_UPDATED
AGENT_SELECTED
ACTION_REQUESTED
ACTION_RESULT
VERIFICATION_RESULT
FAILURE_DETECTED
REPAIR_REQUESTED
REPLAN_REQUESTED
TASK_COMPLETED
This does not need to expose chain-of-thought. State transitions, routing decisions, and external observations are enough to make the system understandable and debuggable.
If the main target is the trained ZYR3.1 behavior
Then I would keep the runtime fixed and compare the trained model against the corresponding base/default behavior.
That helps separate:
“the model learned better orchestration behavior”
from:
“the surrounding runtime made the task easier.”
Even a small task set could be informative if the same tools, executor, limits, and completion criteria are used.
Useful things to look for would be whether the trained version is better at:
- decomposing the task,
- waiting for verification before completion,
- reacting correctly to failed verification,
- selecting a repair step instead of restarting,
- avoiding premature “done” states.
If the main target is MeO routing
I would treat this as a separate question from whether the model learned the behavioral language of orchestration.
The behavior specification clearly says specialist delegation and orchestration behavior are training targets. What I cannot tell from the public material yet is whether the routing policy itself is independently learned, with its own routing objective/data/reward, or whether “learned MeO” mainly refers to orchestration behavior learned by the model.
If routing itself is learned, a very clean comparison would be:
fixed specialist chain
vs.
simple heuristic routing
vs.
learned MeO routing
with the same underlying model and execution environment.
That would answer a much more interesting question than “does multi-agent beat single-agent?”: does dynamic specialist selection improve success or efficiency enough to justify the coordination?
This matters because more agents are not automatically better. Anthropic’s write-up on its multi-agent research system is useful here: multi-agent execution worked especially well for highly parallelizable research, but it also consumed much more computation/tokens, and tasks with tightly shared context or dependencies are harder to parallelize cleanly.
So for MeO, “which specialists should not run?” may be just as valuable a decision as “which specialists should run?”
If the main target is MicroVM execution
Then I would make the executor’s observation the source of truth.
Conceptually:
agent says "I fixed it"
↓
not sufficient
executor returns exit code / files / test result
↓
ATP receives structured observation
↓
verifier checks required outcome
↓
only then can completion become true
OpenHands’ runtime architecture is a useful implementation reference for this boundary: actions go into a sandboxed runtime and observations come back to the agent/backend.
The exact implementation does not have to look like OpenHands. The useful idea is the contract:
Action -> external environment -> Observation
rather than:
model-generated description of an action -> model-generated description of success
Since the separate ZYR3 build agent already works from real command/test output, there may already be a useful execution component to build on if these projects are intended to converge.
If the main target is UltraDeep / long-horizon work
I would separate context length from durable task state.
They help with different problems:
LLM context
what the model can currently see
task/progress state
what has been completed and what remains
workspace state
files, artifacts, environment
memory
useful lessons/facts retained across stages
checkpoint
enough durable state to resume after interruption
A 512K or 1M context can be useful, but by itself it does not guarantee reliable multi-hour execution.
A very small long-horizon test could instead be:
start task
→ complete several steps
→ interrupt/restart the worker
→ restore task state
→ do not repeat completed side effects
→ continue from the correct point
→ externally verify the final artifact
That tests the runtime property directly without requiring a million-token workload.
LangGraph’s persistence/checkpoint model is one useful reference for the distinction between thread-scoped execution checkpoints and longer-lived stored information.
And there is a general systems issue here: once an agent can retry real actions, retries are not always harmless. Re-running a read is usually fine; re-running a file write, API POST, payment, deployment, message send, etc. may produce duplicate side effects. So eventually it may help for ATP to distinguish things such as:
logical task failure
transient tool failure
infrastructure failure
verification failure
irreversible / externally visible action
That probably matters much later than V1, but UltraDeep makes this distinction increasingly important.
Verification seems especially important for this architecture
The verification part of the ZYR3.1 behavior specification caught my attention because it already points in a good direction.
For an execution-oriented agent, these are different states:
agent says "done"
!=
command returned successfully
!=
required artifact exists
!=
artifact passed verification
!=
whole task is complete
One potentially useful ATP completion contract could eventually be something like:
required subtasks complete
AND required artifacts exist
AND required external checks pass
AND no blocking failure remains
AND final review is complete
The exact rules will obviously vary by task.
A particularly relevant project here is Long-Horizon Terminal-Bench (LHTB). For tasks configured for continued execution, the agent does not automatically win because it decides to stop. A hidden verifier checks the result, and if verification fails the same session can be resumed with feedback so it can continue working.
Its GitHub repository also documents an interesting practical failure mode: verifier artifacts initially had to be isolated more carefully because agents could sometimes inspect information belonging to the grader.
That is a useful future lesson for a MicroVM design:
execution isolation and verifier isolation are related, but not identical trust boundaries.
If ATP is eventually using verification as the authority for completion, it is worth keeping the verifier’s hidden state separate from anything the working agents can inspect.
A small evaluation ladder before a large benchmark
I would probably evaluate this in layers rather than immediately trying to prove the whole architecture on one large benchmark.
Something like:
1. Deterministic orchestration test
No expensive model needed.
Check routing/state/event contracts.
2. One real failure -> repair -> success trace
Check the complete execution feedback loop.
3. Fixed routing vs dynamic routing
Same model, same executor, same task.
4. Base/default model vs ZYR3.1-trained behavior
Same orchestration environment.
5. If routing itself is learned:
heuristic routing vs learned routing.
6. Small repeatable task set
Measure reliability and cost together.
7. Larger coding / long-horizon benchmarks
Once the earlier layers are understood.
Even at the small-task stage, I would not look only at final success rate.
A few inexpensive measurements can reveal quite different failure modes:
task success
premature termination
recovery after a real failure
number of retries
model turns
tool/executor calls
specialists activated
tokens
wall-clock time
Not every metric is necessary. The useful ones are whichever help distinguish “better model behavior” from “better routing” from “more compute” from “better external verification.”
The paper Why Do Multi-Agent LLM Systems Fail? is useful as a failure-analysis reference here. It groups observed multi-agent failures into specification/system-design failures, inter-agent misalignment, and verification/termination failures. I would not read that as an argument against multi-agent systems; it is more useful as a checklist for deciding what to log when an orchestration run fails.
One more reason I like the 'single real trace' milestone
A full architecture like ATP + ACN + MeO + specialists + MicroVM + UltraDeep has many moving pieces.
If a large benchmark improves, it can be difficult to tell why:
Was it the trained model?
Was it extra model calls?
Was it specialist diversity?
Was it routing?
Was it the external executor?
Was it retry?
Was it verification?
Was it simply more context?
A tiny controlled trace makes the data flow visible first.
And the nice thing here is that the ZYR projects seem to already contain pieces on both sides of that boundary:
So if those lines are intended to converge, connecting them may provide more information than adding another specialist immediately.
And if they are not intended to converge, that is fine too: the same separation makes it easier to say exactly which layer ZYR3.1 V1 is trying to advance.
So my default path would be fairly small:
one real, externally verified failure-and-recovery trace first; then choose the next experiment based on which layer you actually want to demonstrate.
That would already make ATP, ACN, MeO, the specialists, and the execution layer much easier for other people to understand and evaluate — while still leaving plenty of room to grow into the larger UltraDeep / long-horizon vision later.
ZYR3.1 IS JUST GETTING STARTED. 
ZYR3.1
ATP — the Main Control Center
ACN — the Agent Communication Network
MeO + 10 specialized agents
Long-horizon coding & task execution
Isolated MicroVM execution & verification
UltraDeep mode for serious multi-step work
512K → 1M context vision
ZYR3.1 — built by ZYR.