How to Query Datasets From AI Agents Without Destroying Your Context Window

Picture this: an agent wakes up, reads a 180,000-row CSV, and suddenly can't remember its own name. That's not a bug — that's context economics.

When you let an agent "read" a dataset, you're not actually giving it insight. You're forcing it to re-derive everything from raw bytes, every single time, paying tokens for the privilege. We built EVIDIQ Atlas because there's a saner primitive hiding in plain sight: let the agent query datasets from AI agents through a paid tool call, and return only the answer — never the whole haystack.

Querying Datasets From an AI Agent, Defined

EVIDIQ Atlas is the production implementation of letting an agent query datasets from AI agents over MCP: the agent sends a structured JSON-RPC request describing the slice it wants, gets back a structured finding plus artifacts, and pays only for the work actually requested via x402 on X Layer. The dataset owner controls access; the agent controls spend.

That's the contract. Three things happen in one round-trip: the agent sends a query with filters, columns, aggregations, and a time window; Atlas executes the slice against the registered dataset; the agent receives a deterministic JSON payload — finding, sample size, confidence, and an artifact URI — plus a canonical hash for later verification. Nothing else is returned. No full rows the agent didn't ask for. No probabilistic guesswork.

The model behind it is the same model EVIDIQ uses everywhere: per-call pricing via the x402 protocol, scheme exact, settled on X Layer in USDT0 via EIP-3009 transferWithAuthorization. You can see this pattern across the EVIDIQ family. Atlas just specializes it for data instead of trust scores or model receipts.

The Context-Window Tax Nobody Budgets For

Here's the math nobody wants to run.

A 100MB CSV lands at roughly 25 million tokens under GPT-4-class tokenizers. Drop that into a single prompt and you've blown past Claude's 200K window before you've even added system instructions, retrieved context, or tool schemas. Push it into a 1M-token window like Gemini 1.5 Pro's and you're paying per-token for data the model will mostly ignore — the actual signal in a transactional dataset is usually under 0.3% of the rows.

[IMAGE_PROMPT: A modern flat illustration showing a giant haystack overflowing from a chat bubble on the left being injected into a small AI agent robot's brain on the right, with token bills falling like confetti, contrasted on the right with a single clean MCP tool call returning a tidy JSON card on a tablet. Developer/tech aesthetic, soft pastel palette with accent of neon teal, no logos, no text.]

Latency follows the same curve. A 25M-token input adds tens of seconds before the first token comes back. For an agent that's supposed to be making decisions in real time, that's a death sentence. Accuracy? Empirically, models hallucinate more on huge prompts because the attention mechanism dilutes across irrelevant rows. You're paying more, waiting longer, and getting worse answers.

The honest take: context-dumping is the wrong default for any non-trivial dataset. A metered query primitive beats it on every axis that matters — cost, latency, accuracy, and reproducibility. When your agent needs to know "give me the median transaction value for wallets that interacted with contract 0x... in the last 30 days," the only honest answer is a tool call, not a prompt paste.

This is exactly why we built Atlas the way we did. The dataset never leaves its source of truth. The agent never sees a row it didn't ask for. The bill is denominated in cents, not context. If your data is sensitive — and most real data is — Atlas also means you never have to choose between "the agent gets nothing" and "the agent gets everything."

One Question, One Priced Call

Let's walk a real flow. An agent on a user's machine wants to compare two datasets before recommending an action — say, the volume profile of two token launches over the same window. Here's what happens end to end:

1. The agent asks the Atlas MCP endpoint estimate_cost({dataset_a: "evidiq://launches/alpha", dataset_b: "evidiq://launches/beta", metric: "volume_p50_p95", window: "7d"}). This call is free — it's a price quote, not a query. Atlas returns the quoted price in USDT0 micro-units plus the estimated runtime. Budget locked before money moves.
2. The agent decides to proceed. It sends query_dataset(...) for dataset A. Atlas responds with HTTP 402 and an x402 challenge — a paymentRequirements object containing the scheme (exact), the network (x-layer), the asset (USDT0), and the accepts[].amount. This follows the x402 v2 spec, settled via EIP-3009 transferWithAuthorization. The agent signs, not Atlas.
3. Once the payment header arrives, Atlas executes the slice and returns a structured payload: {finding: {...}, sample_size: n, confidence: 0.87, artifacts_uri: "evidiq://artifacts/abc123", canonical_hash: "0x..."}. Same input, same output — deterministic.
4. The agent repeats steps 2 and 3 for dataset B, then calls compare_datasets(...) with both artifact URIs. The comparison runs server-side against the cached results — you don't pay to re-fetch. Final verdict is returned as a single signed JSON object.

The trade-off that matters: every step is auditable, every step has a price tag, and no step accidentally streams 25M tokens into a prompt. Compare that to the same comparison done by stuffing both CSVs into a context window — same question, roughly 50× the cost, roughly 30× the latency, and zero reproducibility guarantee because the model's next attention pass will land somewhere slightly different each time.

If you're wiring this up today, the EVIDIQ docs walk through installing the remote MCP, configuring your X Layer signer, and registering your dataset manifests. We designed the price surface to be readable from a budget, not a black box.

Where Atlas Fits Next to Sentinel and Notary

EVIDIQ's MCP family is small on purpose. Three tools, each answers a different question, each is metered the same way.

• Sentinel — answers "is this agent trustworthy?" It probes an endpoint, scores identity + capability + reputation + risk into a 0–100 trust score with an explicit recommendation. Read the EVIDIQ Sentinel docs for the scoring formula.
• Atlas — answers "what does the data say?" It runs the structured query against your slice and returns a deterministic finding with artifacts.
• Notary — answers "what did the model actually produce?" It receipts the model's output, hashes it, and anchors evidence on 0G Storage so anyone can re-fetch and verify. See the EVIDIQ Notary docs.

[IMAGE_PROMPT: A modern flat illustration of three connected hexagonal nodes containing abstract icons — a shield for trust, a chart for data, and a certificate for receipts — joined by glowing lines on a soft slate gradient background, representing the Sentinel-Atlas-Notary MCP family. Developer/tech aesthetic, muted blues and warm gold accents, no real brand logos, no text labels.]

The handoff we love: Sentinel verifies a counterparty agent, Atlas pulls the dataset slice you'll actually act on, Notary signs what you did with it. Three paid calls, one auditable chain. And since Atlas and Sentinel can both be reached from the same MCP entry at evidiq.dev/mcp, your agent only has to learn one payment flow.

For the operator side — how to spin up an agent that auto-discovers all three services, rotates signers, and budgets per-call — the EVIDIQ Operator docs are the place to start. We've open-sourced the local skill under MIT at github.com/evidiq/evidiq-skill so you can read every line before you wire it in.

The honest version of the roadmap in 2026: Atlas does deterministic structured queries today, with a path toward richer joins and federated slices across multiple registered datasets later this year. We'll keep the pricing as transparent as it is now — no surprise metering, no per-row tax on top of the per-call bill.