Evolution of an Internal AI Platform from No-Code LLM Apps to Agentic Systems
grab · Tech · 2025 · source Agentic: yes · promotional bias: med · 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: internal no-code AI platform and agentic tooling
Grab needed SpellVault to keep democratizing AI for non-technical employees while evolving from static RAG-based apps into agentic systems that could reason, act, call tools, support workflows, and interoperate with external agent frameworks.
Constraints:
- The platform had to remain no-code and easy for users across Grab.
- Apps needed grounding in current knowledge rather than relying only on LLM internal knowledge.
- Users needed integrations with internal systems, external APIs, Slack, web, and APIs.
- The platform had to evolve incrementally without disrupting existing apps.
- Agentic behavior required a clearer tool model and standards-compatible interoperability.
Architecture
SpellVault began as a no-code LLM app builder with RAG and plugins, then added workflow orchestration, citations, Python runtime, scheduling, graph-based execution, ReAct-style agents, Deep Research, unified Native and Community Built Tools, and MCP service exposure. This turned internal apps and knowledge vaults into callable building blocks for other agents while preserving the platform's no-code mission.
Diagram confidence: explicit (topology described by the source).
flowchart LR no-code-app-builder["No-code app builder"] --> knowledge-vault["Knowledge Vault"] knowledge-vault --> graph-executor["Graph executor"] plugin-framework["Plugin framework"] --> unified-tools-layer["Unified tools layer"] workflow-designer["Workflow designer"] --> graph-executor graph-executor --> react-agents["ReAct agents"] react-agents --> unified-tools-layer unified-tools-layer --> mcp-service["MCP service"]
Components
| Component | Role | Interacts with |
|---|---|---|
No-code app builder |
Lets Grab employees create LLM apps without coding. | Knowledge Vault |
Knowledge Vault |
Provides RAG grounding from wikis, Google Docs, text, and PDFs. | Graph executor |
Plugin framework |
Lets apps fetch information or call internal systems and external APIs at runtime. | Unified tools layer |
Workflow designer |
Drag-and-drop deterministic workflow interface combining LLM calls, code, and lookups. | Graph executor |
Graph executor |
Runs apps with nodes, edges, states, branching, looping, and modularity. | ReAct agents |
ReAct agents |
Transforms apps into reasoning-and-acting agents that use Knowledge Vault and plugins dynamically. | Unified tools layer |
Unified tools layer |
Combines Native Tools and Community Built Tools under a runtime tool abstraction. | MCP service |
MCP service |
Exposes SpellVault apps and RAG as MCP-callable tools for other agents and clients. | — |
Data flow
Users configure apps through web or Slack, attach Knowledge Vault sources and plugins, optionally design workflows that combine LLM calls, Python execution, and knowledge lookups, run apps through a graph executor or ReAct agent, invoke Native or Community Built Tools at runtime, and expose apps or RAG through MCP for other clients.
Why this architecture
Grab evolved SpellVault incrementally because users already depended on a no-code platform. Layering workflows, graph execution, tool abstractions, and MCP on top of RAG preserved ease of use while giving apps more agency, dynamic context gathering, and interoperability.
Models used: Large Language Models · RAG pipelines · ReAct agents · Graph based executor · Deep Research · Python runtime · Model Context Protocol
Scale
- SpellVault enabled thousands of apps at Grab.“enabling the creation of thousands of apps that drive automation, foster experimentation, and support production use cases.”article, stated
- Users could make apps in minutes and use them through browser or Slack.“users can make their AI apps in minutes and start using them via browser or Slack messaging immediately and intuitively”article, stated
- Grab operates across more than 800 cities in eight Southeast Asian countries.“Serving over 800 cities in eight Southeast Asian countries”article, stated
Alternatives considered (roads not taken)
Rely only on the LLM's internal knowledge.
Rejected because: Grab wanted responses grounded in current, contextually relevant, and factual information from company sources.
Keep capabilities as UI checkboxes inside PromptBuilder.
Rejected because: Agentic apps needed a clearer model where LLMs could choose and invoke tools autonomously.
Keep SpellVault self-contained.
Rejected because: MCP let other agents and clients invoke SpellVault apps and RAG without custom integrations.
Patterns
rag-retrieval (Knowledge Vault)
SpellVault grounds app responses in Wikis, Google Docs, text, and PDF knowledge sources.
tool-use-orchestration (tools and plugins)
SpellVault unifies Native Tools and user-configured tools so LLM apps can invoke capabilities dynamically at runtime.
prompt-chaining (workflow orchestration)
The Workflow designer combines LLM calls, Python code execution, and Knowledge Vault lookups in predefined structured flows.
multi-agent-orchestration (agentic platform)
SpellVault exposes apps and RAG as MCP tools so agents and MCP-compatible clients can compose them as building blocks.
Tradeoffs
Evolve incrementally instead of rebuilding the platform.
Chose Layered capabilities on SpellVault over A complete overhaul.
Rationale: Incremental evolution kept the platform seamless for users while adding new execution modes and tools.
Convert existing apps to ReAct agents.
Chose One size fits many ReAct execution over Separate bespoke agent rewrites for every app.
Rationale: The ReAct framework enhanced app capabilities while preserving existing functionality.
Distinguish Native Tools from Community Built Tools.
Chose Two classes under one tools umbrella over Treating every tool as the same configuration type.
Rationale: Native tools need no user-specific configuration, while custom plugins often require credentials and workflow-specific settings.
Gotchas (what bit them)
Static app prompts were not enough for dynamic work.
Root cause: Apps needed to interact with external systems and diverse data sources at runtime.
Resolution: Add plugins and later a unified tool abstraction for internal systems, APIs, and runtime information fetching.
Trustworthiness became more important as more users built apps.
Root cause: More production and productivity use cases increased the risk of ungrounded or unverifiable responses.
Resolution: Add citation capability to mitigate trust concerns.
Feature checkboxes hid the agentic mental model.
Root cause: Capabilities such as Python code execution and internal search were embedded directly in PromptBuilder.
Resolution: Reposition capabilities as tools that agents can choose and use autonomously.
Evaluation
Grab evaluated SpellVault through user adoption, app creation, production use cases, trust/citation needs, user feedback for new capabilities, and the ability to preserve existing functionality while adding agentic execution.
Metrics: Thousands of apps created · Internal productivity gains · Automation use cases · Production use cases · User feedback · No-disruption migration to ReAct agents
Outcomes
- SpellVault grew from a no-code RAG app builder into an agentic platform.
- Existing apps gained ReAct-style reasoning and acting without behavior disruption.
- Deep Research, workflows, Native Tools, Community Built Tools, and MCP broadened the platform.
- SpellVault apps and RAG became callable building blocks for other agents and clients.
The article cites thousands of internal apps, app creation in minutes, and Grab's broader footprint of over 800 cities in eight Southeast Asian countries.