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:

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"]
Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

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.

“These workflows enabled users to seamlessly combine various components from the SpellVault ecosystem—such as LLM calls, Python code execution, and Knowledge Vault lookups”article, stated
“Each app created in SpellVault can now be exposed through the MCP protocol.”article, stated

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.

“Rather than opting for a complete overhaul, SpellVault has embraced incremental advancements”article, stated
“It meaningfully shifted SpellVault toward making agentic behavior more natural, discoverable, and extensible for every app.”article, stated

Models used: Large Language Models · RAG pipelines · ReAct agents · Graph based executor · Deep Research · Python runtime · Model Context Protocol

Scale

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.

“Rather than solely relying on the LLM’s internal information, we wanted the apps to ground their responses in up-to-date, contextually relevant, and factual information.”article, stated

Keep capabilities as UI checkboxes inside PromptBuilder.

Rejected because: Agentic apps needed a clearer model where LLMs could choose and invoke tools autonomously.

“we recognized that these capabilities should instead be positioned as “Tools” for LLMs to use with greater autonomy”article, stated

Keep SpellVault self-contained.

Rejected because: MCP let other agents and clients invoke SpellVault apps and RAG without custom integrations.

“By exposing both apps and RAG through MCP, we shifted SpellVault from being a self-contained platform to becoming an interoperable service provider”article, stated

Patterns

rag-retrieval (Knowledge Vault)

SpellVault grounds app responses in Wikis, Google Docs, text, and PDF knowledge sources.

“SpellVault has built-in integrations with knowledge sources such as Wikis, Google Docs, as well as plain text and PDF uploads.”article, stated

tool-use-orchestration (tools and plugins)

SpellVault unifies Native Tools and user-configured tools so LLM apps can invoke capabilities dynamically at runtime.

“formed a comprehensive collection of tools that LLMs could dynamically invoke at runtime.”article, stated

prompt-chaining (workflow orchestration)

The Workflow designer combines LLM calls, Python code execution, and Knowledge Vault lookups in predefined structured flows.

“design deterministic workflows. These workflows enabled users to seamlessly combine various components”article, stated

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.

“other agents or MCP-compatible clients, such as IDEs or external orchestration frameworks, to treat a SpellVault app as a callable tool.”article, stated

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.

“ensuring that users can seamlessly benefit from new capabilities without disruption.”article, stated

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.

“a “one size fits many” solution that significantly enhanced the capabilities of these apps.”article, stated

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.

“Native Tools required no user-specific configuration (e.g., performing internet searches), whereas Community Built Tools were custom, user-configured entities”article, stated

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.

“Their real value lies in the ability to seamlessly interact with external systems and diverse data sources.”article, stated

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.

“With more users building with the platform, ensuring the trustworthiness of responses generated by SpellVault apps became increasingly important.”article, stated

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.

“these features were primarily accessible through simple checkboxes in the user interface.”article, stated

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

“Users quickly adopted the platform, creating thousands of apps for internal productivity gains, automation, and even production use cases.”article, stated
“Over time, we introduced numerous new capabilities to SpellVault, driven both by user feedback and our commitment to innovation”article, stated

Outcomes

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.

“What began as a no-code builder for LLM apps has steadily expanded into an agentic platform”article, stated
“these apps become accessible building blocks that other systems can invoke dynamically.”article, stated