Forem: Mrunmay

How Deep Agents Actually Work: A Browsr Architecture Walkthrough

Mrunmay — Mon, 15 Dec 2025 12:20:07 +0000

Deep agents don’t fail loudly — they drift.

Once an agent runs for 10–50 steps, debugging becomes guesswork. You don’t know which tool call caused the issue, why the plan changed, or where cost and context exploded.

In this post, we’ll break down how a real deep agent works under the hood by walking through the architecture of Browsr, a browser-based deep agent, and observing its execution step by step.

What Makes an Agent “Deep”

Keeps a running plan / TODO list of what still needs to be done.
Uses tools (like a browser, shell, APIs) to act in the world step by step.
Stores persistent memory (artifacts, notes, intermediate results) so it doesn’t forget earlier work.
Regularly evaluates its own progress, adjusts the plan, and retries when something fails.

Because it can plan, remember, and correct itself, a deep agent can run for a long duration, tens or hundreds of steps without losing the thread of the task.

Let’s debug and observe Browsr using vLLora(a tool for agent observability) and see what happens under the hood.

Browsr

Browsr is a headless browser agent that lets you create sequences using a deep agent pattern and then hands you the payloads to run over APIs at scale. It also exports website data as structured or LLM-friendly markdown.

At a high level, Browsr is a deep agent that:

Plans its next action explicitly
Executes browser commands in controlled steps
Persists state between iterations
Evaluates progress before continuing

You can explore the definition and related configurations in this repo.

Note: Always respect the copyright rules and terms of the sites you scrape.

Debugging with vLLora

To make the execution observable, we’ll inspect the agent using request-level traces and timelines captured during execution.

vLLora lets you debug and observe your agents locally. vLLora can help us to better understand our architecture; toolcalls and observe the full agent timeline. It also works with all popular models.

Browsr iterates in 1–3 command bursts as a single step, saving context to artifacts and completes the task with final tool.

Driver: browser_step is the main executor; every turn runs 1–3 browser commands with explicit thinking, evaluation_previous_goal, memory, and next_goal.
Context control: Large tool outputs are written to disk so the model can drop token-heavy responses and reload them on demand.
Stateful loop: Up to eight iterations, each grounded in the latest observation block (DOM + screenshot) to avoid hallucinating.
Strict tool contract: Exactly one tool call per reply (no free text), keeping the agent deterministic and debuggable.

Lets further examine tool definitions as stated below.

browser_step is the driver between steps. The system prompt forces the model to read the latest DOM and screenshot, report the current state, and then decide what to do next. Each turn must include:

thinking: Reasoning about the current state.
evaluation_previous_goal: Verdict on last step
next_goal: Next immediate goal in one sentence.
commands: Array of commands to be executed.

You can checkout the full agent defintion here.

Example: In one representative run, Browsr used the available context to navigate in step one, click in step two, and then run a JS evaluation to return structured data from the page.

Sample Traces

Average cost and no. of steps using gpt-4.1-mini

Average cost per trace ≈ $0.0303 per run
Average steps ≈ 10.5 steps per run

Why Observability Is Critical for Deep Agents

Once agents move beyond single-shot prompts, debugging stops being straightforward.

Engineers often find themselves tweaking system prompts, stepping through tool calls, and guessing what went wrong somewhere in the middle of a long run. When an agent executes 50+ steps and makes hundreds of decisions, failures rarely have a single obvious cause.

This is where observability becomes essential.

Drift over time

An agent may start out doing exactly what you expect, then gradually veer off course due to noisy context, misinterpreted instructions, or a small mistake early on that compounds across later steps.
Cost and context visibility

Without traces, it’s hard to see where tokens spike, context balloons, or expensive branches are triggered — especially when comparing behavior across different models.
Traceable decisions

Lining up what the agent read, decided, and executed at each step makes cause-and-effect visible instead of speculative.
End-to-end execution clarity

Long-running agents blur where time and money are spent: planning, tool execution, retries, or extraction. Observability provides the full picture.

Tools like vLLora make this practical by exposing request-level traces and timelines, allowing you to see what a deep agent is actually doing across an entire run — not just the final output.

If you want to discuss observability patterns, agent anatomy, or agent tooling in more detail, join the vLLora Slack community to connect with other developers.

Key Takeaways

Deep agents fail gradually, not catastrophically
Observability turns debugging from guesswork into inspection
Cost, context, and behavior are architectural concerns
Deterministic tool execution makes long runs understandable

As deep agents become more common, observability isn’t optional — it’s the difference between hoping an agent works and knowing why it does.

Useful if you're building agents or gateways that need to support image generation with OpenAI-compatible APIs.

Mrunmay — Mon, 15 Dec 2025 05:26:22 +0000

Karolis Gudiškis

Dec 15 '25

Building AI-Powered Image Generation with OpenAI-Compatible Responses API

#llm #openai #rust #api

Comments

8 min read

Pause, Inspect, Edit: Debugging LLM Requests in vLLora

Mrunmay — Fri, 12 Dec 2025 04:18:29 +0000

LLMs behave like black boxes. You send them a request, hope the prompt is right, hope your agent didn't mutate it, hope the framework packaged it correctly — and then hope the response makes sense.
In simple one-shot queries this usually works fine. But when you're building agents, tools, multi-step workflows, or RAG pipelines, it becomes very hard to see what the model is actually receiving. A single unexpected message, parameter, or system prompt change can shift the entire run.

Today we're introducing breakpoint debugging for LLM requests in vLLora that makes this visible — and editable.

Here’s what debugging looks like in practice:

Breakpoint Debugging for LLM Requests

vLLora now supports interactive, breakpoint-style debugging for LLM requests. When debugging is enabled, every request pauses before it reaches the model.

You can:

Inspect the exact request
Edit anything
Continue execution normally

This brings a familiar software-engineering workflow ("pause -> inspect -> edit -> continue") to LLM development.

Why We Built This

If you've built anything beyond a simple chat interface, you've likely hit one of these:

Silent tool-call failures (wrong name / bad params / malformed JSON)
Overloaded or corrupted context / RAG input leading to hallucination or truncation
Error accumulation and state drift in long or multi-step workflows
Lack of visibility: standard logs rarely show the actual request sent to the model

It is difficult to fix these issues without proper observability. Breakpoint debugging changes that.

What Happens When a Request Pauses

Here's what it looks like when vLLora intercepts a request right before it's sent:

You get a real-time snapshot of:

The selected model
Full message array (system, user, assistant)
Parameters like temperature or max tokens
Any tool definitions
Any extra fields and headers your framework injected

This is the full request payload your application is about to send — not what you assume it's sending.

Edit Anything

Click Edit and the payload becomes modifiable:

You can adjust:

Message content
System prompts
Model name
Parameters
Tool definitions
Metadata

This affects only the current request. Your application code stays untouched.

It's a fast way to validate fixes, test ideas, and confirm what the agent should have sent.

Continue the Workflow

When you click Continue, vLLora:

Sends your edited request to the model
Receives the real response
Passes it back to your application
Resumes the workflow as if nothing unusual happened

After you click Continue, the workflow proceeds using the response from your edited request. The agent treats it the same way it would treat any normal response from the model.

Why This Matters for Agents

Agents are long-running chains of decisions. Each step can depend on the previous one, and each step can affect the next. Once you're 15 steps deep, you might not know whether:

The prompt changed
A system message was overwritten
A parameter was set differently than expected
The context blew up
A tool schema got mutated

With breakpoint debugging:

You catch drift early
You see exactly what the model receives
You fix issues in seconds
You avoid rerunning long multi-step workflows
You test prompt or parameter changes instantly

For deep agents, debugging becomes 10x easier.

Closing Thoughts

Debugging LLM systems has been mostly tedious. Breakpoint mode gives you a clear view into what’s happening and a way to correct issues as they occur.

If you need to understand or fix what an agent is sending, this is the most direct way to do it.

Read the docs: Debugging LLM Requests

Try it locally: Quickstart

Join Community: https://join.slack.com/t/vllora/shared_invite/zt-2haf5kj6a-d7NX6TFJUPX45w~Ag4dzlg

Designing Smart Multi-Agent Workflows with Agno & LangDB

Mrunmay — Thu, 24 Jul 2025 14:48:53 +0000

Build a multi-agent financial analysis team with LangDB and Agno that can reason, research, and report on complex financial data.

In the world of finance, staying ahead requires more than just data; it requires deep analysis, contextual awareness, and collaborative reasoning. What if you could build a team of AI agents to do this for you? In this post, we'll show you how to build a sophisticated, multi-agent financial analysis team using LangDB and Agno.

TL;DR:

This guide walks you through building a multi-agent workflow using Agno for orchestration and LangDB as the AI Gateway. We'll use a financial analysis team as a practical example to show how you can build sophisticated agent systems that are easy to manage and debug, thanks to LangDB's end-to-end tracing, dynamic tooling, and access to over 350 LLMs.

This team of agents collaborates to deliver in-depth insights on publicly traded companies by combining web research for market sentiment with hard financial data analysis. You can see a full trace of the final agent's execution.

The Code

You can find the complete source code for this project on GitHub:

LangDB Samples: https://github.com/langdb/langdb-samples/tree/main/examples/agno/reasoning-finance-team

The Architecture: A Trio of Financial Experts

Our system is composed of two specialist agents orchestrated by a coordinating team:

Web Search Agent: Gathers the latest news and market sentiment from the internet.
Finance Agent: Equipped with YFinanceTools to fetch and analyze quantitative stock data, including pricing, fundamentals, and analyst recommendations.
Reasoning Finance Team: A coordinator that directs the two agents, synthesizes their findings, and produces a final, comprehensive report.

LangDB provides the backbone for this system. As an AI Gateway, it enables seamless access to over 350 LLMs, simplifies tool integration, and provides full end-to-end tracing and observability into each agent's actions and the team's collaborative process.

Checkout: https://docs.agno.com/models/langdb and https://docs.agno.com/observability/langdb

Enhanced Tracing with `pylangdb.agno.init()`

While you can use LangDB as a provider in Agno directly, calling pylangdb.agno.init() unlocks deeper, end-to-end tracing. This function provides additional metadata and observability by automatically instrumenting the entire Agno framework, giving you complete visibility into your agent's workflows.

# main.py
from pylangdb.agno import init

# Initialize LangDB for enhanced tracing *before* importing any Agno modules.
init()

from agno.agent import Agent
from agno.team import Team
# ... other imports

As an official provider integrated with Agno, LangDB requires you to set up your credentials. You'll need to export your LangDB API key and Project ID as environment variables. You can find these in your LangDB project settings.

export LANGDB_API_KEY="<your_langdb_api_key>"
export LANGDB_PROJECT_ID="<your_langdb_project_id>"

Code Walkthrough: Building the Team

Let's look at how the agents and the team are defined.

The Web Search Agent: Decoupled and Dynamic

Instead of hard-coding a search tool, we assign the web_agent a LangDB Virtual Model. This decouples the agent's logic from the specific tools it uses.

web_agent = Agent(
    name="Web Search Agent",
    role="Search the web for the information",
    model=LangDB(id="langdb/search_agent_xmf4v5jk"),
    instructions="Always include sources"
)

This virtual model is configured in the LangDB UI to provide search capabilities, which we'll cover in the next section.

The Finance Agent: The Quantitative Analyst

This agent is equipped with YFinanceTools to access a wide range of financial data. It's powered by a powerful model like Grok-4 and has specific instructions to format its output professionally.

finance_agent = Agent(
    name="Finance AI Agent",
    role="Analyse the given stock",
    model=LangDB(id="xai/grok-4"),
    tools=[YFinanceTools(
        stock_price=True,
        stock_fundamentals=True,
        analyst_recommendations=True,
        company_info=True,
        company_news=True
    )],
    instructions=[
        "Use tables to display stock prices, fundamentals (P/E, Market Cap), and recommendations.",
        "Clearly state the company name and ticker symbol.",
        "Focus on delivering actionable financial insights."
    ]
)

The Coordinating Team: The Orchestrator

The ReasoningFinanceTeam orchestrates the two specialist agents. It operates in coordinate mode, allowing it to delegate tasks, synthesize information, and ensure the final output is a comprehensive report.

reasoning_finance_team = Team(
    name="Reasoning Finance Team",
    mode="coordinate",
    model=LangDB(id="xai/grok-4"),
    members=[web_agent, finance_agent],
    tools=[ReasoningTools(add_instructions=True)],
    instructions=[
        "Collaborate to provide comprehensive financial and investment insights",
        "Consider both fundamental analysis and market sentiment",
        "Present findings in a structured, easy-to-follow format",
    ],
    success_criteria="The team has provided a complete financial analysis with data, visualizations, risk assessment, and actionable investment recommendations."
)

Dynamic Tooling with Virtual Models and Virtual MCPs

To empower the web_agent with live web search capabilities without hard-coding tools, we configure a Virtual Model in LangDB. This model is backed by a Virtual MCP Server that provides the actual search functionality.

Create a Virtual MCP Server: In the LangDB UI, create a new Virtual MCP Server named web-search-mcp that uses the Tavily Search MCP.
Create and Configure the Virtual Model: Create a new virtual model (e.g., search-agent) and attach the web-search-mcp to it.
Use the Virtual Model ID: Copy the ID of your new virtual model and use it in the web_agent definition.

This setup allows you to change the tools and models your agents use on the fly from the LangDB UI, without changing a single line of code.

Running the Team and Observing the Results

To run the team, simply call the print_response method with a detailed prompt:

reasoning_finance_team.print_response(
    """Compare the tech sector giants (AAPL, GOOGL, MSFT) performance:\n
    1. Get financial data for all three companies\n
    2. Analyze recent news affecting the tech sector\n
    3. Calculate comparative metrics and correlations\n
    4. Recommend portfolio allocation weights"""
)

Every execution is captured in LangDB, providing a complete trace of the team's operations. This includes the initial prompt, each agent's contributions, the tools they used, and the final synthesized output. You can explore the full, shareable trace.

Here is a snippet of the final report generated by the agent team:

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃                   Comprehensive Comparative Analysis of Tech Giants: AAPL, GOOGL, and MSFT                    ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

As the Reasoning Finance Team, we've conducted a thorough analysis of Apple Inc. (AAPL), Alphabet Inc. (GOOGL), and Microsoft Corporation (MSFT) based on the user's request. This includes financial data retrieval, recent news analysis, comparative metrics and correlations, and portfolio allocation recommendations. Our evaluation incorporates fundamental analysis (e.g., valuations, growth), market sentiment (e.g., news and analyst views), quantitative metrics (e.g., betas, correlations), and risk assessments. Data is current as of July 2025.

─────────────────────────────────────────────────────────────────────────────────────────────────────────────────

                                             1. Financial Data Overview                                             

Key financial data for each company, sourced from reliable APIs.                                                  

                                                   Stock Prices                                                   

   Metric               AAPL      GOOGL     MSFT                                                                   
  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━                                                               
   Current Price        $210.16   $182.97   $505.62                                                                
   52-Week High         $260.10   $207.05   $508.30                                                                
   52-Week Low          $169.21   $140.53   $344.79                                                                
   50-Day Moving Avg    $203.87   $170.88   $472.41                                                                
   200-Day Moving Avg   $222.55   $173.43   $427.18

And here's a view of the full trace in the LangDB UI, showing how the agents collaborated to produce the report.

Full Observability with LangDB Tracing

The "full observability" promised in our subtitle is delivered through LangDB's detailed tracing capabilities. When you run your Agno team, every action is captured, providing a transparent, hierarchical view of the entire workflow. Here’s what you can see in the trace:

Hierarchical Span View: The trace isn't a flat list of events but a tree of "spans." The top-level span represents the entire team's execution, with child spans for each agent's turn, tool call, and model invocation. This shows the exact flow of control and delegation.
Input/Output for Each Step: For every span, you can inspect the exact inputs and outputs. This means you can see the precise query sent to the Web Search Agent, the articles it returned, the data requested by the Finance Agent, and the final synthesized response from the team. This level of detail is crucial for debugging.
Latency and Performance: Each span is timestamped and includes latency information, allowing you to instantly identify bottlenecks. You can see exactly how long each tool call, model response, or agent deliberation took.
Cost and Token Usage: For every LLM call, the trace displays the number of input and output tokens and the associated cost, giving you full transparency into your operational expenses.
Automatic Metadata: Thanks to pylangdb.agno.init(), traces are automatically enriched with metadata, including agent names, the team name (Reasoning Finance Team), and the models used, making it easy to filter and search for specific traces in the LangDB UI.

This granular, end-to-end visibility is what makes building, debugging, and managing complex agentic workflows with LangDB and Agno so powerful.

You can check out the full conversation with tracing here: https://app.langdb.ai/sharing/threads/630b2ded-15ae-43d9-8a7a-d6dd9d649655

Conclusion

By combining Agno with the LangDB AI Gateway, we've built a financial analysis team that is:

Modular: Each agent has a specific, firewalled responsibility.
Dynamic: We can change models and grant new tools on the fly from the LangDB UI without redeploying our agent.
Observable: We get detailed traces of every interaction, making debugging and performance analysis straightforward.

This architecture allows for rapid development and iteration, enabling you to build truly powerful and intelligent agentic systems for any domain.

Ready to build your own? Start building for free on LangDB or Explore Agno to orchestrate your agent workflows.

Discover End-to-End Tracing on Google ADK with LangDB

Mrunmay — Mon, 07 Jul 2025 04:25:59 +0000

Before diving into the code, watch this 2-minute video to see a complete demonstration of what we'll be building. You'll learn how to integrate LangDB tracing into the Google ADK Travel Concierge sample with no code chages.

In this quick demo you’ll see:

How to install and initialize the pylangdb[adk] package.
The single line of code that enables full observability for every ADK agent and tool.
Running a sample prompt like “Find me flights from JFK to London”.
Inspecting your workflow in the LangDB AI Gateway dashboard, including:
- Threads view for step-by-step conversation logs.
- Traces view for Gantt charts, cost & token breakdowns, and dependency graphs.
Drilling into any agent or tool (like the planning_agent on Claude 3 Sonnet) for full observability.

In this tutorial, we'll walk through the architecture of a sophisticated Travel Concierge agent built with Google's Agent Development Kit (ADK). We'll explore how to leverage the LangDB AI Gateway to use any LLM—from OpenAI, Google, Anthropic, and more—and harness powerful features like Virtual Models and Virtual MCPs (Model Context Protocol) to create a dynamic, observable, and easily maintainable agent system.

Our travel_concierge agent is not just a single agent; it's a hierarchy of specialized sub-agents that handle everything from vacation inspiration to booking and in-trip assistance. Here's a look at the overall architecture:

This project is based on the official Google ADK Travel Concierge sample and has been modified to showcase the integration with the LangDB AI Gateway.

You can find the complete source code for this agent on GitHub: LangDB Samples

The Magic Behind the Curtain: `pylangdb.adk.init()`

First, let's talk about the most important line of code in this integration:

# travel_concierge/agent.py
from pylangdb.adk import init
# Initialize LangDB *before* importing any ADK modules.
init()

This single function call is the key to unlocking the LangDB AI Gateway's observability features. By placing it at the very top of our script, before any google.adk modules are imported, we enable automatic instrumentation for the entire agent framework.

Here’s what init() does automatically:

Discovers Agents: It recursively finds all agent and sub-agent definitions within your project.
Patches Runtimes: It automatically patches the necessary ADK components to emit traces.
Links Sessions: It intelligently links all the interactions—from the root agent's initial processing to the deepest sub-agent and tool calls—into a single, cohesive trace in the LangDB Tracing.

This "zero-instrumentation" approach means you get complete, end-to-end visibility into your agent's complex workflows just by adding that one line of code.

The Architecture: Root Agent and Sub-Agents

Our travel_concierge is a hierarchical agent. At the top is the root_agent, which acts as a smart router or orchestrator. Its job is not to answer queries directly, but to delegate them to a specialized sub-agent.

Here's its actual definition:

# travel_concierge/agent.py
root_agent = Agent(
    model="openai/gpt-4.1",
    name="root_agent",
    description="A Travel Conceirge using the services of multiple sub-agents",
    instruction=prompt.ROOT_AGENT_INSTR,
    sub_agents=[
        inspiration_agent,
        planning_agent,
        # ... and other sub-agents
    ],
    # ...
)

As you can see, it uses a standard model ("openai/gpt-4.1") and has a list of sub_agents. It doesn't have any tools of its own. The real power comes from the sub-agents.

Dynamic Tooling with Virtual Models and Virtual MCPs

A LangDB Virtual Model is a powerful abstraction that decouples your agent's code from its runtime configuration. It acts as a pointer to a configuration that you can manage entirely from the LangDB UI.

This is where the Model Context Protocol (MCP) comes in. MCP is a standard that allows language models to interact with external tools and services in a uniform way. However, managing connections to multiple MCP-enabled tools can be complex.

The LangDB AI Gateway simplifies this with Virtual MCP Servers. A Virtual MCP is a single, managed endpoint that you configure in the UI. It can bundle multiple tools (like Google Maps, Tavily Search, or your own custom APIs), handle their authentication securely, and lock them to specific versions.

You then connect this Virtual MCP to your agent's Virtual Model. This is how you can dynamically grant new capabilities to your agents without changing a single line of code.

Here are all the virtual models for our project, as seen in the LangDB AI Gateway dashboard. You can see the inspiration_agent, google_search_agent, and planning_agent all configured here, ready to be assigned to our agents.

Example: The `inspiration_agent` and Google Maps

Let's look at our inspiration_agent. It needs access to location data to give travel ideas. Instead of hardcoding a Google Maps MCP, we use a Virtual Model.

Here's the agent's definition:

# travel_concierge/sub_agents/inspiration/agent.py
inspiration_agent = Agent(
    model= "langdb/inspiration_agent_z73m3wmd",
    name="inspiration_agent",
    description="A travel inspiration agent...",
    # ...
)

Notice its model is langdb/inspiration_agent_z73m3wmd. In the LangDB AI Gateway UI, we've configured this virtual model to use a Virtual MCP server that has the Google Maps API attached as a tool. Now, when the inspiration_agent is active, it can seamlessly query Google Maps, even though the tool isn't explicitly listed in its code.

Example: Grounding with Google Search

We also have a specialized agent tool for web searches, google_search_grounding.

# travel_concierge/tools/search.py
_search_agent = Agent(
    model= "langdb/google_search_agent_hsz7lf9q",
    name="google_search_grounding",
    description="An agent providing Google-search grounding capability",
    # ... instruction ...
)

google_search_grounding = AgentTool(agent=_search_agent)

Just like our inspiration_agent, the _search_agent uses a virtual model, langdb/google_search_agent_hsz7lf9q. We've attached a Virtual MCP server that provides the Tavily Search tool to this model in LangDB.

Example: The `planning_agent` for Flights and Hotels

Finally, let's look at the planning_agent, which handles the core booking tasks.

# travel_concierge/sub_agents/planning/agent.py
planning_agent = Agent(
    model="langdb/planning_agent_w1l8sygt",
    name="planning_agent",
    description="Helps users with travel planning...",
    # ...
)

This agent's virtual model, langdb/planning_agent_w1l8sygt, is connected to a Virtual MCP that provides an Airbnb search tool. This allows the agent to handle complex booking-related queries by leveraging this external service, all without having the tool logic hardcoded in the agent's definition.

The Flow: From Query to Answer

A user asks the travel_concierge: "What are some good museums to visit in Paris?"
The root_agent receives the query and, based on its instructions, delegates the task to the inspiration_agent.
The inspiration_agent is activated. Its virtual model configuration is loaded from the LangDB AI Gateway.
The agent now knows it has access to the Google Maps tool (via its Virtual MCP).
It uses the tool to find museums in Paris and provides a list to the user.
All of these steps—the delegation, the model calls, the tool usage—are automatically captured as traces in the LangDB AI Gateway, giving us complete observability into our agent's behavior.

You can explore a complete, shareable trace of a conversation with this agent here: https://app.langdb.ai/sharing/threads/8425e068-77de-4f41-8aa9-d1111fc7d2b7

When you open the trace, you'll see a detailed breakdown of the entire workflow. This includes:

A Gantt chart visualizing the sequence and duration of each agent and tool invocation.
Cost and token counts for every LLM call, helping you monitor usage and optimize performance.
Detailed input/output payloads for each step, allowing you to inspect the exact data being passed between components.
A dependency graph showing how agents and tools are interconnected, making it easy to debug complex interactions.

Conclusion

By combining Google ADK with the LangDB AI Gateway's virtual models and MCPs, we've built a travel_concierge agent that is:

Modular: Each sub-agent has a specific responsibility.
Dynamic: We can change models and grant new tools on the fly from the LangDB UI without redeploying our agent.
Observable: We get detailed traces of every interaction, making debugging and performance analysis easy.

This architecture allows for rapid development and iteration, enabling us to build truly powerful and intelligent agentic systems.

Ready to build your own? Check out the LangDB AI Gateway documentation to get started

Supercharging AI Code Editors with LangDB Virtual MCP Servers

Mrunmay — Sun, 18 May 2025 19:09:59 +0000

In my last post, we explored how AI editors like Cursor and Windsurf can build real dashboards by pulling from Figma and Supabase with minimal coding.

This time, I wanted to dig deeper into a growing challenge: managing the increasing number of external tools and APIs these editors rely on.

This is where LangDB Virtual MCP Servers come in.

They simplify how editors access and use services like Supabase, GitHub, Figma, and Context7, making AI-driven coding workflows cleaner, faster, and easier to manage.

The Problem: Tool Explosion

Supabase MCP alone exposes over 28 tools for database access, migrations, authentication, and more.

If my AI editor connects to multiple services, I quickly end up juggling:

Multiple endpoints
Separate credentials
Different tool versions
Configuration overhead for each connection

The more tools I connect, the harder it becomes to maintain clean, stable, and efficient workflows.

The Solution: LangDB Virtual MCP Server

A Virtual MCP Server lets me:

Select only the tools I actually need. I am not forced to expose all 26 Supabase tools if I only need 10.
Merge them into a single endpoint. My editor sees one clean interface instead of dozens.
Centralize credentials, scopes, and tool versions. I can manage everything from a single place.

In short: it compresses multiple messy connections into one smart, easy-to-manage access point.

How I Used Virtual MCP in My Café Rewards Project

When building the Café Rewards dashboard, I wanted my AI editor to:

Query metrics like offer completion rates and transaction counts
Understand database schema for customers, offers, and events
Fetch only necessary information for rendering dashboard charts

But I didn't want:

28 Supabase tools cluttering up the prompt space
Credential sprawl across dozens of connections
Extra latency from calling multiple services separately

Using LangDB Virtual MCP Server:

Selected 10 essential Supabase tools like execute_sql, get_anon_key, and list_tables.
Built a Virtual MCP config listing only those tools.
Launched a single endpoint that my Windsurf editor could connect to easily.

Simple, clean, and highly specific.

The Benefits I Saw

Cleaner prompts: Only relevant tools appear in the editor’s suggestions.
Faster responses: No extra negotiation overhead across 28+ tools.
Simpler management: One place to rotate credentials, upgrade tool versions, or adjust scopes.
Fewer bugs: Fewer moving parts means fewer integration errors during development.

The end result? A smoother, faster AI-driven frontend build with fewer obstacles between code, design, and data.

Want to Set Up Your Own?

📄 LangDB MCP Servers: https://app.langdb.ai/mcp-servers

📄 LangDB Docs: Virtual MCP Servers

Whether you're building a dashboard, orchestrating backend workflows, or speeding up frontend builds, a Virtual MCP Server can help your AI editor stay smart, lightweight, and maintainable.

MCPs changed how editors code. Virtual MCPs make scaling that change possible.

Frontend Web Dev Is Dead (Thanks to Figma + Supabase MCP)

Mrunmay — Tue, 13 May 2025 18:31:44 +0000

Frontend development used to be a craft of its own—spending countless hours adjusting margins, wrestling CSS grids, translating Figma designs into pixel perfect components, and stitching together endless APIs. Every new project felt like starting from scratch.

But things are changing faster than most realize.

With the rise of AI code editors like Cursor and Windsurf, combined with the power of the Model Context Protocol (MCP), frontend workflows are moving into a new era, one where design, data, and logic can be orchestrated instead of handcrafted.

TL;DR: I built a real-time Café Rewards Dashboard using Windsurf, Figma, Supabase, and LangDB's Virtual MCP Server. No writing code manually, only vibe coding. Check out the live project.

The Problem With Old-School Frontend

Mockups drift. What designers meticulously create in Figma rarely survives the journey into production untouched.
Boilerplate hell. Building every form, chart, and dashboard manually from designs wastes enormous time.
API complexity. Wiring up dozens of endpoints, handling different SDKs, tokens, and data transforms bloats the frontend unnecessarily.
Lost developer time. Instead of solving real user problems, most of the work is recreating layouts and plumbing API calls.

Developers weren't inefficient. They were stuck doing tedious work because there was no better system.

The Shift: Figma MCP + Supabase MCP

Now, AI editors can read real-time design structures and database schemas directly inside your coding environment.

Figma MCP lets your editor pull live design tokens, layouts, typography, and component structure from Figma.
Supabase MCP allows structured access to your database, helping the editor understand data models, write correct SQL queries, and generate APIs.

Instead of guessing how the UI should look or crafting APIs manually, the editor becomes an orchestrator:

It reads the intended design structure.
It understands the database schema.
It generates the right frontend code, data queries, and connections.

Frontend stops being interpretation. It becomes execution.

If you want a deeper dive into how MCPs are reshaping coding workflows, check out our earlier breakdown here: Smarter Coding Workflows with MCP

Real-World Example: Building the Café Rewards Dashboard

In my recent project, I set out to build a real-time analytics dashboard for a fictional Café Rewards program.

Using Windsurf as the code editor and connecting to Figma MCP and Supabase MCP, the workflow was straightforward:

Pull the live dashboard layout from the Figma file.
Query the customer offers, demographics, and events data from Supabase.
Map the fetched data directly into the live dashboard design structure.

Design Foundation:

Link to Figma template: https://www.figma.com/community/file/1355536424065701712/dashboard-info-graphics

Data Foundation:

Link to dataset: https://mavenanalytics.io/challenges/maven-rewards-challenge/404c6060-60eb-400f-9bce-c3b9f97e9d5a

Tech Stack Overview

Frontend: Next.js + TypeScript, styled with TailwindCSS
Data: Supabase MCP
Design: Figma MCP
Docs (optional): Context7 MCP
Unification: LangDB's Virtual MCP Server to merge all sources under a single endpoint

Prompt Used:

Example Editor Prompt:

You are working in a Next.js + TypeScript + Tailwind project.

**Goal:**  
Build a frontend analytics dashboard that showcases key metrics from the Café Rewards dataset. All the data is already stored in a Supabase (Postgres) database and accessible via a Supabase MCP endpoint.

**You have:**  
- A running Next.js app (basic setup complete)  
- TailwindCSS already configured  
- Access to Supabase via MCP (SQL execution through an API)  
- A Figma file that serves as the design reference (read-only access via Figma MCP): Figma Link
- Optionally, context7 for live documentation 

**Database Tables:**  
- `offers`: details of promotional offers (bogo, discount, informational)  
- `customers`: demographics like gender, income, signup date  
- `events`: logs of offer received/viewed/completed + transactions

**What you want to build:**  
A dashboard that shows these metrics:
1. **KPIs**: overall completion rate, completion by offer type
2. **Trends**: weekly avg transactions, weekly total transactions
3. **Demographics**: income range vs avg. spending
4. **Summaries**: total transactions

**Your job:**  
- Use the Supabase MCP to run SQL queries and create api endpoints for metrics
- Render all metrics as cards/charts using React + Tailwind  
- Use Figma MCP to inspect layout tokens or design spacing if needed  
- Do not attempt to write to Figma—read-only reference only  
- Return a complete, functional dashboard at `/` when someone runs `npm run dev`

Only fetch, transform, and render data visually using components—this is a read-only analytics frontend based on live database values.

This single prompt tells your AI editor to fetch data and wire the dashboard layout automatically.

No manual recreation. No trial-and-error styling. No repetitive API wiring.

Live Demo: Visit the Café Rewards Dashboard

Why This Changes Frontend Forever

AI-powered code editors like Cursor and Windsurf are here to stay. MCPs are the next logical step—giving these editors access to the real sources of truth: the design file and the database.

The benefits are clear:

Live integration. Layouts and data models are fetched and understood natively.
Zero manual boilerplate. Focus only on business logic and UX improvements.
Consistent fidelity. UIs match exactly what designers created.
Developer velocity. Spend less time wiring things up and more time shipping features.
Frontend isn't dead. It's evolving—toward self-orchestrating, AI-powered workflows.

Closing Thoughts

If you're still hand-coding every UI detail based on static mockups and manually stitching APIs together, you're already a step behind.

AI coding workflows are the future.

In this new world, your code editor:

Reads Figma designs as a source of layout truth.
Understands database schemas to generate correct data flows.
Builds components and APIs naturally, without endless manual plumbing.

The next generation of frontend is here. It's faster, smarter, and less about handcrafting code—and more about orchestrating data, design, and user experience together.

Curious to learn how to use LangDB Virtual MCP? Stay tuned for Part 2!

Choose the right AI model: Comparision of gpt-4o, claude and gemini using LangDB

Mrunmay — Thu, 27 Feb 2025 11:49:55 +0000

Wondering which model to pick for your AI integration? It often comes down to response quality, time, and cost. LangDB’s Chat lets you compare GPT, Claude, and Gemini and many other models side by side:

Send identical prompts to all three models in one interface.
Analyze response accuracy, coherence, and tone.
Measure execution time, latency, and cost.

Chat Interface in LangDB

Query: "Summarize the potential risks and benefits of AI-driven automated trading in financial markets, focusing on efficiency, transparency, and ethical concerns."

LangDB provides detailed insights into the API calls made to various providers. Here's an example of a traces in LangDB:

Model	Execution Time	Cost
GPT-4o	12.44 sec	$0.637
Claude 3.5 Sonnet	11.40 sec	$0.013
Gemini 1.5 Pro	7.47 sec	$0.384

These metrics allow developers to track performance, latency, and associated costs for each model efficiently.

Supported Models

Why Perform Model Comparisons?

Directly comparing LLMs helps developers:

Select the Best Model: Choose the model that performs best for your specific use case.
Optimize Costs and Performance: Compare API costs, execution times, and token efficiency.

LangDB’s Chats feature eliminates the operational friction of testing models. It provides a clean, user-friendly platform for experimenting with the latest AI models without any extra configuration.

Get Started with LangDB

Stop guessing which model works best—test them side by side with LangDB Chats. Compare the latest and best AI models effortlessly, optimize performance, and unlock new possibilities without writing or managing infrastructure.

Start building smarter AI systems today—and let LangDB handle the heavy lifting.

How to Integrate LangChain with LangDB

Mrunmay — Thu, 27 Feb 2025 11:06:50 +0000

LangDB integrates seamlessly with libraries like LangChain to provide advanced tracing and logging support for workflows, allowing developers to streamline the development process while maintaining detailed logs. If you're familiar with LangChain, adding LangDB to your workflow can offer enhanced functionality without adding complexity.

In this blog post, we'll walk through how to use LangDB with LangChain, including a practical example. By the end, you'll understand how to capture detailed logs and take advantage of LangDB’s features in your own LangChain projects.

Pre-requisites

Tavily API token
OpenAI API token
Python v3.11
Pip packages: langchain (at least v0.1.0), openai, wikipedia, langchain-community, tavily-python, langchainhub, langchain-openai, python-dotenv

pip install langchain wikipedia langchain-community tavily-python langchainhub langchain-openai openai python-dotenv

Example: Using LangDB with LangChain

Below is an example of how you can integrate LangDB into your LangChain workflow. The integration is designed to be as simple as possible, letting you focus on writing logic without worrying about setup complexities.

from langchain import hub
from langchain.agents import (
    AgentExecutor,
    create_tool_calling_agent,
)
from langchain_openai import ChatOpenAI
import os
from langchain_community.agent_toolkits.load_tools import load_tools
from langchain_community.tools.tavily_search.tool import TavilySearchResults
from langchain_community.utilities.tavily_search import TavilySearchAPIWrapper
import uuid


api_base = "https://api.us-east-1.langdb.ai"  ### LangDB API base URL
pre_defined_run_id = uuid.uuid4()
default_headers = {
    "x-project-id": "xxxxx",  ### LangDB Project ID
    "x-thread-id": str(pre_defined_run_id),
}
os.environ["OPENAI_API_KEY"] = "xxxx"  ### LangDB API key
os.environ["TAVILY_API_KEY"] = "tvly-xxxx"


def get_function_tools():
    search = TavilySearchAPIWrapper()
    tavily_tool = TavilySearchResults(api_wrapper=search)

    tools = [tavily_tool]

    tools.extend(load_tools(["wikipedia"]))

    return tools


def init_action():
    llm = ChatOpenAI(
        model_name="gpt-4o-mini",
        temperature=0.3,
        openai_api_base=api_base,
        default_headers=default_headers,
        disable_streaming=True,
    )
    prompt = hub.pull("hwchase17/openai-functions-agent")
    tools = get_function_tools()
    agent = create_tool_calling_agent(llm, tools, prompt)
    agent_executor = AgentExecutor(agent=agent, tools=tools, verbose=True)
    agent_executor.invoke(
        {"input": "Who is the owner of Tesla company? Let me know details about owner."}
    )


init_action()

In this example:

We define an API base URL for LangDB (api_base), which points to the LangDB.
We add a project-id to the headers to specify the LangDB project being used, and a thread-id to create a unique thread for tracking and logging the execution within LangDB.
Once executed, the agent is able to process an input query ("Who is the owner of Tesla company? Let me know details about owner.") and use the tools integrated into the agent, like Tavily search and Wikipedia.

Dynamic Model Switching

One of LangDB’s most powerful features is the ability to seamlessly switch between different models without major changes in the existing codebase. In the above example, if you want to use Claude 3.5 Sonnet, all you need to do is update the model name in your configuration:

# Switch to Anthropic's Claude model
llm = ChatOpenAI(
    model_name='claude-3-sonnet-20240229',  # Change model here
    temperature=0.3, 
    openai_api_base=api_base, 
    default_headers=default_headers
)

With this small change, LangDB takes care of the rest, ensuring that your application can dynamically adapt to new models without the need for rewriting large parts of your codebase.

Tracing in LangDB

LangDB’s tracing feature provides real-time visualizations of your AI workflows, breaking down the time spent in each stage. The trace shows key stages like:

API Invoke: Total time for the request.
Model Call: Time spent interacting with the model.
Tool Usage: Duration of specific tool calls.

The trace visualization below highlights these stages, helping you identify bottlenecks and optimize your workflow.

This detailed view makes it easier to diagnose performance issues and fine-tune your LangChain integrations.

Conclusion

Using LangDB with LangChain is a powerful yet straightforward way to manage and trace your AI workflows. By leveraging LangDB’s capabilities, you can focus on developing complex workflows without worrying about the operational overhead. The ability to seamlessly switch between models also ensures that you can stay agile as new AI technologies emerge.

Start integrating LangDB with LangChain today, and enjoy the flexibility and scalability it offers; Check out LangDB!

Why We Built an AI Gateway in Rust: A Performance-Centric Decision

Mrunmay — Thu, 13 Feb 2025 18:44:14 +0000

When building our AI gateway, we knew performance would be a critical factor. Unlike most AI software written in Python, an AI gateway acts as the proxy layer between users and inference engines. This gateway must handle high concurrency, low latency, and large data volumes efficiently. Python, while dominant in the AI ecosystem, struggles under these demands due to its runtime overhead and limitations with concurrency.

To demonstrate why we chose Rust, we benchmarked three popular programming environments—Rust, Python, and JavaScript (Node.js)—to evaluate their performance under high-load conditions. Rust emerged as the clear winner, offering predictable and stable performance even at scale.

Benchmark Setup: Simulating Real-World AI Traffic

We built an HTTP/2 streaming server and a corresponding client to mimic real-world AI workloads. Here’s how the setup worked:

Server:

Streams tokens at a fixed inter-token latency of 25ms, similar to the tokenized output of an AI inference engine.
Uses HTTP/2 to deliver tokenized data efficiently to multiple clients.
Implements asynchronous programming to support thousands of connections concurrently.

Client:

Gradually establishes up to 15,000 simultaneous connections to the server.
Measures the intra-token latency—the time between consecutive tokens received from the server. This metric reflects the server’s ability to scale under increasing load.
Ensures that connections remain stable and records latency for each connection.

Test Workflow:

The server was implemented in Rust, Python, and JavaScript (Node.js) to ensure a fair comparison.
The client progressively increased the number of active connections, starting with a small number and scaling up to 15,000.
Intra-token latency measurements were collected for each implementation to evaluate performance under load.

Results: Rust vs. Python vs. JavaScript (Node.js)

The chart below illustrates the intra-token latency (in milliseconds) as the number of concurrent connections increases:

Key Observations:

Rust:
- Rust exhibited the most stable performance, maintaining a near-linear increase in latency as connections scaled.
- At 15,000 connections, Rust's intra-token latency reached approximately 75ms, only 3x the baseline inter-token latency of 25ms.
- Rust’s efficiency highlights its ability to handle high concurrency without significant degradation.
Python:
- Python's intra-token latency grew exponentially, exceeding 200ms at 15,000 connections.
- This exponential growth demonstrates Python's inherent limitations in managing large-scale concurrency and resource contention.
JavaScript (Node.js):
- Node.js initially performed better than Python, maintaining lower latency up to 7,500 connections.
However, its performance began to degrade significantly beyond this point, reaching over 150ms at 15,000 connections.
- This result underscores Node.js’s event-driven model, which works well for moderate concurrency but struggles under extreme loads.

Why Rust is the Best Choice for an AI Gateway

Predictable, Scalable Performance:

Rust’s ability to maintain 75ms latency at 15,000 connections demonstrates its scalability. Its near-linear latency growth makes it ideal for high-concurrency systems.
Concurrency Without Compromise:

Rust’s async programming model (e.g., Tokio) efficiently manages thousands of simultaneous connections. Unlike Python, Rust avoids the bottlenecks of the Global Interpreter Lock (GIL) and utilizes system resources optimally.
Resource Efficiency:

Rust compiles directly to machine code, ensuring minimal runtime overhead. Its memory safety and zero-cost abstractions allow for predictable and efficient resource management.
Low-Level Control:

Rust provides fine-grained control over threading and memory, making it the best choice for performance-critical applications like AI gateways.

Why Python and JavaScript Fall Short

Python:

Concurrency Limitations: The GIL prevents true multi-threading, causing severe bottlenecks under high load.

Runtime Overhead: Python's interpreted nature adds significant latency, making it unsuitable for latency-sensitive applications.

Exponential Growth: As connections increase, Python's performance deteriorates rapidly, with latency exceeding acceptable thresholds.
JavaScript (Node.js):

Event-Driven Model: Node.js performs well under moderate concurrency but struggles as the number of simultaneous connections grows beyond 7,500.

Resource Contention: While Node.js handles asynchronous I/O well, it lacks the low-level control offered by Rust, leading to degraded performance at scale.

Why AI Gateways Must Be Built with Performance in Mind

An AI gateway is more than a simple intermediary. It plays a critical role in ensuring:

Real-Time Responses: Users expect tokenized outputs to arrive with minimal delay, making low latency essential.
Scalability: AI gateways must handle thousands or tens of thousands of simultaneous connections to accommodate large-scale applications.
Reliability: Inconsistent performance or connection drops can severely impact user experience and application reliability.

Rust excels in all these areas, delivering predictable, stable performance at scale, making it the ideal language for building high-performance AI gateways.

The Takeaway: Rust is the Future of AI Gateways

Our benchmark results clearly show that while Python and JavaScript (Node.js) have their strengths, they are ill-suited for building performance-critical AI gateways:

Python struggles with concurrency and runtime overhead, leading to exponential latency growth.
Node.js performs better but falters under extreme loads, making it unreliable for high-concurrency scenarios.

Rust, on the other hand, delivers consistent, scalable performance with low latency, even at 15,000 connections. By choosing Rust for our AI gateway, we’ve built an infrastructure that can handle the demands of modern AI applications with ease.

If you’re building an AI gateway or any performance-critical infrastructure, Rust isn’t just an option—it’s the solution. When every millisecond matters, Rust is the language that ensures you meet the challenge head-on.

Introduction to AI Gateway

Mrunmay — Tue, 10 Dec 2024 17:04:23 +0000

Rise Of LLMs

In the ever-evolving landscape of technology, few innovations have created waves as transformative as artificial intelligence (AI).

The rise of AI—fueled by large language models (LLMs)—is reshaping how we think about software, automation, and the user experience. Much like the pivotal shifts brought by mobile computing, cloud infrastructure, and microservices architecture, AI represents a foundational shift in how we design and deliver technology.

As we embrace this new era of AI, large language models are not just reshaping what’s possible—they’re redefining how we approach technology itself. However, this transformation is only as strong as the underlying frameworks that support it. APIs, as the silent workhorses of modern software, serve as the crucial bridge connecting AI’s potential with real-world applications, ensuring its seamless integration into the fabric of our digital ecosystem.

What is an AI Gateway

An AI Gateway is a middleware platform that simplifies the integration, management, and scaling of artificial intelligence (AI) models and services within an organization’s IT infrastructure. It serves as a critical bridge between AI systems—such as large language models (LLMs)—and the applications or services that consume them.

LangDB’s AI Gateway provides a simplified way to connect with multiple Large Language Models (LLMs) using a single line of code. It’s designed to help developers integrate and manage LLMs efficiently while keeping operations cost-effective.

Key Features of LangDB's AI Gateway

LangDB’s AI Gateway provides developers with a practical, streamlined solution for integrating and managing LLMs. Here’s how it stands out:

Cost Management: Gain control over LLM usage by tracking and optimizing spending, ensuring cost-effective operations.
Dynamic Routing: Automatically route requests to the most suitable LLM based on performance, cost, or availability, optimizing results.
Scalability: Seamlessly scale your AI integrations across projects and environments without added complexity.
Seamless Integration: Connect with multiple AI providers using a single line of code, reducing development overhead and increasing productivity.
Future-Ready: Stay adaptable as new LLMs emerge, ensuring your workflows remain at the cutting edge of AI technology.

Built with developers in mind, LangDB’s AI Gateway empowers you to integrate multiple AI models using just a single line of code. Whether you’re scaling enterprise applications or experimenting with new AI tools, LangDB ensures your workflows are efficient, cost-effective, and future-ready.

Conclusion

As AI adoption grows, LangDB’s AI Gateway simplifies the process, helping developers focus on building smarter, faster applications without operational overhead. By offering seamless integration, cost optimization, and scalable solutions, it reduces complexity and empowers developers to focus on innovation and delivering impactful results.

Exploring Different Chunking Strategies and Working with Unstructured Data

Mrunmay — Fri, 23 Aug 2024 04:13:32 +0000

LangDB provides a powerful arsenal of functions for developers to deal with unstructured data. These functions are designed to streamline common tasks in data extraction, and text chunking. Let's dive into some of the key functions and see how they can make your life easier.

load

The load function converts any webpage/file into bytes. These bytes can be used to extract text or layout from the file/webpage.

SELECT * FROM load('s3://sample-onlineboutique-codefiles/onlineboutique-codefiles/just-deserts-spring-obooko-small.pdf');

content
[37,80,68,70,45,49,46,54,10,37,-30,-29,-49,-45,10,53,32,48,32,111,98,106,10,60,60,10,47,66,77,32,47,78,111,114,109,97,108,10,47,99,97,32,49,10,62,62,10,101,110,100,111,98,106,10,56,32,48,32,111,98,106,10,60,60,10,47,70,105,108,116,101,114,32,47,70,108,97,116,101,68,101,99,111,100,101,10,47,76,101,110,103,116,104,32,50,57,54,10,47,78,32,51,10,62,62,10,115,116,114,101,97,109,10,120,-100,125,-112,-67,74,-61,96,20,-122,31,107,65,20,-59,65,-121,14,14,25,28,92,-44,-2,104,127,-64,-91,-83,88,92,91,-123,86,-89,52,77,-117,-40,-97,-112,-90,-24,5,-24,-26,-32,-22,38,46,-34,-128,-24,101,40,8,14,-30,-32,37,-120,-96,-77,111,26,36,5,-87,-25,-16,-26,123,120,-13,-110,47,-25,64,36,-122,42,26,-121,78,-41,115,-53,-91,-126,81,-83,29,24,83,-17,76,-88,-121,101,90,125,-121,-15,-91,-44,-9,75,-112,125,94,-3,39,55,-82,-90,27,118,-33,-46,-7,33,121,-82,46,-41,39,27,-30,-59,86,-64,-89,62,-41,3,-66,-16,-7,-60,115,60,-15,-75,-49,-18,94,-71,40,-66,19,-81,-76,70,-72,62,10]

content

[37,80,68,70,45,49,46,54,10,37,-30,-29,-49,-45,10,53,32,48,32,111,98,106,10,60,60,10,47,66,77,32,47,78,111,114,109,97,108,10,47,99,97,32,49,10,62,62,10,101,110,100,111,98,106,10,56,32,48,32,111,98,106,10,60,60,10,47,70,105,108,116,101,114,32,47,70,108,97,116,101,68,101,99,111,100,101,10,47,76,101,110,103,116,104,32,50,57,54,10,47,78,32,51,10,62,62,10,115,116,114,101,97,109,10,120,-100,125,-112,-67,74,-61,96,20,-122,31,107,65,20,-59,65,-121,14,14,25,28,92,-44,-2,104,127,-64,-91,-83,88,92,91,-123,86,-89,52,77,-117,-40,-97,-112,-90,-24,5,-24,-26,-32,-22,38,46,-34,-128,-24,101,40,8,14,-30,-32,37,-120,-96,-77,111,26,36,5,-87,-25,-16,-26,123,120,-13,-110,47,-25,64,36,-122,42,26,-121,78,-41,115,-53,-91,-126,81,-83,29,24,83,-17,76,-88,-121,101,90,125,-121,-15,-91,-44,-9,75,-112,125,94,-3,39,55,-82,-90,27,118,-33,-46,-7,33,121,-82,46,-41,39,27,-30,-59,86,-64,-89,62,-41,3,-66,-16,-7,-60,115,60,-15,-75,-49,-18,94,-71,40,-66,19,-81,-76,70,-72,62,10]

extract_text

The extract_text() function extracts text from various file types, with specific options available for PDF files.

Parameters

Parameter	Type	Optional	Description	Possible Values	Sample Value
`path`	String	No	The file path to extract text from	Any valid URL	`'https://example.com'`
`type`	String	Yes	Type of file	PDF, Markdown, Text, HTML	`'pdf'`
`page_rage`	Array(Int)	Yes	Extra parameter for PDF file type for the range of page numbers	Array of Start and Ending page numbers	[1, 10]
`per_page`	Bool	Yes	Extra parameter for PDF file type to chunk per Page	true, false	true

Usage with `load` function

SELECT * FROM extract_text((SELECT * from load('s3://sample-onlineboutique-codefiles/onlineboutique-codefiles/just-deserts-spring-obooko-small.pdf')),
    type => 'pdf' ,
    per_page => false
);

content	metadata	page_no
JUST DESERTS Aniela Spring © Copyright Aniela Spring 2024 This is an authorised free edition from www.obooko.com Although you do not have to pay for this book, the author’s intellectual property rights remain fully protected by international Copyright laws. You are licensed to use this digital copy strictly for your personal enjoyment only: it must not be redistributed commercially or offered for sale in any form. If you paid for this free edition, or to gain access to it, we suggest you demand an immediate refund and report the transaction to the author and Obooko. All characters are fictitious and any resemblance to real persons, living or dead, is utterly coincidental. 1	{"total_pages":2,"page_range":"(0, 2)"}	0

These all functions are best suited for raw text. However, if you want to get the layout information from a document, LangDB has support for it too.

extract_layout

The extract_layout function enables structured data extraction with layout information from a document.

Parameters

Parameter	Type	Optional	Description	Possible Values	Sample Value
`path`	String	No	The file path to extract text from	Any valid file URL	'https://example.pdf'
`type`	String	Yes	Type of file	Raw, PDF, Image	'pdf'
`page_range`	Array(Int)	Yes	Extra parameter for PDF file type for the range of page numbers	Array of Start and Ending page numbers	[1, 10]
`parallelism`	Int	Yes	Extra parameter for PDF file type to process pages parallelly	2, 4, 5	2

Extracting Layout information from a PDF

SELECT * FROM extract_layout(
    path => 's3://sample-onlineboutique-codefiles/onlineboutique-codefiles/just-deserts-spring-obooko-small.pdf',
    type=> 'pdf'
);

block_idx	block_id	block_type	text	confidence	entity_types	relationships
0	c7261e9c-be58-4776-a1de-70adf6e4e6e6	PAGE		0	[]	[["CHILD",["23112b0d-4062-424d-bbb3-4f4aa82f4d80","3e3c5562-b018-4f75-85d9-6e7771489ba0","f08a9210-eedb-4150-99e2-a5d22b26e029","f3087bee-7680-4024-aeff-60ab0bdc1dac"]]]
1	23112b0d-4062-424d-bbb3-4f4aa82f4d80	LINE	Don't forget about your past, because it never forgets about you.	99.88849	[]	[["CHILD",["102e10d5-fd45-46ee-9890-b70279c6e532","af6bad3a-34fc-462e-9033-c1af2bd5aa1a","aab2849a-4a4b-499c-a16f-43c55fb5dffd","78ef1f76-d8a5-413f-be87-cff88194b7e1","9f41e657-f307-487f-872e-569272305ad4","01ae2b2a-755f-4ef9-9ddc-24eaefbaabd4","7484031d-5259-48ad-a3c7-bbcb862d34f0","783ddab6-47a3-48aa-b56b-adc564daa8cd","d7a69ab3-c601-4d9d-9632-7d4f176b2462","d8f537c7-4c64-4a01-9792-088660b1631d","fb7ad2cb-e72d-4013-8399-fa32d46cb21d"]]]
2	3e3c5562-b018-4f75-85d9-6e7771489ba0	LINE	JUST DESERTS	98.635315	[]	[["CHILD",["5e4fc404-7326-4195-a3d7-343a4dea7a8f","f3efd0b2-0c54-49bc-9867-6830eab05403"]]]
3	f08a9210-eedb-4150-99e2-a5d22b26e029	LINE	ANIELA SPRING	99.87999	[]	[["CHILD",["f4e95636-470f-45eb-a599-4d3e00f754d6","5e8676d2-f90c-4455-b179-083da72c647e"]]]
4	102e10d5-fd45-46ee-9890-b70279c6e532	WORD	Don't	99.96765	[]	[]
5	af6bad3a-34fc-462e-9033-c1af2bd5aa1a	WORD	forget	99.908676	[]	[]
6	aab2849a-4a4b-499c-a16f-43c55fb5dffd	WORD	about	99.9353	[]	[]
7	78ef1f76-d8a5-413f-be87-cff88194b7e1	WORD	your	99.92315	[]	[]
8	9f41e657-f307-487f-872e-569272305ad4	WORD	past,	99.73978	[]	[]
9	01ae2b2a-755f-4ef9-9ddc-24eaefbaabd4	WORD	because	99.9515	[]	[]

Extracting Layout information from an Image

Similarly, you can extract layout information from an image through the following code:

SELECT * FROM extract_layout(
    path => 'https://langdb-sample-data.s3.ap-southeast-1.amazonaws.com/Screenshot+from+2024-08-09+09-49-18.png',
    type => 'image'
);

chunk

The chunk function breaks down large texts into smaller, manageable pieces. This is particularly useful for processing long documents, especially when working with models that have input size limitations.

Parameters

Parameter	Type	Optional	Description	Possible Values	Sample Value
`raw_text`	String	No	The raw text which needs to be chuncked	Any String	'In a quaint village...'
`type`	String	No	Unit of chunking	Char, Word, Sentence, Paragraph	'Char'
`chunk_size`	Int	Yes	Number of units to be present in a Chunk	Any non-negative integer	100
`overlap`	Int	Yes	Number of units to overlap between consecutive chunks	Any non-negative integer	20
`trim`	Bool	Yes	Whether to trim whitespace from the start and end of each chunk	true, false	true

Chunking Raw text into Char with Chunk Size

SELECT * FROM chunk('In a quaint village nestled in the heart of the countryside, there lived a young girl named Lily. She was known throughout the village for her vibrant imagination and her love for adventure. Every day, Lily would set out to explore the lush forests and rolling hills that surrounded her home, always eager to discover something new and exciting.

One particularly sunny morning, Lily decided to venture deeper into the woods than she ever had before. As she walked, she stumbled upon a hidden grove filled with the most beautiful flowers she had ever seen. The colors were so vivid and the petals so delicate that Lily couldnt help but marvel at their beauty. She spent hours in the grove, carefully examining each flower and breathing in their sweet fragrance.',
    type => 'Char',
    trim => true,
    chunk_size => 200);

text	index
In a quaint village nestled in the heart of the countryside, there lived a young girl named Lily. She was known throughout the village for her vibrant imagination and her love for adventure.	0
Every day, Lily would set out to explore the lush forests and rolling hills that surrounded her home, always eager to discover something new and exciting.	1
One particularly sunny morning, Lily decided to venture deeper into the woods than she ever had before.	2
As she walked, she stumbled upon a hidden grove filled with the most beautiful flowers she had ever seen.	3
The colors were so vivid and the petals so delicate that Lily couldnt help but marvel at their beauty.	4
She spent hours in the grove, carefully examining each flower and breathing in their sweet fragrance.	5

Chunking Raw text into Word with Chunk Size and Overlap

SELECT * FROM chunk('In a quaint village nestled in the heart of the countryside, there lived a young girl named Lily. She was known throughout the village for her vibrant imagination and her love for adventure. Every day, Lily would set out to explore the lush forests and rolling hills that surrounded her home, always eager to discover something new and exciting.

One particularly sunny morning, Lily decided to venture deeper into the woods than she ever had before. As she walked, she stumbled upon a hidden grove filled with the most beautiful flowers she had ever seen. The colors were so vivid and the petals so delicate that Lily couldnt help but marvel at their beauty. She spent hours in the grove, carefully examining each flower and breathing in their sweet fragrance.',
    type => 'Word',
    chunk_size => 30,
    overlap => 10);

text	index
In a quaint village nestled in the heart of the countryside there lived a young girl named Lily She was known throughout the village for her vibrant imagination and her	0
known throughout the village for her vibrant imagination and her love for adventure Every day Lily would set out to explore the lush forests and rolling hills that surrounded her	1
explore the lush forests and rolling hills that surrounded her home always eager to discover something new and exciting One particularly sunny morning Lily decided to venture deeper into the	2
particularly sunny morning Lily decided to venture deeper into the woods than she ever had before As she walked she stumbled upon a hidden grove filled with the most beautiful	3
stumbled upon a hidden grove filled with the most beautiful flowers she had ever seen The colors were so vivid and the petals so delicate that Lily couldnt help but	4
and the petals so delicate that Lily couldnt help but marvel at their beauty She spent hours in the grove carefully examining each flower and breathing in their sweet fragrance	5

Chunking Raw Text into Sentences

SELECT * FROM chunk('In a quaint village nestled in the heart of the countryside, there lived a young girl named Lily. She was known throughout the village for her vibrant imagination and her love for adventure. Every day, Lily would set out to explore the lush forests and rolling hills that surrounded her home, always eager to discover something new and exciting.

One particularly sunny morning, Lily decided to venture deeper into the woods than she ever had before. As she walked, she stumbled upon a hidden grove filled with the most beautiful flowers she had ever seen. The colors were so vivid and the petals so delicate that Lily couldnt help but marvel at their beauty. She spent hours in the grove, carefully examining each flower and breathing in their sweet fragrance.',
    type => 'Sentence');

text	index
In a quaint village nestled in the heart of the countryside, there lived a young girl named Lily	0
She was known throughout the village for her vibrant imagination and her love for adventure	1
Every day, Lily would set out to explore the lush forests and rolling hills that surrounded her home, always eager to discover something new and exciting	2
One particularly sunny morning, Lily decided to venture deeper into the woods than she ever had before	3
As she walked, she stumbled upon a hidden grove filled with the most beautiful flowers she had ever seen	4
The colors were so vivid and the petals so delicate that Lily couldnt help but marvel at their beauty	5
She spent hours in the grove, carefully examining each flower and breathing in their sweet fragrance	6

Chunking Raw Text into Paragraphs

SELECT * FROM chunk('In a quaint village nestled in the heart of the countryside, there lived a young girl named Lily. She was known throughout the village for her vibrant imagination and her love for adventure. Every day, Lily would set out to explore the lush forests and rolling hills that surrounded her home, always eager to discover something new and exciting.

One particularly sunny morning, Lily decided to venture deeper into the woods than she ever had before. As she walked, she stumbled upon a hidden grove filled with the most beautiful flowers she had ever seen. The colors were so vivid and the petals so delicate that Lily couldnt help but marvel at their beauty. She spent hours in the grove, carefully examining each flower and breathing in their sweet fragrance.',
    type => 'Paragraph');

text	index
In a quaint village nestled in the heart of the countryside, there lived a young girl named Lily. She was known throughout the village for her vibrant imagination and her love for adventure. Every day, Lily would set out to explore the lush forests and rolling hills that surrounded her home, always eager to discover something new and exciting.	0
One particularly sunny morning, Lily decided to venture deeper into the woods than she ever had before. As she walked, she stumbled upon a hidden grove filled with the most beautiful flowers she had ever seen. The colors were so vivid and the petals so delicate that Lily couldnt help but marvel at their beauty. She spent hours in the grove, carefully examining each flower and breathing in their sweet fragrance.	1

text

index

In a quaint village nestled in the heart of the countryside, there lived a young girl named Lily. She was known throughout the village for her vibrant imagination and her love for adventure. Every day, Lily would set out to explore the lush forests and rolling hills that surrounded her home, always eager to discover something new and exciting.

One particularly sunny morning, Lily decided to venture deeper into the woods than she ever had before. As she walked, she stumbled upon a hidden grove filled with the most beautiful flowers she had ever seen. The colors were so vivid and the petals so delicate that Lily couldnt help but marvel at their beauty. She spent hours in the grove, carefully examining each flower and breathing in their sweet fragrance.

Combining functions

We have seen how these functions behave individually, but the real power of these functions and LangDB lies within combining. Let's take an example of a job description pdf.

Firstly, we will use load to convert the file into bytes and then extract_text to get all the raw text from it.
After that, we will Chunk by Char with a chunk_size of 2000.

select * from chunk(
    (
        select content from extract_text((
            select * from load('https://www.stjohneyehospital.org/wp-content/uploads/2024/05/Job-Description-Accountant.pdf',
            type=> 'pdf')
        ))
    ),
    chunk_size => 2000,
    type => 'Char',
    trim => false
)

text	index
ST. JOHN EYE HOSPITAL – JERUSALEM JOB DESCRIPTION Title Accountant Department Finance Section Reports to Director of Finance Hours 40 hrs per week (inc of lunch breaks) Date February 24 formulated/updated General Statement of Duties: To play a major role in controlling the costing system of purchases and payroll by supporting the existing accountants and providing reports as instructed by the Director of Finance. Main Responsibilities: To act as a substitute for the senior/payroll accountant during her absence. Act as the Projects’ accountant and point of contact by providing reports and supporting documents for projects and any other assistance as needed. Act as the Cafeteria’s accountant which includes recording of expenses and income, produce reports for management, as well as reporting to the tax authority. Responsible for examining, recording, and summarizing the organization’s West Bank costs, mainly payroll and purchases. The Accountant records and classifies expenditures to create financial statements for senior management. Ensure that all costs are identified and recorded accurately. Maintaining accurate costing records in relation to labour and supplies. Process accounting transactions using the existing accounting software. Assist in the preparation of the monthly local management accounts and comparing it to budget, and report on any variance to DOF and other heads of departments. Process Palestinian payroll transactions using accounting and payroll systems and assist with the Israeli payroll system when needed (and ensure that the payroll taxes and national insurance are paid to the regulatory bodies on timely basis). Revision of purchases recorded at the pharmacy system. Monitor and coordinate payments for West Bank Suppliers Any other duties as assigned by the Director of Finance. General Responsibilities:	0
1. All staff are expected to report for work on time and fulfil their hours of duty, from time to time some flexibility may be required in order to meet the needs of the job and this may be outside regular hours of work. All staff are expected to promote and contribute to a cooperative and productive work environment. Staff are also expected to show respect and consideration to their colleagues and all patients and visitors to the hospital. All staff are expected to follow the dress code for their area of work. All uniforms as required by different work areas should be worn at all times. Staff who do not have a uniform are expected to wear appropriate, respectful, modest business dress. Jeans are not considered appropriate attire. The hospital is a no smoking hospital and smoking is only permitted in the designated smoking areas and only during official break periods. All staff will abide by confidentiality rules and will not disclose any information about patients, the staff or the workings of the hospital, except in certain circumstances where express permission is given as per the Confidentiality Policy. All staff are expected to comply at all times with the requirements of Health and Safety regulations and to take responsibility for the health and safety and welfare of others in the working environment ensuring that agreed safety procedures are carried out to maintain a safe environment. The Hospital has a Control of Visits in the Hospital and Security of Workers policy in order to help protect patients, visitors and staff and to safeguard their property. All employees have a responsibility to ensure that those persons using the Hospital and its service are as secure as possible. The Hospital is committed to equality and all staff are expected to treat colleagues, patients and visitors to the Hospital with dignity and respect, regardless of their ethnic background, religion, race, gender, age or	1
sexual orientation. All staff are expected to familiarise themselves with the requirements of the Hospitals policies and procedures for staff and also their specific area of work. All appointments within the Hospital are subject to pre-employment health screening. All staff are responsible for ensuring that all risks of cross infection to patients are minimised and that all policies, procedures and guidance relating to infection control practice are adhered to. All staff are responsible, where relevant, for ensuring that all equipment used by patients is clean/decontaminated as instructed by manufacturers and in line with the infection control/guidelines protocol and policy. The job description gives a general outline of the duties of the position and is not intended to be an inflexible or finite list of tasks. It may be varied, from time to time, after consultation with the member of staff. Any other duties as designated by your manager and which are commensurate with the grade. Essential requirements for the post: Bachelor’s degree in accounting. At least one year experience in the accounting field mainly in the payable’s sections. At least one year experience in processing payroll. Knowledge and experience of the Israeli & Palestinian Payroll systems is required. Previous experience in projects is a plus. Very Good in English and Hebrew languages. Computer literate especially excel spread sheets. Good eye for details. Methodical and organised. Ability to work under pressure. Ability to meet deadlines. Ability to lead & contribute to team work as necessary. Name ______________________________________________ Date ________________________ Signed ______________________________________	2

By leveraging functions like load, extract_text, extract_layout and chunk, LangDB equips developers with a powerful toolkit for overcoming unstructured data challenges. Whether you're dealing with disorganized text, intricate document layouts, or vast amounts of data, these functions provide the versatility and efficiency needed to convert raw information into structured, actionable insights. LangDB not only simplifies the complexity of data extraction and processing but also enhances the overall productivity of your development workflow.

Forem: Mrunmay

How Deep Agents Actually Work: A Browsr Architecture Walkthrough

What Makes an Agent “Deep”

Browsr

Debugging with vLLora

Sample Traces

Average cost and no. of steps using gpt-4.1-mini

Why Observability Is Critical for Deep Agents

Key Takeaways

Useful if you're building agents or gateways that need to support image generation with OpenAI-compatible APIs.

Building AI-Powered Image Generation with OpenAI-Compatible Responses API

Pause, Inspect, Edit: Debugging LLM Requests in vLLora

Breakpoint Debugging for LLM Requests

Why We Built This

What Happens When a Request Pauses

Edit Anything

Continue the Workflow

Why This Matters for Agents

Closing Thoughts

Designing Smart Multi-Agent Workflows with Agno & LangDB

TL;DR:

The Code

The Architecture: A Trio of Financial Experts

Enhanced Tracing with pylangdb.agno.init()

Code Walkthrough: Building the Team

The Web Search Agent: Decoupled and Dynamic

The Finance Agent: The Quantitative Analyst

The Coordinating Team: The Orchestrator

Dynamic Tooling with Virtual Models and Virtual MCPs

Running the Team and Observing the Results

Full Observability with LangDB Tracing

Conclusion

Discover End-to-End Tracing on Google ADK with LangDB

The Magic Behind the Curtain: pylangdb.adk.init()

The Architecture: Root Agent and Sub-Agents

Dynamic Tooling with Virtual Models and Virtual MCPs

Example: The inspiration_agent and Google Maps

Example: Grounding with Google Search

Example: The planning_agent for Flights and Hotels

The Flow: From Query to Answer

Conclusion

Supercharging AI Code Editors with LangDB Virtual MCP Servers

The Problem: Tool Explosion

The Solution: LangDB Virtual MCP Server

How I Used Virtual MCP in My Café Rewards Project

The Benefits I Saw

Want to Set Up Your Own?

Frontend Web Dev Is Dead (Thanks to Figma + Supabase MCP)

The Problem With Old-School Frontend

The Shift: Figma MCP + Supabase MCP

Real-World Example: Building the Café Rewards Dashboard

Design Foundation:

Data Foundation:

Tech Stack Overview

Prompt Used:

Why This Changes Frontend Forever

Closing Thoughts

Choose the right AI model: Comparision of gpt-4o, claude and gemini using LangDB

Chat Interface in LangDB

Supported Models

Why Perform Model Comparisons?

Get Started with LangDB

How to Integrate LangChain with LangDB

Pre-requisites

Example: Using LangDB with LangChain

Dynamic Model Switching

Tracing in LangDB

Conclusion

Why We Built an AI Gateway in Rust: A Performance-Centric Decision

Benchmark Setup: Simulating Real-World AI Traffic

Results: Rust vs. Python vs. JavaScript (Node.js)

Why Rust is the Best Choice for an AI Gateway

Why Python and JavaScript Fall Short

Why AI Gateways Must Be Built with Performance in Mind

The Takeaway: Rust is the Future of AI Gateways

Introduction to AI Gateway

Rise Of LLMs

What is an AI Gateway

Key Features of LangDB's AI Gateway

Conclusion

Enhanced Tracing with `pylangdb.agno.init()`

The Magic Behind the Curtain: `pylangdb.adk.init()`

Example: The `inspiration_agent` and Google Maps

Example: The `planning_agent` for Flights and Hotels

Usage with `load` function