Orchestrating Multi-Agent Code Review Systems with Improved Observability and Reliability

cubic · Tech · 2026 · source Agentic: yes · promotional bias: high · source-backed · extracted with prompt 0.5.6 (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: AI code-review agent reliability and observability

Cubic needed to move an AI code-review product from proof of concept to production while reducing unexplained failures, false positives, serverless timeout issues, and weak observability across multi-step agent runs.

Constraints:

• The product integrates with GitHub pull requests and must support large customer codebases.
• The initial multi-step agentic system could fail or get stuck without clear explanations.
• Manual trace IDs and grep-based log searching were not enough for production debugging.
• Serverless execution introduced timeouts for long-running multi-step work.
• The code-review output needed fewer low-value comments and false positives.

Architecture

Cubic adopted Inngest as an orchestration and observability layer for its AI code-review agents. The architecture moved from a single do-everything agent to specialized planner, security, duplication, and filtering agents connected through step APIs, parallel execution, event-driven triggers, idempotency, timeout callbacks, and flow control. Inngest traces give run-level and step-level inspection across local and production environments, while agents pull context through tools connected to APIs and sandboxes instead of receiving all context upfront.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  GitHub_pull_request["GitHub pull request"] --> Inngest_event_orchestration["Inngest event orchestration"]
  Inngest_event_orchestration --> Planner_agent["Planner agent"]
  Planner_agent --> Security_agent["Security agent"]
  Planner_agent --> Duplication_agent["Duplication agent"]
  Planner_agent --> Filtering_agent["Filtering agent"]
  Security_agent --> Filtering_agent
  Duplication_agent --> Filtering_agent
  Filtering_agent --> GitHub_pull_request
  Security_agent --> Context_pulling_tools["Context-pulling tools"]
  Duplication_agent --> Context_pulling_tools
  Context_pulling_tools --> Third_party_APIs["Third-party APIs"]
  Context_pulling_tools --> Secure_sandbox_environment["Secure sandbox environment"]
  Flow_control["Flow control"] --> Context_pulling_tools
  Inngest_event_orchestration --> Run_search["Run search"]
  Run_search --> Trace_view["Trace view"]
  Inngest_event_orchestration --> Trace_view

Components

Data flow

A GitHub pull request triggers Inngest-orchestrated agent runs. A planner assesses the change, specialized security and duplication agents inspect relevant concerns, a filtering agent validates issues to reduce false positives, and traces record steps, outputs, and actions so the team can debug behavior by pull request, customer, token usage, or function.

Why this architecture

The single-agent proof of concept lacked observability and produced noisy comments. Inngest gave Cubic managed async orchestration, retries, traces, parallel steps, idempotency, timeout handling, and flow control, while specialized agents separated planning, security, duplication, and filtering responsibilities.

Models used: AI Agents · Large Language Models

Scale

• Cubic customers include Granola, n8n, and Browser Use.
  “helping teams at Granola, n8n, and Browser Use merge Pull Requests 4x faster.”article, stated
• The product claims customer pull requests merge 4x faster.
  “helping teams at Granola, n8n, and Browser Use merge Pull Requests 4x faster.”article, stated
• The multi-agent redesign reportedly reduced false positives by 51%.
  “transitioning from a single-agent system to a multi-agent system, which resulted in a 51% reduction in false positives.”article, stated

Alternatives considered (roads not taken)

Manual trace IDs and grep-based log search

Rejected because: That approach made multi-step agent runs hard to inspect compared with searchable traces.

Single do-everything agent

Rejected because: The monolithic agent produced low-value comments, nitpicks, and false positives.

Push all context into agent prompts upfront

Rejected because: Cubic moved to context-pulling so agents retrieve context on demand through tools.

Uncoordinated parallel agent/tool execution

Rejected because: Parallel agents introduced race conditions and external constraints that required idempotency, timeouts, and flow control.

Patterns

multi-agent-orchestration (orchestration)

Cubic split one broad code-review agent into planner, security, duplication, and filtering agents connected by Inngest steps and events.

observability-tracing (operations)

Inngest replaced manual trace tagging with run search and step-level traces for agent executions.

async-message-orchestration (orchestration)

Agents are connected through event-driven architecture and triggered from pull-request-related events.

tool-use-orchestration (orchestration)

The system moved from pushing context into prompts to letting agents pull needed context through tools backed by APIs and sandbox environments.

agent-memory (state)

Cubic's GitHub integration builds long-term memory of codebase patterns over time.

eval-driven-development (quality)

The filtering agent confirms issues found by other agents to reduce false positives before comments reach pull requests.

Tradeoffs

Use a managed orchestration layer for agent workflows.

Chose Inngest step APIs, events, retries, and traces over Custom serverless queues plus manual logs.

Rationale: Cubic needed serverless timeout handling, long-running multi-step orchestration, observability, and a smooth integration path.

Specialize the code-review agents.

Chose Planner, security, duplication, and filtering agents over A single do-everything review agent.

Rationale: Specialization lowered false positives and gave each agent a focused review responsibility.

Switch from context-pushing to context-pulling.

Chose Tool-based on-demand context retrieval over Providing a lot of context to agents upfront.

Rationale: Tool use lets agents retrieve only what they need, but requires reliable API and sandbox orchestration.

Gotchas (what bit them)

The early agentic system failed or got stuck without clear explanations.

Root cause: Large codebases exposed edge cases, and limited observability made diagnosis difficult.

Resolution: Adopt structured orchestration with fine-grained traces and searchable metadata.

Manual logging did not scale to nested multi-agent workflows.

Root cause: Trace IDs plus grep did not expose steps and sub-steps triggered by each event.

Resolution: Use Inngest run search and trace views for agent runs, steps, outputs, and actions.

The monolithic review agent generated noisy low-value feedback.

Root cause: One broad agent handled too many review responsibilities and produced nitpicks and false positives.

Resolution: Split responsibilities across planner, security, duplication, and filtering agents.

Parallel agents created consistency risks.

Root cause: Multiple agents could race while updating or acting on shared resources.

Resolution: Use idempotency features in the orchestration layer.

External tool dependencies introduced reliability constraints.

Root cause: Tools called third-party APIs and sandboxes with provisioning and rate-limit constraints.

Resolution: Use flow-control features for rate limits, debouncing, and task priority.

Evaluation

Cubic evaluated production behavior through false-positive reduction, pull-request merge speed, trace inspection, customer/PR-specific run search, and iterative debugging of flawed reasoning patterns in agent traces.

Metrics: 51% reduction in false positives after moving to multi-agent architecture · 4x faster pull-request merges for named customer teams · Runs searchable by pull request, customer, custom metadata, and token usage · Trace inspection of steps, outputs, and actions

Outcomes

• Cubic moved from a proof-of-concept to a production-ready multi-agent code-review system.
• The multi-agent redesign reportedly reduced false positives by 51%.
• Customer teams are reported to merge pull requests 4x faster.
• The team gained run-level and step-level traces for debugging agent behavior.
• Flow control improved reliability for tools that call APIs and sandboxes.

The source is an Inngest customer story, so reported improvements should be treated as vendor-framed claims, but it provides concrete architecture and operations details.