Intelligence is Free, Now What? <br> Data Systems for, of, and by Agents

What it claims

This is a perspective piece. Most of it is a research agenda, but a few concrete figures and design sketches go past the summary:

• Cost premise. GPT-4-class inference fell from about $30 per million tokens in early 2023 to under $1. Some providers are below $0.10. Across benchmarks, prices are falling 9x–900x per year, with a median near 50x.
• Redundancy in agentic speculation. On a text-to-SQL benchmark where multiple agents attempt each task, only 10–20% of sub-plans are distinct, so 80–90% of sub-queries repeat work. Task success rises significantly with more attempts. The authors argue the redundancy should be exploited, not suppressed: it helps agents and is waste only from the database's side.
• Synthesized engines are cheap. Bespoke OLAP and GenDB produce a complete workload-specific analytical engine in minutes to a few hours, for a few dollars. The engine is regenerated when the workload shifts.

How it works

Interface ideas for agent-facing databases. These are proposals, not built systems:

• Reuse results across overlapping sub-plans, drawing on multi-query optimization and shared scans.
• Return approximate answers (AQP), or stream intermediate operator output so the agent can stop early.
• Accept a batch of queries, each with its own approximation tolerance, instead of one SQL statement at a time.
• Offer looping primitives modelled on DBT-style Jinja macros, so agents don't enumerate a combinatorial query space by hand.
• Return a latency estimate before running an expensive query, and push precomputed materialized or virtual views into the agent's context. This is feasible now because agents accept arbitrary textual feedback, not only result sets.

Structured memory. This comes from the authors' own work:

• Each memory entry carries attribute facets, and each facet is either * (applies everywhere) or a list of values to match.
• For a data agent, the facets are tables, columns, operation type, and a free-text corrective instruction. Examples: "use fiscal year, not calendar year, for date-time operations"; "prefer product_cleaned over product for product-name queries."
• Retrieval matches on facets rather than keywords or embeddings.
• Raw traces are deliberately not stored as memory, because they lead agents to repeat the same mistakes.
• The authors argue knowledge graphs share the weakness of markdown files: neither supports structured search.

Countering reward hacking in synthesized systems. In the authors' custom key-value store work:

• Auxiliary verification agents generate test cases aimed at corner cases the specification missed, which in effect expands the spec.
• A second approach generates the system and a correctness proof together.
• A third idea is to apply proofs only to critical code paths rather than the whole system.

Evidence

The paragraphs above contain all the numbers the page gives. The 10–20% distinct-sub-plan figure has no benchmark name, agent count or model attached. The synthesis cost and time figures are attributed to Bespoke OLAP and GenDB, not measured here.

Limits

• The authors state that the post draws heavily on their own ongoing work.
• Proof co-generation is described as "early success, but more needs to be done."
• It is unclear whether multiversioning or copy-on-write scale to thousands of concurrent agent writers.
• It is unclear whether Temporal-style durable execution holds at swarm scale.
• Livelock from endless compensating actions is named as a key unsolved failure mode.
• It is open whether coordination should be centralized or decentralized.
• Defining a per-application memory schema is an open question.
• Starting from a mature system such as Postgres and stripping components, versus composing verified parts, is posed as a question, not tested.
• No code, systems or APIs are released with the post.