An AI Data Agent With 80+ Tools: What It Takes to Go Beyond a Chatbot

We have written about what AI data agents are and how NL2SQL agents work at a high level. This post is the technical deep dive. If you have spent any time building agentic systems yourself, or if you are evaluating AI analytics tools and want to know what separates real architecture from a thin wrapper around a chat completion API, this is for you.

The short version: Fastero's agent is not a chatbot with a SQL plugin. It is a multi-model reasoning system that runs a ReAct loop over 80+ tools, catches its own mistakes through a reflection engine, decomposes complex goals into executable plans, runs parallel analyses via fan-out, and remembers context across sessions using vector search. You bring your own LLM keys. Here is how each piece works.

The tool surface: 80+ tools, not just SQL

When people hear "AI data agent," they picture a text-to-SQL translator. Our agent can write SQL, sure. But SQL execution is one tool out of more than 80.

The toolkit breaks down into categories. Data and SQL tools handle query execution, schema inspection, relationship analysis, query optimization, data profiling, and sample exploration. Dashboard tools create, edit, and refresh widgets — bar charts, line charts, KPIs, tables — directly from the conversation, producing real dashboards that persist and auto-refresh. Python execution tools run arbitrary analysis on a managed K8s runtime with log streaming and resource tiers. Streamlit tools generate, deploy, and manage full data apps from a prompt. File processing tools handle Excel, CSV, and PDF table extraction with profiling. SaaS integration tools pull directly from Stripe, HubSpot, Shopify, Klaviyo, GA4, Google Ads, Meta Ads, Xero, and more — no warehouse round-trip needed. Communication tools send Slack messages and emails. Analysis tools run pattern detection, anomaly identification, and multi-step autonomous investigation. Memory tools store and recall facts. Web tools search the internet and fetch URLs for context enrichment.

The breadth matters because real analytical questions rarely stay in one lane. "How does our email campaign performance correlate with Shopify revenue by product category?" requires Klaviyo data, Shopify data, SQL joins, statistical analysis, and a visualization — five tool categories in a single question. A text-to-SQL chatbot cannot even begin.

The ReAct loop: reason, act, observe, repeat

The agent runs on a ReAct (Reason + Act) architecture. This is not a single LLM call. It is a loop: the LLM reasons about the current state, chooses a tool to call, executes it, observes the result, and decides what to do next. The loop continues until the agent has enough information to deliver a final answer — or until it hits the iteration ceiling (30 rounds for conversations, 20 tool calls for structured tasks).

Each iteration is a deliberate decision. The LLM sees the full conversation history, all prior tool results, and the available tool schemas. It picks the next action based on what it learned so far. If a SQL query returns unexpected nulls, the agent does not surface an error — it runs a profiling tool to understand the data distribution, adjusts the query, and retries. If a dashboard widget needs data from two sources, the agent pulls both, joins them in DuckDB, and builds the chart.

This is the fundamental difference between a chatbot and an agent. A chatbot gives you one response per message. An agent works a problem until it is solved, using whatever tools the problem demands.

Reflection: the agent that catches itself

Tool calls fail. Queries time out. APIs return unexpected shapes. In a chatbot, that failure surfaces as an error message you have to interpret yourself. Our agent handles it differently.

When a tool call fails, the reflection engine kicks in. It sends the failure context — what was attempted, what went wrong, what the surrounding conversation looks like — to a fast reasoning model. The reflection returns one of three directives: retry with a different approach, clarify by asking the user a question, or escalate when the problem is genuinely unsolvable. The agent gets up to two reflection cycles per failure before escalating.

This is surprisingly important in practice. A SQL query might fail because the agent used a PostgreSQL window function against a MySQL connection. The reflection engine catches the dialect mismatch, regenerates the query with MySQL-compatible syntax, and retries — all without the user seeing an error.

Planning: goal decomposition before execution

For complex, multi-step requests, the agent does not just start executing. It plans first.

When you ask something like "Build me a dashboard comparing our Stripe revenue trends against HubSpot pipeline velocity, with cohort retention curves for customers who activated last quarter," the orchestrator decomposes that into ordered steps: pull Stripe revenue data, query HubSpot pipeline metrics, define activation criteria, compute cohort retention, build each dashboard widget, compose the final layout. The plan is shown to you before execution starts. You can approve it, modify it, or redirect it.

If a step fails after the reflection engine exhausts its retries, the orchestrator does not just stop. It re-plans — generating a revised sequence that routes around the failure. If the Stripe API is down, maybe the orchestrator pulls the same data from the local DuckDB store that synced an hour ago. The goal stays the same; the path adapts.

Fan-out: parallel analysis at scale

Some questions decompose into independent sub-problems. "Analyze performance across all five of our marketing channels" does not need to run sequentially — each channel analysis is independent.

The fan-out engine detects when a request has three or more independent subgoals and spawns them as parallel jobs on a Redis-backed queue. Each subgoal runs its own ReAct loop with its own tool calls, subject to a two-minute timeout. When all branches complete, a synthesis step sends every result to the LLM for a single coherent answer.

Within each branch, tool calls themselves also run in parallel when they are independent. If a single analysis step needs both schema metadata and a data sample, the agent fires both tool calls concurrently and continues when both resolve.

This is not cosmetic parallelism. It is the difference between a 10-minute sequential analysis and a 2-minute parallel one. For a data team lead who needs a cross-channel breakdown before a 9 AM standup, that difference is the entire value proposition.

Memory: three layers of context

Most AI tools have the memory of a goldfish. Every conversation starts from zero. Fastero's agent has three layers of memory.

Session memory carries context within a conversation. The agent remembers disambiguation choices, prior query results, and the rolling analytical context. Follow-up questions like "break that down by region" just work because the agent knows what "that" refers to.

Semantic long-term memory persists across sessions. When the agent learns that your fiscal year starts in April, or that your status column uses 1 and 0 instead of active and inactive, it stores that as an embedding in a pgvector-backed PostgreSQL database. Future conversations retrieve relevant memories by cosine similarity, scoped to your organization and user. The agent gets smarter every time you use it.

Artifact retrieval indexes every dashboard, query, and report your team has built. When you ask a new question, the agent searches past artifacts for relevant work. If someone on your team already built a retention analysis last month, the agent finds it and builds on top of it instead of starting from scratch.

All three layers are injected into the system prompt at the start of every interaction. The agent walks into every conversation with your organizational context already loaded.

Multi-LLM and BYOK: no vendor lock-in

Here is an architectural opinion: your analytics platform should not lock you into a single AI provider. Models improve at different rates. Pricing shifts. Availability varies. A production system needs to route between providers.

Fastero's LLM gateway supports OpenAI, Anthropic, Google Gemini, Azure OpenAI, OpenRouter, and Sagemaker. You can use our hosted models or bring your own API keys — full BYOK. An org-scoped model registry tracks per-model cost, token limits, tool support, and PII policies.

If your primary model's API goes down mid-analysis, the gateway automatically falls back to the next active model in your configuration. Tool call formats are translated between providers transparently — OpenAI's function calling format, Anthropic's tool use format, Gemini's function declarations — so you can switch models without changing anything about how you use the agent.

This matters more than it sounds. Different models have different strengths. Anthropic's Claude tends to be better at careful, multi-step analytical reasoning. OpenAI's GPT models are often faster for straightforward SQL generation. Gemini handles large context windows well for document-heavy analysis. With BYOK and a model registry, you can assign different models to different task types, optimize for cost or quality per use case, and never be stuck waiting for one provider's outage to resolve.

Example: a complex query, end to end

To make this concrete, here is what happens when you type: "Our Shopify revenue grew 40% last quarter but Stripe settlements only grew 15%. Where's the gap?"

Step 1 — Plan. The agent decomposes this into subgoals: pull Shopify revenue by month, pull Stripe settlement data by month, compare growth rates, identify categories of discrepancy (refunds, disputes, delayed settlements, currency conversion, fees).

Step 2 — Fan-out. The Shopify and Stripe data pulls are independent, so they run in parallel. Two concurrent tool calls hit the shopify_get_sales_summary and stripe_get_revenue_summary tools.

Step 3 — Analysis. Results come back. The agent runs SQL to join the datasets in DuckDB, calculates the month-over-month delta, and profiles the gap. It finds that refunds spiked in Month 2, Stripe processing fees grew disproportionately, and a batch of international orders had currency conversion losses.

Step 4 — Reflection. The initial refund query returned a suspicious zero for one month. The reflection engine catches this, re-inspects the Shopify refund schema, discovers refunds are stored in a separate refunds endpoint rather than as negative line items, and reruns with the corrected approach.

Step 5 — Synthesis. The agent presents a breakdown: 60% of the gap is refunds, 25% is processing fees, 15% is FX losses. It builds a dashboard with three widgets — a waterfall chart showing the reconciliation, a line chart of refund trends, and a table of the largest individual discrepancies.

Step 6 — Memory. The agent stores a fact: "Shopify refunds are in a separate endpoint, not inline." Next time anyone on your team asks about Shopify refunds, the agent already knows.

That entire flow — planning, parallel execution, cross-source joins, error recovery, visualization, and memory — is what 80+ tools and a real agent architecture buy you. A chatbot would have given you two separate numbers and wished you luck.

Notice what the user did not do: they did not write SQL, they did not know the Shopify refund schema, they did not manually join two datasets, and they did not build a dashboard. They described the problem. The agent did the rest.

The architecture is the product

We could have built a thin NL2SQL wrapper and shipped it in a week. Plenty of tools did exactly that. But a text-to-SQL translator breaks the moment a question requires more than one query, more than one data source, or any kind of iterative reasoning.

The architecture described in this post — ReAct loops, reflection, planning, fan-out, memory, multi-LLM routing, and a deep tool surface — is what it takes to build an AI agent that actually works on real analytical problems. Not toy demos. Not "ask your data a question and get a table." Real, multi-step, multi-source investigation that produces persistent, shareable outputs.

That is what we built. And every piece of it is live in production today.

---

Try Fastero free — connect your databases, bring your own LLM keys, and see what 80+ tools and a real agent architecture do with your data. No credit card required.