Article

Search, Fetch, and Write: A Primer

•

January 7, 2026

•

2 min

Summarize this article with:

I noticed that teams building agents often reach for familiar patterns such as streaming pipelines, CDC, and reverse ETL. These tools were built to move datasets between systems in bulk. Agents don’t work that way. They don’t move datasets at all.

To work reliably, agents need three things: the ability to fetch fresh data about a specific entity, connect that data across systems, and safely write changes back when it’s time to act.

When teams miss this distinction, agents tend to break down.

Why Agents Need Different Data Operations

Analytics systems are built to summarize the past. Agents operate in real-time, making decisions about a specific customer, ticket, or transaction. That means the agent must view an entity as a single, coherent object rather than a set of loosely related rows distributed across systems.

This shift from moving datasets to accessing entities changes everything about how data infrastructure needs to work.

Something similar happened when mobile apps emerged, as teams tried to adapt desktop architectures. It quickly became clear that responsive design meant rethinking layout, interaction, and performance, not just adding breakpoints to desktop designs.

The same thing applies now with agents. You can't just wrap your data warehouse in an API and call it agent-ready.

Search: Finding the Right Entity

Search means discovering which entities exist across your systems and how they connect.

Most data silos don’t understand who a customer is. If you ask Stripe about Erik, it returns nothing because it stores customer IDs, not names. Your support system stores an email address, Salesforce uses a different identifier, and GitHub tracks a username. Each system holds pieces of information about the same person, but none of them recognize they’re referring to the same entity.

An agent needs to be aware that Erik is one entity across all of these tools. To do that, it must resolve which identifiers belong to them in each system and discover what information exists. This process is called identity resolution.

Search is how agents perform that resolution. By searching across data silos, they uncover what data is available and how systems relate. This ability to connect fragments into a coherent whole is what we call entity intelligence.

To support this, data from source systems flows into a unified context layer where entities are resolved and connected. This layer understands that customer ID 12345 in Stripe, erik@company.com in your support system, and the Salesforce contact record all refer to the same person. When an agent searches for Erik, it can discover what information exists across systems in real time.

But you can't stop at discovery. What happens when you need the actual data?

Fetch: Retrieving Fresh Data on Demand

Most teams think caching solves the freshness problem. Replicate everything into a warehouse, let agents query it instantly, and move on. That works until it doesn’t. When a payment fails, the warehouse may not reflect it for hours, and the agent may make decisions based on stale data.

When an agent needs information about a specific entity, that data has to come directly from the source system at the moment it’s needed. That’s what fetch means.

Agentic data infrastructure must support both a centralized foundation of connected entities and real-time fetches from source systems. This combination keeps the shared entity cache consistent while giving agents a fresh understanding when needed.

Permissions are part of this design, too.

When an agent fetches data, it does so with the correct credentials and access controls. Instead of copying all the data and fixing permissions later, agentic systems respect access rules at the source.

Search discovers what information exists and how entities connect. Fetch retrieves fresh, permission-aware data about those entities when it’s needed. Without both, agents can’t work reliably.

Write: Completing the Action

Up to this point, agents have discovered and retrieved information. Write is where that understanding turns into action. Agents update records, open tickets, trigger workflows, and generate outcomes.

Write is significantly more complex than fetch because it changes state in production systems. That means governance, auditability, and proper access control matter deeply.

Every action must be traceable back to the data that informed it, and policies need to enforce what agents can modify. When something goes wrong, actions must be reversible.

This is where agentic data write patterns differ from reverse ETL. Reverse ETL is sync-oriented and batch-oriented. It takes aggregated data from your warehouse and pushes it to operational systems on a schedule. The pattern is predictable.

Agents complete tasks by updating specific records in the moment, not on a schedule. The write happens because the agent reasoned through context and determined an action was necessary.

Write completes the cycle. The agent discovers what exists, retrieves what it needs, reasons over context, and acts.

How the Three Work Together

Search, fetch, and write form a loop that defines how agents operate.

An agent receives a request to find everything related to a specific customer. It searches across structured and unstructured sources, identifies the right entity, validates permissions, and fetches fresh data.

As it processes the information, it discovers additional relevant entities such as related customers, products, transactions, or tickets. It searches again, fetches more context, and expands its understanding.

Once it has enough information, the agent completes the action by writing updates downstream. Then the loop starts again.

Without all three working together, agents can't operate effectively in production.

Building with Clarity

When you understand that agents discover through search, retrieve through fetch, and act through write, the architecture becomes clear. You move away from forcing streaming or reverse ETL into the wrong patterns and build infrastructure designed specifically for how agents work.

Agents use specific entities, not entire datasets. They operate in real time, fetching information on demand rather than waiting for batch syncs. This is fundamentally different from how analytics infrastructure served humans, where centralization and historical aggregation were the primary goals.

We're still early. The patterns are emerging, and the infrastructure is being built. The teams figuring this out are the ones shipping agents that actually work.

If you're building agents, I'd love to hear what you're learning.

Subscribe to Agent Blueprint to learn more about agentic data infrastructure.

Limitless data movement with free Alpha and Beta connectors

Introducing: our Free Connector Program ->