Your Data is Toxic: Designing Tools for the Age of Context

There is a silent killer in AI agent development: The Bloated API.

We often treat AI agents like human developers. We give them the same APIs, the same database access, and the same documentation that we use. But there is a fundamental difference. When a human looks at a 5,000-line JSON response, their brain automatically filters out the noise to find the one ID they need.

When an LLM sees that same 5,000-line JSON, it treats every single bracket, key, and null value as a token that must be processed, attended to, and weighed against the "attention budget."

You are effectively flooding your agent's working memory with noise before it has even started thinking. To build effective agents, we need to stop building tools for humans and start building tools for token efficiency.

The "Need-to-Know" Principle

In Context Engineering, data is a liability until proven otherwise. Your tool design should enforce a strict "Need-to-Know" policy.

Consider a standard "Get Customer" tool.

Bad Design: Returns the entire customer object (shipping history, preferences, metadata, logs) — 2,000 tokens.

Good Design: Returns a summary (ID, Name, Status, and a list of available sub-fields) — 50 tokens.

If the agent needs the shipping history, it can ask for it in a second turn. This strategy, known as Progressive Disclosure, prevents the context window from filling up with irrelevant data "just in case."

The "Navigation First" Pattern

How do you find a file on your computer? You don't open every single document and read it until you find the right one. You use the file explorer (ls) to see the list, then maybe a search (grep) to narrow it down, and finally you open one file.

Most agent developers skip the first two steps. They build tools that dump data immediately.

"Effective agents require Navigation Tools before they need Consumption Tools."

Instead of readFile(), give your agent listFiles().

Instead of databaseDump(), give your agent getSchema().

By forcing the agent to navigate the structure of the data before retrieving the content, you ensure that only the highest-signal tokens ever enter the context window.

Just-in-Time (JIT) Context

We are moving away from "RAG" (Retrieval Augmented Generation) where we try to guess what the agent needs before the query starts. We are moving toward Agentic Search.

In this model, the agent is responsible for its own context loading. It uses "Just-in-Time" strategies to pull data from the web, internal docs, or codebases at the exact moment a decision requires it.

This is where new standards like the Model Context Protocol (MCP) come into play. MCP acts as a universal adapter, allowing agents to "mount" data sources (like Google Drive, Slack, or a Postgres DB) and query them on demand, rather than having data force-fed into the prompt.

The Golden Rule: Silence is Golden

The most sophisticated agents are often the quietest. They use tools that return minimal, precise feedback ("File updated successfully" vs. printing the whole file). They navigate metadata before reading content. They treat the context window like a clean room, not a dumping ground.

"If your agent is confused, hallucinating, or getting stuck in loops, don't look at the prompt. Look at your tools."

Are you feeding it signal, or are you drowning it in noise?

Clean data in. Clear thoughts out.