# Grab Tech Grab's Engineering team solves critical transportation challenges and makes transport freedom a reality for 620 million people in Southeast Asia. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Data Mesh at Grab (Part III): Operationalizing data reliability with automated DPIs DevFeed: [Data Mesh at Grab (Part III): Operationalizing data reliability with automated DPIs]() Original publisher: [Read original article]() Author: Harvey Li Published: 2026-08-28T00:00:00Z Content type: article Language: en Sources: [Grab Tech]() Topics: [incident](), [Kafka]() Tags: [apis](), [data](), [data-quality](), [database](), [engineering](), [incident](), [mesh](), [observability](), [platform](), [production](), [workflow]() ### AI overview Grab describes an automated Data Production Issue lifecycle for maintaining reliable data products. An incident orchestrator checks data-contract health, starts a DPI when contract tests fail, and distinguishes alerts from confirmed contract breaches. ### Source excerpt Introduction In the first two parts of this series, we described how Grab approaches data mesh through the Signals Marketplace: a way for teams to publish, discover, and reuse trusted data products across domains. Part II introduced the foundational tools behind certification: Hubble for metadata and ownership, Genchi for data quality observability, and the Data Contract Registry for explicit producer-consumer guarantees. Certification is the starting point for a trusted data marketplace. It gives downstream consumers confidence in an asset's ownership, documentation, lineage, and quality controls. Certification does not eliminate runtime failure. A certified table can still arrive late. A certified metric can still be affected by a broken dependency. A certified Kafka stream can still violate a freshness expectation. Keeping certified data products reliable in production requires more than defining standards upfront. Teams need a consistent way to detect failures, diagnose the root cause, fix the issue, and verify recovery. That is where Data Production Issues (DPIs) come in. At Grab, DPIs turn data quality signals into an operational workflow. The DPI lifecycle A good DPI should be clear enough to act on, and it should close automatically when the underlying condition recovers. From the beginning, we designed the DPI lifecycle to be automated, with minimal human-in-the-loop. The lifecycle starts when Kinabalu, Grab's incident orchestrator, observes that a data asset may no longer satisfy its contract. The contract captures the reliability expectations that matter for the asset, along with the health checks, exposed through Test Health application programming interfaces (APIs), that evaluate those expectations. The orchestrator stays decoupled from platform internals. It does not need to know how each platform computes freshness, completeness, or other quality dimensions. It only needs to ask whether the relevant contract tests are healthy. If one or more contract ## Building Jarvis Pro: Route first, answer later DevFeed: [Building Jarvis Pro: Route first, answer later]() Original publisher: [Read original article]() Author: Christian Coffrant Published: 2026-08-21T00:00:00Z Content type: article Language: en Sources: [Grab Tech]() Topics: [AI Chat]() Tags: [account-management](), [ai](), [artificial-intelligence](), [business](), [classification](), [data](), [engineering](), [evaluation](), [llm](), [product](), [routing]() ### AI overview Grab describes Jarvis Pro, an AI assistant for account managers that routes a request to a constrained task type before generating an answer. The design aims to avoid confident but unsuitable merchant recommendations, and reports offline routing and answer-quality evaluation results. ### Source excerpt Introduction The first Jarvis Pro prototype could produce answers that sounded right. That was the problem. One early answer looked polished: it named the merchant, summarized the week, and recommended pushing promotions before the next review. It was also wrong. The merchant's order volume was down, but the sharper issue was operational: more outlets were paused and fulfilment had slipped. Sending more demand into that setup would have made the merchant look worse. That failure changed how we judged the system. Fluent was not enough. Jarvis Pro is the AI assistant we built for Grab account managers. Its job is to help them turn account data into better merchant conversations: what changed, why it changed, and what to do next. They rarely ask clean dashboard questions. They ask: "I am meeting this merchant tomorrow. What should I tell them?" or "Which accounts in my portfolio need attention this week?" Those questions hide decisions: scope, access, business diagnosis, and metric definition. If the system gets those wrong, confidence becomes a liability. So the core design became: route first, answer later. In an internal offline evaluation (not a measure of production performance or business impact), routing matched the expected safe route for 99.4% of 351 realistic prompts drawn from labelled eval sets from the first half of 2026. In a focused portfolio and brand answer-quality suite, the average score moved from 78.5 to 91.0. These figures come from offline launch-readiness evaluation only; they are not business-impact proof. Why dashboards were easier A dashboard answers a bounded question: "Show net sales for merchant X last week." An account review question has to diagnose the work to be done: "This merchant softened this week. Should I push promos, ads, or operations fixes before the review?" If outlets were paused, more traffic can backfire. If average order value fell, the next action may be menu or bundle design. If a dashboard, warehouse table, and local s ## Grab Bench: Evaluating AI on Grab-shaped production work DevFeed: [Grab Bench: Evaluating AI on Grab-shaped production work]() Original publisher: [Read original article]() Author: Christian Coffrant Published: 2026-08-12T00:00:00Z Content type: article Language: en Sources: [Grab Tech]() Topics: [Human-AI evaluation](), [Language models](), [AI-assisted coding]() Tags: [ai](), [artificial-intelligence](), [benchmark](), [code](), [engineering](), [evaluation](), [llm](), [machine-learning](), [product](), [production](), [safety](), [sql]() ### AI overview Grab Bench is a configurable evaluation harness for AI systems performing production-shaped tasks. It evaluates failures in SQL generation, tool calling, profile updates, and coding agents using task plugins, row-level records, deterministic scorers, or LLM judges. ### Source excerpt Introduction What worried us wasn't the hallucination, it was the subtle plausibility. Answers an engineer could easily read past and accept: a right-looking Structured Query Language (SQL) query, a plausible tool call, an innocent profile update, or a patch that satisfied the surface tests. When we analyzed the row-level failures, a clear pattern emerged: SQL generation: kept the query shape but changed the underlying metric. Tool calling: selected the right tool family but drifted on parameters. Profile updates: cited every event instead of only the evidence that supported the claim. Coding agents: passed visible tests while missing a hidden stateful invariant. Grab Bench bridges this exact gap. Grab Bench is a configurable eval (evaluation) harness for artificial intelligence (AI) systems on Grab-shaped work. It runs model providers through task plugins, records one row per case/model pair, and uses deterministic scorers or large language model (LLM) judges depending on the task. We treat the eval like software: version it, run baselines, keep score records, and make the failure modes visible enough for a team to debug. This write-up focuses on the design choices behind that work. The problem: plausible is not correct Public leaderboards are still useful; we read them too. They just answer a different question. A product team needs to know whether a model can preserve a metric definition, obey an internal tool contract, stay cautious with weak evidence, or make a code change without breaking behaviour hidden from the prompt. The hard part is that real examples are rarely reusable as-is. Production traces, schemas, user records, and internal workflows need protection. So the benchmark has to preserve the shape of the work without depending on the work itself. That constraint shaped Grab Bench from the beginning. Some surfaces stay internal. Others use synthetic or redacted cases. Either way, the case has to keep the thing that makes the work hard: metric faithfuln ## How AI is transforming analytics at Grab DevFeed: [How AI is transforming analytics at Grab]() Original publisher: [Read original article]() Author: Maanas Prabhakar Published: 2026-08-01T00:23:00Z Content type: article Language: en Sources: [Grab Tech]() Topics: [Artificial Intelligence](), [data](), [Code](), [coding]() Tags: [agentic](), [agents](), [ai](), [analysis](), [analytics](), [data](), [engineering](), [workflow]() ### AI overview Grab describes how increasingly capable AI agents are transforming analytics by automating data preparation, query writing, analysis, experiment design, result interpretation, and commentary. The article presents an autonomy ladder in which agents take ownership of more of the analytics loop while humans retain accountability for problem framing, metric definitions, causal reasoning, business assumptions, decisions, and stakeholder relationships. ### Source excerpt Introduction At Grab, analytics sits close to almost every decision that matters. Our north star is the democratisation of intelligence, ensuring that anyone making a business call has immediate access to trustworthy answers. Over the last two years, model capability has crossed a threshold enabling this shift. Agents now do in minutes what used to take a week: preparing the data, writing queries, running deep analysis and developing insights for business opportunities, designing experiments and interpreting the results, drafting the commentary that follows, and more. Our throughput is no longer rate-limited by how fast an individual can write code, build a deck, or run a deep-dive. It is rate-limited by how fast we can frame the right problem, judge the right answer, and influence the right decision. As autonomy climbs, an analyst's impact moves from producing the artefact to owning the question and the call behind it, and the role evolves to become part builder, part advisor, part strategist, owning the loop rather than running it. That unlocks two things at once: work we already do, faster and at lower marginal cost, and work we could never staff before, sitting beside every product manager, business owner, and operator at the moment they decide. The ladder We were heavily inspired by Dan Shapiro's framing of five levels for AI coding. We use a similar ladder that defines how much of the loop an agent should own and where human judgement stays for every analytics loop. One distinction runs across every level: who owns the loop, and where human judgement is required. Level What Human role Agent role L2 AI-Assisted Owns and executes every step; uses AI to draft, suggest, summarise Drafts SQL, suggests a visualisation L3 Human plans, agent owns steps, human reviews Frames the question, picks the metric, the segment, and the comparison frame, reviews evidence, owns the recommendation Discovers data, writes and runs the query, sanity checks, drafts the write-up, flags ## Crowdsourced taxonomy verification: A feedback-driven framework for refining knowledge graph relationships via online search interactions DevFeed: [Crowdsourced taxonomy verification: A feedback-driven framework for refining knowledge graph relationships via online search interactions]() Original publisher: [Read original article]() Author: Junpeng Niu Published: 2026-07-30T00:00:00Z Content type: article Language: en Sources: [Grab Tech]() Topics: [AI search](), [AI, ML & Data Engineering](), [Language models]() Tags: [algorithms](), [data](), [engineering](), [graphs](), [knowledge-graph](), [large-language-models-llms](), [llm](), [machine-learning](), [search](), [validation]() ### AI overview The article presents a feedback-driven system for verifying knowledge-graph relationships through live search interactions. It tests unverified parent-child or sibling edges in search suggestions, measures user engagement, and uses greedy exploration to balance data collection with result quality. ### Source excerpt Introduction The efficacy of semantic search relies on the accuracy of the underlying Knowledge Graph (KG). In high-velocity domains like on-demand food delivery or e-commerce, the catalog of entities like dishes, products, and merchants changes rapidly. Current methods for KG construction and maintenance face three critical challenges: Inaccuracy and hallucination from Large Language Models (LLMs): Automated models often infer relationships based on statistical text co-occurrence rather than semantic reality. For instance, an LLM might incorrectly classify "Pho" as a child of "Italian Noodle Soup" due to linguistic similarity, leading to irrelevant search results. Scalability limits of manual verification: Traditional verification relies on human annotators or domain experts. This approach is slow, expensive, and unable to keep pace with dynamic catalogs containing millions of entities. For example, daily changes in restaurant menus or grocery stock keeping units (SKUs). Error propagation in ranking: Inaccurate graph edges propagate errors downstream. If a parent-child relationship is wrong, query expansion algorithms will retrieve irrelevant items, directly degrading Click-Through Rate (CTR) and user trust. We introduce a feedback-driven verification engine that operationalizes the search interface as a validation environment. Key contributions include: User feedback-driven verification: The system treats unverified graph edges as hypotheses. Instead of accepting them as truth, it tests them against live traffic by injecting them into search suggestions and measuring user engagement. Hierarchical relationship refinement: Unlike systems that only validate entities (nodes), this framework validates structural links (edges). It confirms whether entity A is truly a parent, child, or sibling of entity B, ensuring structural integrity. Adaptive exploration: The system employs a greedy exploration policy. It intelligently balances exploitation by showing known good resul ## Agent platform (Part 1): How we help Grab build and run AI agents at scale DevFeed: [Agent platform (Part 1): How we help Grab build and run AI agents at scale]() Original publisher: [Read original article]() Author: Kendrick Tan Published: 2026-07-24T00:00:10Z Content type: article Language: en Sources: [Grab Tech]() Topics: [AI Bots](), [AI Chat](), [MSP MCP]() Tags: [ai-agents](), [ai-infrastructure](), [architecture](), [design](), [engineering](), [experiment](), [generative-ai](), [go](), [llm](), [machine-learning](), [mcp](), [platform](), [scale]() ### AI overview Grab describes the first part of its AI-agent platform story: a Tech Infra support bot that evolved from operational automation into a GPT-powered Level-0 support layer. The article outlines its reasoning and tool planes and explains how scaling challenges informed the LLM-Kit framework. ### Source excerpt Part 1: From one support bot to a framework At Grab, AI agents have evolved from interesting team prototypes into production services used every day by millions of merchants, drivers, and consumers. Today, more than 500 services run on our internal agent framework, over 50 Model Context Protocol (MCP) servers are registered on our remote MCP framework, and a single Large Language Model (LLM) gateway fronts every model call across the company, handling billions of tokens each month. None of this was designed up front. It began as the plumbing behind one internal support bot, which then expanded because the same problems kept resurfacing for every team trying to ship an agent. This series tells the story of what the platform eventually became. This Part 1 of the blog focuses on the beginning: the architecture of our AI support bot, the specific pain points we hit while scaling and iterating on it, and how each of those failures became a core building block in the framework we now call LLM-Kit. The bot that started it Imagine you have a question for the Technical Infrastructure (Tech Infra) team - the engineers who run the cloud platforms, databases, developer tooling, and AI infrastructure behind Grab's ecosystem. Instead of immediately paging an on-call engineer, a bot first triages the request, checks the team's documentation, runbooks, and past Slack threads, and tries to answer directly in the thread. If it still cannot resolve the issue, it routes the ticket to the right human, with the relevant context already attached. That is what we built with the Tech Infra Support Bot. In the first half of 2023, Tech Infra handled thousands of support tickets, many of them repeated questions that had already been answered somewhere internally. Before LLMs, the bot's role was mainly operational; performing tasks like helping track acknowledgments and response times for on-call engineers. With the arrival of GPT-4-32k, we evolved it into a GPT-powered Level-0 support layer th ## Scaling Grab's Data Lake: Our journey to Apache Iceberg adoption DevFeed: [Scaling Grab's Data Lake: Our journey to Apache Iceberg adoption]() Original publisher: [Read original article]() Author: Rahul Penti Published: 2026-07-10T00:00:00Z Content type: article Language: en Sources: [Grab Tech]() Topics: [Apache Iceberg](), [data](), [Amazon S3](), [parquet](), [Apache Spark](), [Latency](), [Concurrency]() Tags: [apache-iceberg](), [compute](), [concurrency](), [data](), [database](), [engineering](), [latency](), [parquet](), [performance](), [s3](), [scale](), [spark]() ### AI overview Grab describes its transition from Hive Parquet and a directory-based Hive Metastore architecture toward Apache Iceberg and a table-centric lakehouse. The article outlines scalability problems involving metadata latency, small files, S3 request overhead, and operational management, and mentions a unified Spark catalog built to hide table-format differences. ### Source excerpt Introduction: The evolution of Grab's Data Lake At Grab's scale, managing petabytes of data across billions of S3 objects demands more than a storage layer. It demands a robust architectural primitive that supports the high-concurrency needs of a modern "Lakehouse." Our goal is full storage-compute separation, leveraging S3 as an elastic foundation for both near-real-time metrics and large-scale batch transformations. For years, the vast majority of our tables were Hive Parquet, managed through the Hive Metastore with a directory-based layout. This model served us well, but as data volume grew, the directory-and-metastore approach became the limiting factor. We are now transitioning to a table-centric architecture built on modern table formats, treating data as a first-class primitive to ensure consistency and performance across our internal data transformation platforms: Slide, which powers batch transformations, and Hugo, which handles online-to-data-lake ingestion. Along the way, we also built the UnifiedSparkCatalog, a unified Spark catalog that hides table-format differences from users entirely, which we are open-sourcing alongside this post. The catalyst for change: Challenges with Hive Parquet For years, Hive Parquet was the backbone of our Data Lake, representing the vast majority of our tables. However, as data volume scaled, the architectural limitations of directory-based storage became apparent. We identified four primary bottlenecks: Catalog latency: The Hive Metastore (HMS) became a centralized failure point. High concurrency during metadata access led to O(n) listing overhead, where query planning time scaled linearly with partition count, crippling throughput. The small file problem: The directory layout left us with severe file fragmentation. Certain Machine Learning (ML) datasets had an average file size under 1 MB, with thousands of files in each partition. At this scale, the overhead of S3 object listing and metadata request latency drove up Appl ## Migrating Counter Service storage: Design choices and learnings DevFeed: [Migrating Counter Service storage: Design choices and learnings]() Original publisher: [Read original article]() Author: Jia Long Loh Published: 2026-07-03T00:00:00Z Content type: article Language: en Sources: [Grab Tech]() Topics: [Database](), [migration](), [Latency](), [real-time](), [backends]() Tags: [artificial-intelligence](), [backend](), [database](), [devsecops](), [engineering](), [evaluation](), [infrastructure](), [kubernetes](), [latency](), [migration](), [platform](), [real-time](), [security](), [storage]() ### AI overview Grab's Counter Service migrated its storage backend from a wide-column database to Aerospike to support a high-volume, low-latency fraud-detection workload. The article describes separating storage from business logic, revisiting data modeling and access patterns, and designing reader- and writer-side changes for a gradual, observable rollout. ### Source excerpt Introduction Counter Service is used across Grab's anti-fraud platform to answer time-windowed count questions, such as recent ride requests by a user or failed payment attempts on a card. The service handles tens of thousands of queries per second (QPS) with about a billion requests per day, while maintaining strict requirements around latency and reliability to support real-time fraud rule evaluation. For most of its life, Counter Service was backed by a wide-column database that served the workload reliably as the service scaled. As part of a broader infrastructure review mandated at an organizational level, our database team evaluated alternatives to this storage that many services relied on, including Counter Service. Based on their assessment, Aerospike emerged as a good fit for our use-case. We also used the migration as an opportunity to decouple storage concerns from business logic, a necessary first step for this migration, and one that would reduce the effort required for future storage changes. As part of the same effort, we revisited the data model and access patterns in detail, which helped us identify and apply several straightforward optimizations. This post walks through how we did it. What we built on the reader-side to make the migration safe, how we redesigned the writer-side data model around the new backend, and what we ran into during the gradual rollout. Setting the stage Counter data is stored in three time granularities: 15-minute, hourly, and daily buckets. A typical read would be along the lines of, "give me the count for key X over the last 90 minutes", which the service decomposes into the smallest possible set of buckets, one hourly in the middle, a few 15-minute buckets at the edges, fetches them, and sums. In the original setup, each granularity was stored in a separate table with a composite primary key: TABLE daily_count ( key TEXT, -- partition key day_ts TIMESTAMP, -- clustering key count BIGINT, PRIMARY KEY (key, day_ts) ); The ## Scaling out Distroless adoption With AI DevFeed: [Scaling out Distroless adoption With AI]() Original publisher: [Read original article]() Author: Jia Yee Chong Published: 2026-06-22T00:00:00Z Content type: article Language: en Sources: [Grab Tech]() Topics: [Security](), [migration](), [Dockerfile](), [Vulnerabilities](), [make](), [ci](), [configuration](), [Docker](), [Docker Image](), [Testcontainers](), [MySQL]() Tags: [artificial-intelligence](), [ci](), [containers](), [devsecops](), [docker](), [docker-image](), [engineering](), [migration](), [mysql](), [security](), [testcontainers](), [testing](), [vulnerabilities]() ### AI overview Grab describes migrating services from heavy base images to Distroless images to reduce security risks and eliminate unnecessary binaries and associated CVEs. The article explains the runtime-failure risks of this migration and presents medium tests using Docker images, Testcontainers, and network proxies to verify configuration and runtime dependencies in CI. ### Source excerpt Distroless adoption at Grab Grab is migrating from heavy base images to Distroless images to reduce security risks. By limiting each container to the application and its runtime dependencies, we shed non-essential binaries and associated Common Vulnerabilities and Exposures (CVEs). This migration is more than a compliance mandate; it is a strategic security decision to build a more resilient environment. Why Distroless requires rigorous testing Distroless adoption risk: Runtime failure Shifting to Distroless images introduces a critical technical risk: Runtime Failure. A service might build perfectly in Continuous Integration (CI), but fail at the deployment stage due to: Missing shared objects: Binaries might require specific libraries (.so files) present in Ubuntu but absent in Distroless. Implicit links: Third-party tools might expect specific system utilities or directory structures. Testing is required to ensure two things: The service spins up with the correct configuration. All runtime dependencies remain intact. Scaling this verification across thousands of services manually? That would take years, unless we found a way to automate the trust. The testing methodology As we perform changes to the Dockerfile definition of our services, it is important for us to include the corresponding test strategy to ensure that the changes that we make do not introduce a regression to our running services. Assessing the change introduced to our services, the lowest possible testing boundary would be that of what we define as medium tests in Grab. Medium tests in Grab At Grab, we categorize our test suites into 3 main sizes: small, medium and large. Small tests refer to functional tests whereby mocks are introduced via dependency injection. Large tests refer to end-to-end tests that run on actual services in our staging environment where nothing is mocked. Figure 1: Architecture diagram of a medium test environment Medium tests sit between the small and large tests. External ## Palana (Part 2): Architecting isolation, identity, and auditability for AI agents DevFeed: [Palana (Part 2): Architecting isolation, identity, and auditability for AI agents]() Original publisher: [Read original article]() Author: Kevin Littlejohn Published: 2026-06-21T00:00:00Z Content type: article Language: en Sources: [Grab Tech]() Topics: [Kubernetes](), [Artificial Intelligence](), [systems](), [observability](), [Network](), [Authentication](), [Large Language Model](), [Command-line interface](), [Filesystems]() Tags: [agents](), [ai](), [ai-agents](), [architecture](), [artificial-intelligence](), [authentication](), [autonomous](), [command-line](), [devsecops](), [engineering](), [http](), [kubernetes](), [llm](), [network](), [observability](), [platform](), [policy](), [production](), [resource](), [secrets](), [security](), [systems](), [workflow]() ### AI overview Palana Part 2 explains the architecture of Grab's Kubernetes-native secure execution platform for autonomous AI agents. It describes isolated user-and-agent namespaces, default-deny networking, proxy-mediated traffic, Vault-based secret separation, operator-managed resources, admission controls, persistent storage, observability signals, and identity handling. ### Source excerpt Introduction In Part 1, we introduced Palana, Grab's Kubernetes-native secure execution platform for autonomous AI agents. We discussed the underlying need for isolated environments and covered its core design principles: treating isolation as the unit of trust, keeping credentials out of agent hands, and mediating all network access. In this second part, we'll dive under the hood into Palana's architecture, look at the agent lifecycle, and share the key lessons we learned from putting this system into production. Architecture overview The core request path looks like this: Figure 1. Palana architecture overview. The agent pod runs in a namespace owned by one user and one agent. It gets default-deny style network policy, domain name system (DNS), access to required platform services, and a persistent /data volume. Browser traffic enters through Traefik. LLM traffic goes to the LiteLLM wrapper in the gateway namespace. General Hypertext Transfer Protocol (HTTP) and Hypertext Transfer Protocol Secure (HTTPS) egress goes through the proxy namespace. Secrets are read from Vault only by the component authorized to use them. The operator is responsible for turning a user request into the concrete Kubernetes shape: The user creates an agent through pcli (Palana command-line interface) or the portal. Palana writes a UserAgent or Agent custom resource with the raw user identity. The operator creates the user and agent namespaces, service accounts, role bindings, storage, network policies, and ingress. The user runs a template or container image. Admission webhooks inject proxy environment variables and enforce pod-level restrictions. Logs, policy decisions, and activity signals are emitted to observability systems. Agent lifecycle From a user's perspective, the basic workflow is intentionally small: ./pcli login ./pcli create demo ./pcli secrets add demo GRABGPT_API_KEY token= ./pcli run demo --template claudecodeui Behind those commands, Palana provisions an isolated