I have spent a long time working in an XP/TDD style, so when AI coding tools became useful enough for real work, I adopted them quickly. The first bottleneck I hit was not code generation, it was verification: AI could write code and tests quickly, but I was still the person reviewing implementations, clicking through flows, checking logs, inspecting database state, and deciding whether the result was actually correct.
That pushed me to move validation further left. Before implementation, AI had to produce test plans. After implementation, it had to execute those plans too: drive the browser, inspect logs, check DB state, create tickets for failures, fix them, and retest until the output converged. Auth9 (https://github.com/c9r-io/auth9) became the proving ground for that method. Once it was clearly working, I started building Agent Orchestrator so the process would not depend on me manually supervising every step.
By mid-February, I was already using early Orchestrator-style automation inside Auth9. In mid-March, I used it during the highest-risk refactor so far: replacing the headless Keycloak setup with a native `auth9-oidc` engine. The core replacement landed over 3 days, and the same method and tooling helped converge the follow-up technical debt and complete the community OIDC Certification tests by the end of the month. That was the point where I became confident this was useful not only for greenfield work, but for governing high-risk change in a real system.
At the time, "orchestration" was the word I cared most about, which is why the project got its name. Later, OpenAI's Harness Engineering framing gave me a better name for the broader shape of the work. The project today is a local-first Rust control plane for long-running agent workflows: YAML resources, SQLite-backed task state, machine-readable CLI output, structured logs, and guardrails around shell-based agents.
That pushed me to move validation further left. Before implementation, AI had to produce test plans. After implementation, it had to execute those plans too: drive the browser, inspect logs, check DB state, create tickets for failures, fix them, and retest until the output converged. Auth9 (https://github.com/c9r-io/auth9) became the proving ground for that method. Once it was clearly working, I started building Agent Orchestrator so the process would not depend on me manually supervising every step.
By mid-February, I was already using early Orchestrator-style automation inside Auth9. In mid-March, I used it during the highest-risk refactor so far: replacing the headless Keycloak setup with a native `auth9-oidc` engine. The core replacement landed over 3 days, and the same method and tooling helped converge the follow-up technical debt and complete the community OIDC Certification tests by the end of the month. That was the point where I became confident this was useful not only for greenfield work, but for governing high-risk change in a real system.
At the time, "orchestration" was the word I cared most about, which is why the project got its name. Later, OpenAI's Harness Engineering framing gave me a better name for the broader shape of the work. The project today is a local-first Rust control plane for long-running agent workflows: YAML resources, SQLite-backed task state, machine-readable CLI output, structured logs, and guardrails around shell-based agents.
- GitHub: https://github.com/c9r-io/orchestrator - Docs: https://docs.c9r.io - Auth9: https://github.com/c9r-io/auth9 - Install: `brew install c9r-io/tap/orchestrator` or `cargo install orchestrator-cli orchestratord` - License: MIT