Back to browse
GitHub Repository

🐯Autonomous dev orchestration that never stops. Failures still converge to completion.

13 starsTypeScript

OpenTiger – Autonomous dev orchestration that never stops

by andyyyy64·Feb 22, 2026·11 points·2 comments

AI Analysis

●●SolidBig BrainShip ItSolve My Problem

Multi-agent dev orchestration with judge + recovery loop, but core value depends on agent quality upstream.

Strengths
  • Non-human-first design: explicitly built around assumption agents fail — architecture treats failure as a state transition, not a dead-end.
  • Role-based parallelism (planner, worker, tester, judge) prevents single-agent bottlenecks and distributes responsibility.
  • Recovery-first state machine with quota_wait, awaiting_judge, needs_rework transitions — handles real operational pain points.
Weaknesses
  • Entire value proposition depends on upstream agent quality — orchestration can't fix bad Claude output, only retry it.
  • Competes with existing agentic frameworks (Anthropic's built-in multi-turn, LangGraph, CrewAI) already shipping recovery patterns.
Target Audience

Teams running autonomous AI coding agents at scale, CI/CD engineers, AI orchestration builders

Similar To

LangGraph · CrewAI · Anthropic's multi-turn agent patterns

Post Description

Hi HN. I've been running AI coding agents (Claude Code, Codex, etc.) on real repos for a while now. The dirty secret of "autonomous coding" is that agents stop all the time — quota limits, test failures, policy violations, bad judgement calls. You end up babysitting them.

So I asked a different question: what if the system was designed around the assumption that agents WILL fail, and the job of the infrastructure is to never let that failure become a dead end?

openTiger is a "non-human-first" orchestration system that runs multiple AI agents in parallel — planner, workers, testers, judge — each with a dedicated role. The planner decomposes requirements into tasks, the dispatcher fans them out to worker agents concurrently, and the judge evaluates results and feeds back rework decisions. It's not one agent doing everything; it's a pipeline of specialized agents running simultaneously.

The entire architecture is built on one principle: no state is terminal. Every failure is a blocked state with a reason, and every reason has a recovery path. If the same failure repeats, the system escalates to a different strategy instead of retrying the same thing.

The interesting philosophical bit: optimizing for recovery turns out to be more effective than optimizing for first-attempt success. When you stop fearing failure, you can let agents be more aggressive.

Early stage, lots to improve. Feedback and contributions welcome.

Docs: https://opentiger.dev/docs/

Similar Projects

Developer Tools●●●Banger

OmoiOS–190K lines of Python to stop babysitting AI agents (Apache 2.0)

DAG-based agent swarms with spec generation from codebase beat prompt chaining, but long-term reliability unproven.

WizardryBold Bet
kanddle
223mo ago