Wix Engineering describes the architecture behind Wix Orchestrator, an internal multi-agent system that autonomously investigates support tickets and produces production-ready pull requests. The system uses four specialized agents (Detector, Enricher/Wix Octocode Research, Coder, Reviewer) coordinated by an orchestrator, with a human engineer always reviewing the final fix before it ships. The core insight is that context quality, not model choice, determines fix quality: the Enricher combines static code analysis (OctoCode), database queries (Trino), live logs (Grafana), and documentation into a structured plan for the Coder agent. Schema validation with retries cut inter-agent error rates from roughly 50% to under 1%. Open problems remain around ticket classification and capturing undocumented organizational/institutional knowledge that isn't visible in code or logs.
Table of contents
The Problem: A Pipeline Built for Humans, at Human SpeedThe Insight That Changed EverythingThe Architecture: Four Agents, One OrchestratorWhat Connects It AllThe Problem We Didn't See ComingHow We Developed the System Itself: Specification Driven DevelopmentWhat We Learned - and What Other Teams Should KnowQuestions this post answers
How does Wix's Orchestrator system automatically fix bugs from support tickets?
It uses four specialized agents coordinated by an orchestrator: a Detector that classifies incoming support tickets, an Enricher (Wix Octocode Research) that gathers static code context via OctoCode, live database state via Trino, and logs via Grafana, a Coder that implements the fix in an isolated container and opens a PR, and a Reviewer that independently evaluates the PR before a human approves it for production. Engineers building similar agent pipelines can find architecture deep dives like this through daily.dev.
Why do coding agents produce unreliable or malformed outputs when chained together in a multi-agent pipeline?
Because agents are non-deterministic and will occasionally return malformed output at handoff points between them. Adding schema validation at every handoff, combined with sending the error and original context back to the same agent for a retry, reduced the inter-agent error rate from roughly 50% down to under 1% in one production multi-agent bug-fixing system. Teams debugging flaky multi-agent pipelines can track patterns like schema validation and retries on daily.dev.
Why did an AI-generated bug fix PR get rejected by an engineering team even though the code was correct?
Because the fix ignored undocumented organizational context, such as a team being mid-migration to a new version and not wanting changes to the old one, a known third-party vendor issue already being tracked, or an old architectural decision made for reasons never written down. This institutional knowledge lives in Slack threads and people's memories rather than in code or documentation, making it invisible to automated systems. Anyone weighing how much to trust AI-generated fixes can follow real-world lessons like this on daily.dev.