Stripe's Kai Architecture: Designing a Company-Wide Agent Framework on LangChain and Deep Agents

🏗️ Architectural Pillars of Stripe's Kai Platform

When an enterprise transitions from simple retrieval-augmented generation (RAG) pipelines to autonomous agentic systems, the architectural complexity scales non-linearly. Stripe’s disclosure of its internal Knowledge AI platform, Kai, highlights this shift. Built to serve as a company-wide agent framework, Kai leverages LangChain alongside "Deep Agents"—systems capable of multi-step reasoning, self-correction, and dynamic code execution.

For engineering leaders, the interest in Kai is not merely that it was built quickly, but how it solves the fundamental challenges of enterprise agent deployment: state management, secure code execution, and centralized governance. In my analysis of agentic architectures, I have found that most organizations fail here. They build brittle, single-use agents that run in unconstrained environments, leading to security vulnerabilities, runaway token costs, and unmaintainable codebases.

To understand Kai, we must first look at its macro-architecture. A company-wide agent framework cannot exist as a collection of isolated microservices running their own LLM clients. Instead, it must be structured as a centralized platform that decouples agent definition, orchestration, and execution. I categorize the core architecture of an enterprise agent platform into four distinct layers:

• The Orchestration Layer (The Control Plane): This layer manages agent lifecycles, routes incoming requests, and coordinates state transitions. In Kai’s case, this is built on top of LangChain, utilizing stateful graph structures to define how agents transition between planning, tool execution, and response synthesis.
• The Agent Registry and Catalog: A centralized repository where teams register their agents, schemas, and tool definitions. This prevents redundant development and ensures that tools (such as database connectors or internal API wrappers) are reusable across different business units.
• The Execution Runtime (The Data Plane): Where the actual LLM calls, tool executions, and code compilations occur. Crucially, this runtime must be decoupled from the orchestration layer to prevent resource exhaustion and isolate security risks.
• The Governance and Observability Gateway: An API gateway specifically designed for LLMs. It handles semantic caching, rate limiting, cost tracking, and policy enforcement (such as preventing prompt injection or data exfiltration).

By centralizing these layers, a unified interface for agent development is established. When a developer builds a new agent—for example, an assistant that analyzes merchant churn—they do not write boilerplate code to connect to LLMs or manage memory. Instead, they register a declarative agent configuration in the registry, define the necessary tools, and let the platform handle orchestration, security, and state management.

This separation of concerns is critical. It allows platform teams to optimize the underlying infrastructure—such as swapping LLM providers, upgrading sandboxed environments, or tuning caching strategies—without breaking individual agent implementations. It also ensures that security policies are enforced globally, rather than relying on individual developers to implement them correctly.

An in-depth architectural analysis of Stripe's Kai platform. Learn how to design a centralized enterprise agent framework using LangChain, secure sandboxed code execution runtimes, and robust governan

Implementing Deep Agents: State, Memory, and Tool-Calling Loops

Simple agents operate on a linear "react" loop: they receive an input, call a tool, and return the output. "Deep Agents," as conceptualized in the Kai architecture, operate on complex, non-linear state machines. They must be capable of breaking down a complex prompt into a directed acyclic graph (DAG) of sub-tasks, executing those tasks in parallel or sequence, evaluating the intermediate results, and dynamically replanning if a tool returns an error.

To implement this level of autonomy, I recommend utilizing a stateful graph framework like LangGraph. LangGraph models agent workflows as state machines where nodes represent actions (such as calling an LLM or executing a tool) and edges represent state transitions based on the output of those actions.

In a deep agent architecture, state must be explicitly defined and persisted. This is not just "chat history"; it is a structured schema that tracks the agent's current plan, the list of completed tasks, the outputs of those tasks, and any errors encountered.

Here is a concrete Python implementation of a stateful deep agent loop utilizing LangGraph. This pattern demonstrates how to implement a self-correction loop where the agent evaluates the output of a code execution tool and automatically rewrites the code if it fails.

import json
from typing import Dict, List, TypedDict, Union
from langgraph.graph import StateGraph, END
from langchain_core.messages import BaseMessage, HumanMessage, AIMessage

# Define the state schema for our Deep Agent
class AgentState(TypedDict):
    messages: List[BaseMessage]
    current_plan: List[str]
    completed_tasks: List[str]
    generated_code: str
    execution_error: Union[str, None]
    retry_count: int

# Node: Planner - Analyzes input and generates an execution plan
def planner_node(state: AgentState) -> Dict:
    last_message = state["messages"][-1].content
    plan = ["write_code", "execute_code", "verify_results"]
    return {
        "current_plan": plan,
        "messages": [AIMessage(content=f"Plan generated: {json.dumps(plan)}")]
    }

# Node: Code Generator - Generates Python code based on the plan
def code_generator_node(state: AgentState) -> Dict:
    error_context = f"\nPrevious execution failed with error: {state['execution_error']}" if state["execution_error"] else ""
    prompt = f"Write a Python script to calculate merchant metrics.{error_context}"

    # Simulating LLM code generation
    generated_code = "def calculate(): return 100 / 0" if state["retry_count"] == 0 else "def calculate(): return 100 / 10"

    return {
        "generated_code": generated_code,
        "messages": [AIMessage(content=f"Generated code: {generated_code}")]
    }

# Node: Sandboxed Executor - Executes the generated code safely
def executor_node(state: AgentState) -> Dict:
    code = state["generated_code"]
    retry = state["retry_count"]
    try:
        if "100 / 0" in code:
            raise ZeroDivisionError("division by zero")
        result = "Success: Result is 10.0"
        return {
            "execution_error": None,
            "completed_tasks": state["completed_tasks"] + ["execute_code"],
            "messages": [AIMessage(content=result)]
        }
    except Exception as e:
        return {
            "execution_error": str(e),
            "retry_count": retry + 1,
            "messages": [AIMessage(content=f"Execution failed: {str(e)}")]
        }

# Conditional Router: Decides whether to retry or proceed to end
def router(state: AgentState) -> str:
    if state["execution_error"] is not None:
        if state["retry_count"] < 3:
            return "generate_code"
        return "fail_node"
    return END

# Construct the LangGraph State Machine
workflow = StateGraph(AgentState)

workflow.add_node("planner", planner_node)
workflow.add_node("generate_code", code_generator_node)
workflow.add_node("execute_code", executor_node)

workflow.set_entry_point("planner")
workflow.add_edge("planner", "generate_code")
workflow.add_edge("generate_code", "execute_code")

# Dynamic routing based on execution success or failure
workflow.add_conditional_edges(
    "execute_code",
    router,
    {
        "generate_code": "generate_code",
        "fail_node": END,
        END: END
    }
)

app = workflow.compile()

This pattern illustrates the core power of Deep Agents: resilience. By encoding the self-correction loop directly into the graph state, the agent can recover from syntax errors, API timeouts, or logical bugs without human intervention.

However, implementing this state machine requires robust state persistence. In a production environment, in-memory state is insufficient. If a node execution takes 30 seconds and the server restarts, the entire agent run is lost. I recommend backing your graph state with a persistent store like Redis or PostgreSQL, using LangGraph’s checkpointer interface. This allows you to pause agent execution, wait for human-in-the-loop approval if a high-risk tool is called, and resume execution seamlessly.

⚙️ Secure Sandboxing for Dynamic Code Execution

Perhaps the most technically challenging aspect of Stripe's Kai architecture is the safe execution of LLM-generated code. Deep Agents are incredibly powerful when they can write and execute arbitrary code to analyze data, parse files, or interact with APIs. However, allowing an LLM to execute arbitrary code on your internal network is an extreme security risk.

If an agent is compromised via prompt injection, an attacker could write code to read environment variables, access internal databases, or launch attacks on other internal services. Therefore, a secure, isolated sandbox is a non-negotiable requirement for any enterprise agent platform.

I have evaluated several sandboxing strategies for agent runtimes. Standard Docker containers are insufficient on their own because they share the host kernel; a container breakout vulnerability could compromise the underlying VM. To mitigate this, you must implement a multi-layered isolation strategy. The table below compares the primary execution sandboxing technologies available for agentic workloads:

Sandboxing Technology	Isolation Mechanism	Startup Latency	Resource Overhead	Best Use Case
Standard Docker	Linux Namespaces / cgroups	Low (100ms - 1s)	Low	Internal, trusted code execution only.
gVisor (Google)	User-space kernel (intercepts syscalls)	Medium (200ms - 500ms)	Low to Medium	Multi-tenant agent execution, untrusted code.
Firecracker (AWS)	MicroVMs (KVM-based virtualization)	Low (100ms - 150ms)	Medium	High-security, ephemeral code execution.
WebAssembly (Wasm)	Language-level runtime sandbox	Extremely Low (<10ms)	Extremely Low	Lightweight data parsing, non-Python runtimes.

For an enterprise agent platform like Kai, I strongly recommend utilizing gVisor or Firecracker MicroVMs. Stripe’s architecture relies on creating ephemeral, isolated sandboxes for each agent session.

When an agent decides to execute code, the orchestration layer packages the code and sends it to a dedicated Sandbox Service. This service provisions a microVM or a gVisor-secured container, executes the code within a strict time limit (e.g., 5 seconds), captures the standard output and error, and immediately destroys the environment. To implement this securely, you must enforce the following network and security boundaries:

• Zero Network Access: The sandbox must run with networking disabled ( --network none ) unless the agent specifically requires internet access. If internet access is required, it must be routed through a highly restrictive egress proxy that only allows connections to pre-approved domain whitelists.
• Read-Only Root Filesystem: The container filesystem should be read-only, with a small, ephemeral in-memory tmpfs mount for temporary file processing.
• Strict Resource Limits: Enforce hard limits on CPU (e.g., 0.5 vCPU), memory (e.g., 256MB), and disk I/O to prevent denial-of-service attacks caused by infinite loops or disk-filling code.
• No Secrets Exposure: Never pass database credentials or API keys directly into the sandbox environment. If the code needs to query a database, the sandbox should communicate with a secure data proxy that enforces row-level security and column masking before returning the data to the sandbox.

Centralized Governance, Guardrails, and Evaluation

When you scale an agent platform to hundreds of developers and millions of runs, governance becomes your primary operational bottleneck. Without centralized guardrails, you will quickly face astronomical API bills, performance degradation, and unpredictable agent behavior.

Stripe’s Kai architecture addresses this by implementing a centralized governance layer that sits between the orchestration framework and the LLM providers. I recommend structuring this layer as an intelligent API Gateway designed specifically for LLM traffic.

1. Token Budgeting and Rate Limiting

Deep agents running in loops can easily consume millions of tokens in minutes if they get stuck in an infinite planning loop. To prevent this, your platform must enforce strict token budgets at multiple levels:

• Per-Run Budgets: Limit the maximum number of LLM calls (e.g., 20) and total tokens (e.g., 100,000) allowed for a single agent execution. If the budget is exceeded, the platform terminates the run and alerts the user.
• Per-User/Per-Team Budgets: Implement daily or monthly financial caps on LLM spending for each business unit.

2. Guardrails and Prompt Injection Mitigation

Every input to an agent and every output from an LLM must pass through an automated guardrail pipeline. I recommend using a combination of fast, local models (like Llama-Guard) and regex-based pattern matchers to inspect traffic in real-time:

• Input Guardrails: Scan incoming user prompts for prompt injection attacks, jailbreak attempts, and personally identifiable information (PII). If PII is detected, redact it before sending it to the LLM.
• Output Guardrails: Scan LLM outputs to ensure they conform to the expected format (e.g., valid JSON or structured tool calls) and do not contain sensitive internal data that the user is not authorized to see.

🤖 3. Continuous Evaluation (LLM-as-a-Judge)

Unlike traditional software, you cannot verify agent behavior with simple unit tests. Because LLM outputs are probabilistic, you must implement a continuous evaluation pipeline. I recommend establishing an evaluation dataset—a golden set of representative user prompts along with their expected tool calls and final answers. Every time a developer updates an agent's prompt, system instructions, or tool definitions, the platform should automatically run the agent against this evaluation dataset.

Using an "LLM-as-a-Judge" pattern, a powerful model (such as GPT-4o or Claude 3.5 Sonnet) evaluates the test runs based on three key metrics:

• Faithfulness: Did the agent stick strictly to the provided context, or did it hallucinate facts?
• Answer Relevance: Did the final response directly address the user's prompt?
• Tool Selection Accuracy: Did the agent call the correct sequence of tools with the correct arguments?

By embedding this evaluation pipeline into your CI/CD process, you can prevent regressions and ensure that agent performance remains stable over time.

🎯 Conclusion

Stripe’s Kai architecture demonstrates that building an enterprise AI agent platform is not a challenge of model capability, but of software engineering discipline. To move beyond fragile prototypes, you must treat agents as stateful, governed, and highly secured systems.

If you are tasked with designing an agent platform for your organization, I recommend taking the following immediate next actions:

• Decouple Orchestration from Execution: Do not allow agents to execute tools or code within your primary application servers. Establish a clear boundary between your LangChain/LangGraph control plane and your execution runtimes.
• Build a Secure Sandbox First: Before you deploy a single agent that can write code, implement an ephemeral, isolated execution environment using gVisor or Firecracker. Treat untrusted LLM-generated code with the same security posture you would apply to malicious software.
• Implement Centralized State Management: Move away from in-memory agent states. Standardize on a persistent state store like Redis to ensure your agents are resilient, interruptible, and capable of human-in-the-loop verification.
• Establish Financial and Security Guardrails: Deploy an LLM gateway to enforce token budgets, rate limits, and input/output guardrails. This is the only way to scale agent development safely without risking runaway costs or data leaks.

By adopting these architectural principles, you will build a robust, secure, and highly scalable foundation that allows your organization to harness the true power of agentic AI.

---

🔗 Originally published on ixuvo.com