What are agent-first data architectures, and do they beat tool calls?

An agent-first data architecture puts a company's data sources behind one query layer for AI agents, instead of giving the agent a separate tool per source. An example is Dinobase, an open-source project presented on Hacker News on 7 April 2026: it syncs sources such as Stripe and HubSpot to Parquet files and queries them with DuckDB, so one SQL query can answer a question across several systems. In Dinobase's own benchmark, 11 models got 91% of the questions right this way, against 35% with per-source tools.

What goes wrong with one tool per source?

The usual setup gives an agent one tool per data source, often an MCP server for each SaaS product. The Dinobase README names three gaps in that approach: agents cannot JOIN across APIs, they have no context to interpret field values, and they receive paginated JSON that fills their context window.

Its example question: "Which customers churned last quarter with declining usage AND open support tickets?" With one tool per source, the agent has to page through the billing data, fetch usage and open tickets from two other systems, and then match the three lists in its own context, by email address for instance. According to the benchmark notes, reading 1,000 records through such a tool takes 10 round trips and about 60,000 tokens, where SQL needs one aggregate query.

The developer behind Dinobase put it like this on Hacker News: tool calls, MCPs and raw APIs "force the agent to join information in-context", while SQL does that natively. Before Dinobase he built PostHog AI, the business-analyst agent of the analytics company PostHog, where the team compared raw SQL access with tools. His verdict: "SQL wins."

How does Dinobase work?

The idea resembles a data warehouse: bring the data together first, then query it with SQL. In the README of 9 April 2026:

• Sources: 101 connectors for SaaS APIs, databases and file storage. API data is synced to Parquet files on local disk or in your own S3, GCS or Azure bucket; Parquet and CSV files are read at query time.
• Query engine: DuckDB. Each source becomes a schema, and joins across sources run on shared columns such as email.
• Interface: a command-line tool for agents that run shell commands, such as Claude Code, Cursor and Codex, or an MCP server for other clients.
• Semantic layer: optional. After each sync, a Claude agent, using your own Anthropic API key, writes table descriptions, column documentation, PII flags and relationships between tables.
• Writing back: agents can change source data through SQL, but every change first returns a preview and only runs after confirmation.

What does the benchmark show?

Dinobase tested 11 models, from Kimi K2.5 to Claude Opus 4.6, on 15 revenue-operations questions about synthetic HubSpot and Stripe data: about 1,400 rows in 7 tables. Each model got the same data and questions in both setups, with at most 15 turns and temperature 0, and answered each question once. The report gives these totals:

• Accuracy: 91% (150 of 165 answers) with SQL, 35% (57 of 165) with per-source tools
• Average time per question: 34 seconds against 106 seconds
• Cost per correct answer: $0.027 against $0.445, about 16 times less

SQL scored higher for every model, from 80% (Kimi K2.5) to 100% (Claude Opus 4.6 and Sonnet 4.6). With per-source tools, models scored between 20% and 53%. Speed varied more: for three models, including GPT-5.4, the per-source tools were about as fast.

The gap was about as large for simple single-source questions as for questions that required a join: SQL got 91% on each of the three question types, per-source tools 38% on the simple ones, 29% on the questions that needed domain knowledge and 36% on the cross-source ones. Of the failures with per-source tools, 62% were wrong answers or interpretations, 12% were joins the agent could not make, 9% were amounts left in cents instead of dollars, 9% were tool or API errors and 7% came from seeing only the first 100 records.

How much weight does that benchmark carry?

Dinobase built and ran the benchmark itself. Its developer called it "an experimental benchmark" and wrote that the results "seem almost too good". Four things limit it:

• The baseline is Dinobase's own simulation: one list tool per table that returns up to 100 records per page, with only a limit and an offset as parameters. Tools that can filter or aggregate were not tested. According to the developer, 80% of the questions in the benchmark set are aggregations, which is where skipping pagination saves the most.
• Each model answered 15 questions once, so a single answer moves its score by almost 7 percentage points.
• The answers to about 40% of the questions were graded by another model (Claude Haiku 4.5); the rest were checked automatically.
• The README mentions 75 questions and "16-22x cheaper". The published report covers the 15 revenue-operations questions and a factor of 16.

What are the trade-offs?

Synced API data is only as fresh as the last sync. In April 2026, a column change at a SaaS vendor created a new column while the old one stayed, and the semantic layer described the current state including those stale columns, according to the developer. He planned automated schema migrations. The optional semantic layer runs Claude over your data with your own API key. Most of Dinobase's code is MIT-licensed, and the benchmark code, questions and results are in the benchmarks folder of the repository.