Repository navigation
Failure modes I kept hitting with supervised Orca workers — and the skill that names the counters #29082
whutlichao
started this conversation in
General
Replies: 2 comments
|
Follow-up note: the supervised / Agent Skills framing in this write-up was inspired by Matt Pocock’s ideas on that topic (mattpocock/skills); orchestra-auto is my port of those process judgements onto Orca’s |
0 replies
|
With ack deferred until the whole batch is handled, how do you recover if an action finishes but the process dies before durably recording completion? The batch is still unacknowledged, but that action has already happened. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Dispatch is the easy part. The hard part of supervised multi-agent work on a real repo is the last 20%. Here are failure modes I kept hitting with Orca orchestration — and the counters I finally wrote down.
main— a new terminal is not a new top-level worktree--worktree new-top-levelper ticket; coordinator never edits or commits in a worker worktree or on the main working copystate: ready≠ turn started — the receipt only means the bytes were writtenturnStart: observed) before waiting; if it did not start, recover — do not resend the whole promptI published that procedure as two installable Agent Skills (English + 简体中文, same semantics). Orca-specific — they drive
orca orchestration …and are not a general orchestration framework.The entrypoint keeps the routing table and hard rules; dispatch-loop / reply-protocol detail lives under
references/and loads on demand (less always-on activation context — no A/B claims).Repo: https://github.com/whutlichao/orchestra-auto
Happy to be corrected on any of the rules — I'd rather fix the procedure than keep rediscovering the same failures.
All reactions