Web Search Integration Patterns for Persistent Agents

Web search integration in a persistent agent is not a question of which API to call. A persistent agent inherits yesterday's findings. Every time a task calls for outside information, it has to decide whether what it already has is good enough or whether the web needs to be consulted again.

That decision has no natural home in a system built around statelessness, because a stateless system has nothing to compare a new query against. In a persistent agent, the decision has to be designed on purpose, and skipping that design work produces three failure modes that appear quickly in production. Each of these is a direct consequence of treating search as a tool call rather than as a memory problem, and each has a remedy, which the rest of this piece lays out in order.

How persistent memory architecture changes what "knowing something" means for an agent

A persistent agent doesn't keep one memory. It keeps at least four, and the layer a search result lands in determines how long it lasts and how cheaply it can be reused later.

The first layer is the working buffer, the scratchpad the agent uses for the reasoning steps of a single task. A search result that lives only here disappears the moment the session ends, which is fine for a one-off lookup but wasteful for anything the agent is likely to need again. The fourth layer isn't really storage at all: it's the live web itself, the ground truth that the other three layers are trying to approximate as closely as they can without constantly re-fetching it.

These four layers appear, in one form or another, in most descriptions of how production agents handle memory: short-term conversational context, long-term knowledge storage, and an episodic record of specific events tied to a timestamp. The question the rest of this piece answers, pattern by pattern, is which of these four layers each category of search result belongs in, and what rule decides when it expires.

Pattern 1 (Search gating, deciding when to fetch before issuing a query)

The most expensive search a persistent agent can make is one it didn't need to make. Search gating is the pattern that stops this before it happens, by checking stored state before the agent touches the network.

The gate works as a lookup that runs ahead of every web query: has the agent retrieved information on this topic already, and is there reason to think it's still good? Two signals answer that question. When both signals come back favorable, close enough and recent enough, the agent answers from stored state and never issues the call.

Not all information decays at the same speed, so the gate needs a sense of what kind of fact it's dealing with. The risk on the other side of this pattern is gating too aggressively: serving a stale answer with the same confidence as a fresh one. The fix is to stamp every stored retrieval with explicit TTL metadata at the moment it's written, so the gate always has an honest number to check against.

Pattern 2 (Retrieval caching with TTL, storing search results so sessions learn from each other)

A search history that just sits there, unstructured, is closer to clutter than to an asset. Retrieval caching with a TTL attached is what turns a pile of old searches into something the agent can actually draw on later.

Raw results are bulky and full of noise, and storing them wholesale defeats the purpose of a cache meant to be reused cheaply, so what goes into the semantic store is the compressed version, tagged with a TTL that matches the freshness class, stable, slow-moving, or fast-moving, assigned when it was retrieved.

Expiry doesn't have to mean deletion. A better approach marks an old record as expired but still present, so the agent can keep reasoning with the stale context while a refresh runs in the background, and the whole task avoids stalling on a fresh fetch. Where this cache physically lives matters more than it might seem. Maritime's approach, giving each agent its own persistent disk inside a dedicated VM, is a direct fit for this pattern: the cache survives the agent's sleep cycle the same way any other file on disk would. The matching logic for this cache borrows from standard retrieval-augmented generation practice: dense semantic search over embeddings combined with sparse keyword matching and re-ranking, applied here to decide whether a prior search result actually answers the question being asked now.

Pattern 3 (Freshness-aware ReAct, wiring staleness signals into the reason-act loop)

The standard ReAct loop, observe, reason, act, repeat, has no built-in sense of what the agent already knows, which is harmless in a stateless setting but wasteful once the agent carries memory across sessions. Adding a freshness check to the reasoning step turns the loop from memoryless into one that actually uses its own history.

The modified loop has the agent observe the current task and whatever context carried over from before, then check the episodic log and semantic store for anything already covering the topic. From there it reasons about whether stored state answers the question outright, partially answers it and needs a narrow follow-up search, or doesn't cover it at all and needs a full fetch. It acts on that decision, serving from cache, running a targeted query, or searching from scratch, and before the session ends it writes back whatever it learned so the next wake starts from a stronger position.

Take an agent asked about current pricing for a product it researched two weeks earlier. Rather than re-running the whole search, it issues one narrow query, just for price changes since the last check, and folds the answer into what it already had. That targeted query, the delta search, is the most valuable move available in this pattern, and it only works because the prior retrieval was stored with a timestamp and a topic summary in the first place, which is what Pattern 2 provides. Each added reasoning step costs tokens, so the freshness check earns its place only when it saves more in avoided searches than it costs in extra reasoning, which for any agent that runs often on topics that shift over time, it reliably does.

Pattern 4 (Session-boundary write-back, extracting durable knowledge before an agent sleeps)

An agent that searches during a session but never deliberately saves what it found before going idle throws away the value of every one of those searches. Write-back at the session boundary is the discipline that keeps knowledge compounding from one wake to the next.

Write-back has a few concrete steps. Only then does the working buffer clear, so the next session opens on a clean scratchpad. This is also the moment to update the cache's query embeddings, so the next gate lookup (Pattern 1) can match future questions by meaning rather than needing an exact repeat of the original wording.

The parallel to infrastructure-level snapshotting applies here too. The fix is to write to the episodic log incrementally as the session runs, treating each finished search as its own small, complete entry rather than betting the whole session's memory on reaching a clean finish.

Pattern 5 (Orchestrator-delegated search, letting a specialist sub-agent own retrieval)

Letting every sub-agent in a multi-agent system run its own uncoordinated searches multiplies redundant fetches across the whole fleet. A dedicated search-and-retrieval worker fixes this by owning the cache and enforcing gating and TTL rules for everyone at once.

In this pattern, an orchestrating agent hands off every information-retrieval task to one specialist worker rather than letting each sub-agent search independently. Other agents in the system get back either a live result or a cache hit, but they never reach the web directly, so they can't generate a redundant fetch even if they wanted to. This mirrors the broader orchestrator-worker pattern used elsewhere in agent design, where a planning model breaks work into pieces and hands them to specialists, with the added benefit here of a built-in audit trail: what was fetched, when, and on whose behalf, which helps both debugging and cost tracking.

The Model Context Protocol is the practical glue that makes this work across a system built from different agents. Because a web-search tool can be written once as an MCP server and called by any MCP-compatible agent, the search worker can expose its cached retrieval logic through that same protocol, so every sub-agent that calls it gets cache-aware behavior automatically. The practical fix is to let worker agents read the semantic store directly for simple lookups, reserving the dedicated search worker for the cases that actually require a live fetch.

Pattern 6 (Confidence-gated reflection, verifying retrieved facts before they enter long-term storage)

Storing an unverified search result doesn't just risk one wrong answer. It risks that wrong answer getting trusted and reused across every session that follows. Applying a reflection step specifically at the point where retrieval gets written back closes that gap before a bad result ever becomes a durable "fact."

The mechanics are straightforward. Results that fail outright still get logged to the episodic record, so the agent retains a note that it searched and came up with something questionable, but they never get promoted into the long-term store.

The added cost here, extra model calls and added latency on the write path, is worth paying because the stakes on either side of the gate aren't symmetric. One mistake compounds; the other costs a single retry.

How the infrastructure layer enables or breaks these patterns

Every pattern described so far assumes the agent has a persistent disk, a filesystem that survives going idle, and the ability to wake up quickly. Stateless infrastructure doesn't offer any of that by default, which makes each of these patterns harder to build correctly, or forces an external service to stand in for what the infrastructure itself doesn't provide.

Persistence at the infrastructure layer is what makes several of these patterns cheap. The retrieval cache from Pattern 2 sits on the agent's own disk and is available the instant it wakes, with no network round-trip to some separate cache service standing between the agent and its own memory. The session-boundary write-back from Pattern 4 becomes an ordinary local file write rather than a call to an external API: milliseconds of latency instead of tens of milliseconds, a difference that matters when write-back happens right at the end of a task a user is actively waiting on. The episodic log is simply a file the agent appends to as the session runs, with no external dependency standing between the agent and a record of its own history, which is also what makes it resilient to a session ending abruptly.

The economics here depend on a snapshot-and-restore scheduler, since most agents spend most of their time idle. The agent pays for storage sitting quietly on disk, not for compute sitting idle and billed anyway. Maritime's architecture, each agent inside its own Firecracker micro-VM with a persistent disk, a snapshot-restore scheduler, and wake times of about a second, lines up with what these patterns require: the cache is sitting there on wake, write-back is an ordinary cheap local operation, and the agent comes back fast enough that the gate lookup in Pattern 1 never turns into a delay the user notices.

Choosing which patterns to combine and in what order

Not every agent needs all six of these patterns running at once. Which ones apply depends on how often the agent runs, how fast the information it cares about goes out of date, and whether it's working alone or as one part of a larger multi-agent system.

An agent that runs rarely, or handles a single session at a time, gets most of the benefit from just two patterns: gating (Pattern 1) paired with write-back (Pattern 4), checking stored state before fetching and logging what it found so the next session starts ahead. An agent that runs often and deals with information that shifts quickly needs more structure underneath it: freshness-aware ReAct (Pattern 3) alongside retrieval caching with TTL (Pattern 2), since a useful gate needs an actual structured cache to check against, and a reasoning loop capable of issuing a narrow delta query rather than re-running a full search every time. An agent operating as part of a multi-agent system needs the orchestrator-delegated search pattern (Pattern 5) on top of that, centralizing the cache and the gating rules so the whole fleet shares one source of truth instead of each sub-agent duplicating the others' work. And any agent writing into a semantic store meant to be trusted over a long stretch of time needs confidence-gated reflection (Pattern 6) sitting on the write path, because the longer a store is expected to last, the more a single bad entry costs once it's been relied on a dozen times over.

The patterns build on each other in that order for a reason: complexity gets added only as it's needed, and gating comes first regardless of how simple the agent looks on paper, because it's the one prerequisite that makes every pattern after it coherent. Without a gate deciding whether a search is necessary in the first place, a cache has nothing to be checked against, a freshness-aware loop has nothing to branch on, and a write-back step is just logging work the agent never needed to do. Seen this way, the whole catalog answers a single underlying question: not how an agent calls a search API, but what it stores, for how long, and when what's already stored is enough that the web doesn't need to be asked again.