Autonomous Self-Healing System for Bug Resolution

wix · Tech · 2026 · source Agentic: yes · promotional bias: med · summary-only (no fetched source) · extracted with prompt 0.5.4 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Autonomous software maintenance and support-ticket resolution

Wix needed to reduce long support-ticket resolution cycles by turning user-reported bugs into production-ready pull requests while still keeping human engineers in the final deployment loop.

Constraints:

• the source transcript was unavailable, so this extraction is summary-only
• traditional support-to-R&D flow averaged 14 days and could stretch to months
• the target was under 24 hours while preserving human deployment decisions
• classification is hard when bugs have no explicit server error or log signature
• organizational knowledge often lives in team memory, drives, emails, or undocumented migration context

Architecture

Wix built Gandalf as a four-agent self-healing system. A Detector pulls and classifies support tickets, Bilbo the Enricher gathers static and live context from code, databases, logs, and documentation, a Coder executes a plan in a Docker/GitLab environment and opens a pull request, and an independent Reviewer checks whether the pull request solves the original ticket without unacceptable risk. Schema validation, retries, idempotency checks, UI monitoring, and future team-specific knowledge agents make the system operational rather than a one-shot coding demo.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  support-tickets[Support tickets] --> detector[Detector]
  detector --> bilbo-enricher[Bilbo Enricher]
  bilbo-enricher --> octo-code[Octo Code]
  bilbo-enricher --> trino[Trino]
  bilbo-enricher --> grafana[Grafana]
  bilbo-enricher --> documentation[Documentation]
  documentation --> team-knowledge-agents[Team knowledge agents]
  team-knowledge-agents --> bilbo-enricher
  bilbo-enricher --> coder[Coder]
  coder --> schema-validator[Schema validator]
  schema-validator --> coder
  coder --> pull-request[Pull request]
  pull-request --> reviewer[Reviewer]
  reviewer --> human-engineer[Human engineer]
  support-tickets --> monitoring-ui[Monitoring UI]
  monitoring-ui --> human-engineer

Components

Data flow

Tickets enter through cron or manual triggers, then the Detector chooses and classifies solvable issues. The Enricher collects context through Octo Code, Trino, Grafana, and documentation systems, produces a plan, and passes it to the Coder. The Coder creates code in a sandboxed Docker pipeline and opens a GitLab pull request. The Reviewer independently evaluates the PR and either marks it ready for human review or flags risk, while the UI exposes states and blocked cases.

Why this architecture

Wix separated detection, enrichment, coding, and review because the system's bottleneck is context quality and because independent review is a necessary check on autonomous fixes. Existing infrastructure integrations make the workflow practical inside Wix, while schema validation and retries compensate for nondeterministic agent outputs.

Models used: Gandalf · Detector agent · Bilbo Enricher agent · Coder agent · Reviewer agent · frontier models for spec generation

Scale

• The original support workflow averaged 14 days in reasonable cases.
  “This process averaged 14 days in reasonable cases, but could extend to months for complex issues. The ambitious target was to reduce this to under 24 hours, with the caveat that final deployment decisions remain with human engineers who still need time to review the proposed fixes.”summary, stated
• The target resolution time was under 24 hours.
  “The ambitious target was to reduce this to under 24 hours, with the caveat that final deployment decisions remain with human engineers who still need time to review the proposed fixes.”summary, stated
• The system serves a company context with millions of users.
  “With millions of Wix users, the traditional flow involved users opening tickets, support engineers reviewing them days later, attempting to reproduce issues, initiating conversations with customers, opening Jira tickets for R&D, and then R&D teams prioritizing and implementing fixes.”summary, stated
• The workflow can poll for tickets every 30 minutes.
  “The sequence begins with a trigger, either a cron job checking for new tickets every 30 minutes or manual initiation by engineers.”summary, stated
• Schema validation and retries reduced inter-agent error rates from about 50% to 1%.
  “This approach reduced inter-agent error rates from approximately 50% down to 1%”summary, stated

Alternatives considered (roads not taken)

Optimize around model choice or agent cleverness first

Rejected because: Wix found context quality to be the key determinant of whether bugs become solvable.

Use one agent for detection, enrichment, coding, and review

Rejected because: Focused roles and independent review provide better attention, checks, and balances.

Deploy fixes without human review

Rejected because: Final deployment decisions remain with engineers because generated fixes can carry business or security risk.

Force all teams into a standardized documentation model

Rejected because: Wix is pursuing team-owned agents behind a protocol because knowledge formats vary by team.

Patterns

multi-agent-orchestration (architecture)

Gandalf decomposes the workflow into Detector, Enricher, Coder, and Reviewer agents with explicit handoffs.

tool-use-orchestration (integration)

The Enricher gathers context through GitLab search, database access, logs, and documentation tools.

structured-output-contract (reliability)

Each agent output is validated against a schema and retried with error feedback when malformed.

human-in-the-loop-gate (governance)

Generated pull requests still wait for human engineering review and deployment judgment.

agent-memory (memory)

The planned Historian agent records bug-fix history so future issues can retrieve organizational precedent.

Tradeoffs

Make context enrichment the core of the system

Chose deep context gathering before code generation over asking a coding agent to infer fixes from the ticket alone.

Rationale: Wix argues most bugs become easy once the relevant static and live context is accurate.

Use an independent Reviewer agent

Chose separate review from generation over embedding review instructions into the Coder.

Rationale: The Reviewer is less biased by prior reasoning and can focus on ticket fit, security, and risk.

Keep final deployment human-governed

Chose automated PR creation with human review over fully autonomous deployment.

Rationale: Some changes touch high-risk areas and engineers need to judge unintended consequences.

Gotchas (what bit them)

Ticket classification remains hard for bugs without explicit failures.

Root cause: Some bugs show up as missing or wrong business behavior rather than server errors or clear log signatures.

Resolution: Wix keeps classification as an acknowledged open problem and still routes unsolved cases to humans.

Organizational context can invalidate an otherwise plausible code fix.

Root cause: Teams know about migrations, vendors, old services, and historical design choices that are not accessible to the agent.

Resolution: Wix is building CDK/organization-brain capabilities and protocol-connected team agents.

Nondeterministic agent outputs break inter-agent handoffs.

Root cause: Agents do not always return data in the expected formats.

Resolution: Stage outputs are schema-validated and failed formats are retried with explicit error feedback.

Duplicate fixes can be generated for already-addressed bugs.

Root cause: Code may contain a pending fix that has not yet deployed.

Resolution: The system runs idempotency checks before creating redundant solutions.

Evaluation

Wix evaluates Gandalf through schema validation, retry/error-rate tracking, reviewer verdicts on generated PRs, idempotency checks, UI state visibility, and continued human review of PR readiness and risk.

Metrics: 14-day baseline resolution time · under-24-hour target · approximately 50% to 1% inter-agent error-rate reduction · 30-minute cron trigger cadence · PR ready vs blocked/review-risk states

Outcomes

• Gandalf can generate pull requests from support tickets and route them through normal human review.
• Schema validation and retries made inter-agent handoffs much more reliable.
• The team identified classification and organizational knowledge as the two main remaining blockers to fuller autonomy.
• The architecture is reusable beyond bug fixing because each microservice/agent can support other asynchronous tasks.

Summary-only: the case reports millions of users, 14-day baseline resolution times, an under-24-hour target, 30-minute ticket polling, and a 50% to 1% handoff-error improvement, but the original transcript was unavailable.