Grab has standardized more than 500 internal agent services on LLM-Kit, an internal framework of scaffolding and integrations that hands a new service a basic agent loop plus evaluation, tracing, secret handling, and tool-server connections already wired in. Agents discover their tools at runtime from over 50 MCP servers and reach models through a single gateway, so new capabilities and new providers arrive as registration or configuration rather than redeployment.
Wiring a new AI agent service into production at Grab now takes about an hour, down from two weeks or more. The saving is not in the agent's reasoning loop but in everything around it: secrets, tracing, service discovery and evaluation. Grab set out the change in an engineering post on LLM-Kit, the internal framework now backing more than 500 services at the Southeast Asian ride-hailing and delivery company, among them agents used every day by millions of merchants, drivers and consumers. As the post puts it: "The reasoning loop took a whole afternoon. The production wrapper took two weeks."
What LLM-Kit takes away is the per-service decision. It is intentionally not a new agent abstraction or a domain-specific language, but scaffolding around infrastructure Grab already had, assembled once the company "stopped solving these problems service by service and started solving them once, centrally." An engineer fills in a form and gets back a GitLab repository holding a working FastAPI service, with LangGraph agent modules, OpenTelemetry tracing, Vault secrets, and service discovery already wired, plus an evaluation endpoint from the first commit, scoring answers with ROUGE, BLEU, and a second model as grader.
Figure 1: FastAPI Service Project Directory Structure (source: Grab team’s blog)
Tools are not pre-wired: agents fetch them at runtime from over 50 registered servers speaking the Model Context Protocol, so a capability registered once reaches every agent. Neither are model providers. Every model call goes through the OpenAI-compatible GrabGPT Gateway, which fronts five providers and injects credentials so that application code never hard-codes a provider.
Choosing a framework over a platform was deliberate, and the post explains why:
A platform would have locked teams into rigid assumptions that would soon become outdated. A framework let us meet developers where they already were.
Analyst Kai Waehner argued in April that "agentic AI lock-in is more durable than API lock-in because it accumulates at multiple layers simultaneously," naming the model, the framework, the runtime and the patterns teams build around them. He was not writing about Grab, but the frame applies: the gateway covers the model layer, while the framework, runtime and patterns are harder to put behind one interface and are shared by every service on LLM-Kit.
Separately, Palana, described in June by Grab's CyberSecurity team, lets teams "experiment with autonomous agents without giving up control over identity, secrets, network access, and operational visibility." The analytics group has built a multi-agent engineering support system of its own.
LLM-Kit solved building and shipping one agent; at 500, Grab found the problems had moved from the framework to the platform. The gateway governs which model everyone calls, the remote MCP framework lets teams reuse each other's tools, and an evals platform tells whether a prompt change made an agent better or merely different. Much of that platform layer can now be bought rather than built: Amazon Bedrock AgentCore and Google's Agent Runtime host agents written in an existing framework and supply identity, gateway and observability. For teams weighing the same decision, the useful finding is where the cost actually sits: if the distinctive work takes an afternoon and the shared plumbing takes a fortnight, the choice is not about which agent library to pick, but about who owns secrets, tracing and evaluation.