Designing a Multi-Agent System for Engineering Support at Scale: A Case Study From Grab

Leela Kumili · rss · 2026-05 source ↗ Reader 🖥️

Agent Tool Management Context Engineering Human-in-the-Loop Multi-Agent Orchestration

Partitioning a multi-agent engineering-support system into investigation vs. enhancement workflows, with a curated tool layer, a LangGraph supervisor, and mandatory human-in-the-loop review for code changes, yields enough reliability to reclaim engineering hours at production scale.

practical · expository — InfoQ news write-up of a case study; reports on Grab's architecture and implicitly argues for a particular pattern (workflow partition + tool consolidation + HITL) as the right way to build internal-support multi-agent systems.

Structure

Part	Role
Framing: ADW scale (1,000 users, 15,000 tables) and the operational-toil problem	context / motivation
Sneh Agrawal quote about reclaiming 'hundreds of engineering hours each month'	appeal to authority / outcome claim (unquantified beyond 'hundreds')
Architecture description: investigation vs. enhancement workflow split	central design claim
Orchestration stack: LangGraph + FastAPI + Supervisor pattern	evidence of concrete implementation
Tool consolidation from 30+ tools to a curated set	lesson learned / corrective evidence
Safety: SQL validation, sensitive-data detection, HITL for code changes	governance argument
Context-management challenge and structured compression solution	acknowledgement of difficulty / partial answer
Closing impact statement: 'shift from firefighting to building' but 'exact metrics not disclosed'	conclusion / hedged outcome

Key terms

investigation workflow
Read-only diagnostic agent path: query analysis, log retrieval, schema lookup, issue summarization. No side effects.
enhancement workflow
Write-path agent flow that produces code changes, SQL fixes, and merge requests, all gated by human review.
Supervisor Multi-Agent Orchestration
A LangGraph orchestration node that classifies incoming requests, routes them to specialized agents, and controls inter-agent communication and task delegation. Implementation-specific (LangGraph supervisor pattern), not a generic notion.
constrained responsibilities
Each agent has a narrow, fixed task scope (context retrieval, code search, solution generation) and a curated tool subset, intended to reduce ambiguity in reasoning and tool selection.
tool consolidation Agent Tool Management
Deliberate reduction from 30+ exposed internal tools to a smaller curated set, because too many tools caused unpredictable selection by agents.
structured context compression Context Engineering
Combination of selective retrieval and compression of intermediate state so multi-step agent reasoning fits within token budgets.
human-in-the-loop Human-in-the-Loop
Mandatory engineering review of any agent-produced code change before deployment; not optional, not advisory.

Propositions

explicitcorroboratedSplitting agent workflows by read-only diagnosis vs. write-path enhancement reduces reasoning complexity and improves production reliability.conf: high
supports ←Project Glasswing: what Mythos showed us · p10 — Both independently find that splitting one hard question across separate specialized agents (buggy-vs-reachable; diagnose-vs-write) produces better reasoning than asking it whole.
explicitExposing many tools (30+) to agents causes unpredictable tool selection; curating a smaller toolset improves maintainability.conf: high
supportsAgent Harness Engineering · p8 — Grab's production finding that 30+ exposed tools cause unpredictable selection independently confirms that a small curated toolset outperforms many overlapping ones.
explicitAgent reliability at scale requires constraining each agent's responsibilities to a narrow domain.conf: high
refinesHenrik Kniberg's Post · p2 — Grab grounds Kniberg's role-specialization value claim in a harder condition: at production scale, narrow per-agent domains are required for reliability, not just preferable.
explicitAny agent-produced code change must pass human review before deployment.conf: high
explicitcorroboratedContext management — keeping relevant state across multi-step agent reasoning within token limits — is the dominant technical challenge for systems like this.conf: high
supports ←Presentation: The Multi-Agent Approach: Building Reliable and Controllable Software Development Automation · p8 — Both name context management/retrieval as the dominant technical challenge for multi-agent systems; Friedman elaborates it as an agentic context engine.
implicitA LangGraph supervisor-routed workflow with FastAPI services is a viable orchestration baseline for internal multi-agent support systems.conf: medium
implicitRepetitive operational support tasks are the right place to apply multi-agent systems first (rather than novel/creative engineering work).conf: high
implicitQualitative outcomes ('shift from firefighting to building') are sufficient to declare success even when exact metrics are not disclosed.conf: high
implicitWhat distinguishes an 'agent' from an automation script here is (a) LLM-driven task classification/routing by a supervisor and (b) constrained tool use over shared state — not autonomy, learning, or initiative.conf: medium

Arguments

A two-workflow partition (investigation vs. enhancement) is the right primary decomposition for engineering-support multi-agent systems. strength: medium

Explicit premises:

Mixing diagnostic and write-path reasoning increases agent ambiguity.
Separation 'reduced complexity in agent reasoning and improved reliability'.

Implicit premises:

Read-only and write-path tasks have different risk profiles and so warrant different control regimes (HITL only on write).
Most engineering-support requests cleanly fall into one of the two categories.
The cost of misclassification at the boundary is acceptable (or handled by the supervisor).

Inferences:

If the same partition holds elsewhere, it suggests a general design rule: separate observability/diagnosis agents from change-producing agents in any internal-tooling multi-agent system.

Tool surface area should be minimized and curated, not maximized. strength: high

Explicit premises:

Initially the system exposed 30+ tools.
This produced unpredictable tool selection.
Reducing to a curated set improved maintainability.

Implicit premises:

Current LLM agents do not select among many similar tools reliably.
Maintainability of the tool layer is a primary cost driver.
The marginal value of additional tools is lower than the marginal cost of agent confusion they introduce.

Inferences:

MCP-style 'expose everything' strategies may be counterproductive for production agent systems until tool-selection reliability improves.

The system delivers meaningful productivity gains. strength: low

Explicit premises:

Sneh Agrawal: 'reclaiming hundreds of engineering hours each month'.
The team reports reduced time on routine support and faster resolution cycles.

Implicit premises:

The baseline against which 'hundreds of hours' is measured is known and credible.
Hours reclaimed are net of time spent building, maintaining, and reviewing the agent system itself.
Engineers reallocated their time to higher-value work rather than to other forms of overhead.

Inferences:

Without disclosed metrics (resolution time deltas, accuracy, cost-per-resolution, false-positive rates), 'hundreds of hours' is a vendor-style claim, not an evaluation.

Human-in-the-loop is a sufficient safety mechanism for code-changing agents. strength: medium

Explicit premises:

All enhancement workflows require human review before deployment.
SQL execution is validated; sensitive-data exposure is mitigated.

Implicit premises:

Reviewers will actually catch agent errors at the rates required (rather than rubber-stamping).
The review burden does not erase the productivity gain.
There is no automation-bias problem with engineers reviewing plausibly-formatted MRs.

Inferences:

If review fatigue or automation bias degrade over time, the safety story collapses without a fallback.

Narratives

Grab's ADW team went from being consumed by repetitive support across 1,000 users and 15,000 tables to reclaiming engineering bandwidth via the multi-agent system — framed as 'firefighting to building'.
→ Implicitly supports the proposition that multi-agent systems are the right tool for operational toil at platform scale.
Tool-explosion regret: starting with 30+ tools, observing unpredictable agent behavior, then curating down.
→ Supports the argument that small tool surfaces beat large ones for current-generation agents; this is the article's most useful war story.

Questions addressed

✅ How should you decompose a multi-agent system for internal engineering support?
Split by read-only investigation vs. write-path enhancement, route via a LangGraph supervisor, give each agent a constrained role and tool subset.
✅ How should agent tool surfaces be sized?
Start small; expect to consolidate; expect tool-explosion to hurt agent decision quality.
⭕ How do you keep multi-step agent reasoning within token limits?
Named as 'structured context compression and selective retrieval' but not described in any actionable detail.
⭕ What measurable outcomes does this system produce?
'Hundreds of engineering hours' is asserted; 'exact performance metrics were not disclosed'.
⭕ What exactly is an 'agent' in this system, vs. a function call wrapped in an LLM?
Never defined. Operationally, agents here are LLM-mediated routers and tool-callers under a supervisor — closer to constrained pipelines than to autonomous agents.
⭕ How is misclassification at the investigation/enhancement boundary handled?
Not addressed.

Gaps

incompleteNo measurable outcomes. 'Hundreds of hours/month' is unanchored to a baseline, a denominator, an accuracy figure, or a cost. There is no comparison to a non-agentic automation alternative (scripts, RAG-only chatbot, runbook automation).
Read next: Look for the original Grab Tech Blog post (engineering.grab.com/from-firefighting-to-building) for the actual numbers; if absent there too, this is a marketing artifact, not an engineering report. Compare to DORA-style AI productivity measurement methodology.
incompleteThe article never offers a metric or boundary that distinguishes 'agent' from 'automation script'. The architecture as described (classify -> route -> tool-call under a supervisor, with constrained responsibilities and HITL on writes) is mostly compatible with a deterministic workflow engine plus LLM classifiers.
Read next: Anthropic's 'Building effective agents' (Schluntz & Carr) on workflows vs. agents; Simon Willison on the agent-definition problem; HumanLayer / Vercel's agent taxonomy work.
incompleteThe supervisor's actual role is described abstractly ('controls communication flow and task delegation') but not behaviorally. Does it re-plan on failure? Loop? Spawn new agents? Without that, the 'multi-agent' label may be doing rhetorical work the architecture does not earn.
Read next: LangGraph supervisor docs and Cognition AI's 'Don't Build Multi-Agents' essay arguing most 'multi-agent' systems are sequential pipelines mislabeled.
incompleteNo discussion of failure modes: hallucinated SQL passing validation, MRs that look correct but introduce regressions, automation bias in reviewers, drift as the platform changes under the agents' indexed context.
Read next: Literature on automation bias in code review; Google's 'AI in software engineering' DORA findings on review burden.
incompleteContext management is named as the hardest problem and dispensed with in one sentence. 'Structured context compression and selective retrieval' is not described as a technique.
Read next: The original Grab post; Anthropic's context-engineering write-ups; recent work on agent memory architectures (e.g., MemGPT-style hierarchies).
uninformedAuthor writes about Grab's system at a level entirely derivable from the company blog and a LinkedIn post; there is no independent reporting, no quote that wasn't already public, no comparison to other companies' similar systems.
Read next: Go to the primary source. Compare to Uber, Shopify, Stripe internal-tooling agent write-ups for triangulation.

Designing a Multi-Agent System for Engineering Support at Scale: A Case Study From Grab

Structure

Key terms

Propositions

Arguments

Narratives

Questions addressed

Gaps

Related documents