Feedback & First Impressions — Tell us what you think!

[oxgeneral]

👋 Welcome!

We'd love to hear from you — whether you're just trying ORCH for the first time or already running multi-agent workflows in production.

Share your experience

• What works well? What do you like about ORCH?
• What's frustrating? Anything confusing, slow, or broken?
• What's missing? Features you wish existed?
• Your setup — which agents do you use? (Claude, Codex, Cursor, shell?) How many agents in parallel?

Quick feedback template (optional)

Setup: [e.g. 3 Claude agents + 1 shell script]
Using for: [e.g. refactoring a monorepo, building features, CI automation]
Best part: ...
Worst part: ...
Wish it had: ...

Every comment helps us prioritize what to build next. No feedback is too small — even "it just works" or "the TUI crashed after 10 min" is useful.

Thanks for being an early adopter! ⭐

[usefulpeople]

Today I tested ORCH on a real task — building a full-stack service with a user-facing app and an admin panel. For context:

1. I'm not a developer, I'm a product person
2. All I can do is describe customer journey maps, which Claude Code then translates into architecture

I fed that architecture into ORCH. Together with Claude Code, we assembled a team of agents based on the required tech stack. A couple of shamanic drum beats and the magic machine started working.

The team ended up with 8 agents: CTO, Python Backend, Svelte Frontend, Bot Developer, DevOps, QA, Reviewer, and a CEO on top. They completed 87 runs across 86 tasks — all succeeded, zero failures. Wall-clock time: ~4 hours, while total agent-time was 7.5 hours (~2x parallelism). The whole thing cost about $31 in tokens.

The CTO agent consumed the most resources (28% of tokens) — it was constantly monitoring progress and spawning new tasks. QA came in second with 252K tokens across 11 test tasks. The Reviewer did 13 code reviews. Even the DevOps agent showed up, set up Docker Compose, and went quiet — just like in real life.

Overall, it felt like actually dispatching a task to a real dev team — things happen in the background, and then you get a nearly working solution. As Dario said, a country of geniuses in a data center — except here it's a dev team in your terminal. Fully autonomous, only needed a bit of polishing at the end with Claude Code.

I really enjoyed it. It also made me think that the team composition can be anything — content factory, research pipeline, you name it. Highly recommend giving it a try.

[ofekron]

Architecture feedback rather than a hands-on review: I use Claude, Codex, and Gemini with one coordinator and usually two to four bounded workers.

The task queue, dependency scheduling, worktrees, QA, and reviewer roles are the right primitives. The feature I would want before trusting a “set a goal and sleep” workflow is a durable execution model that distinguishes:

• agent process exited;
• task produced an artifact;
• verifier checked the artifact;
• review passed;
• change is safe to merge;
• goal-level acceptance criteria are satisfied.

Those should not collapse into one DONE state. The 87/87 run report in this thread is impressive, but “all subprocesses succeeded” and “the product requirement is correct” are different measurements.

I would also test daemon restart during every boundary: before dispatch, mid-tool call, after a side effect but before acknowledgement, after result persistence, and before downstream scheduling. Recovery needs idempotency keys and side-effect receipts so a restart cannot silently repeat a push, deployment, or paid API call.

For the TUI, make waiting for approval, blocked dependency, retrying, stale heartbeat, partial failure, and verified completion visually distinct. Zero-human operation makes truthful state more important, not less.

Maintainer disclosure: this perspective comes from Better Agent, a related local web workspace I’m building for supervising persistent Claude, Codex, Gemini, and other coding-agent sessions: https://github.com/ofekron/better-agent

It is source-available and free for non-commercial use; commercial use requires separate permission. I have not run ORCH yet; restart/recovery and completion semantics are the first areas I would exercise.