The harness becomes an economic interface
I moved from the hardware side to the harness side. The harness is the agent's execution surface and what the rest of this track will focus on. It connects a model to memory, tools, credentials, payments, and the outside world. Moving from hardware to harness shifts attention from who supplies intelligence to who controls execution and the information produced along the way.
The word harness doesn't really make you think of a market. Operationally, however, it governs which context reaches a model, which tool calls it can make, which permissions accompany them, and how results return. Hardware supplies computation; the harness determines how that computation becomes an action in a market.
As I put it, agent markets can be analyzed as communication between harnesses. One configured system sends an intent or tool call to another, and the two boundaries enforce the terms. You can analyze this from a harness perspective because the transaction is carried by models plus memory, credentials, policies, and tools—not by a bare model.
“Markets of agents are basically just harnesses talking to harnesses.”
If agents become the main economic interface to markets, harnesses become economic interfaces too. The same model can act for different principals when its harness supplies different memories, identities, and spending authority. Conversely, a nominally decentralized market can concentrate control in a shared execution provider. Economic agency inherits the constraints of the machinery around the model.
Four surfaces define the privacy boundary
I broke the harness into a four-part surface map One is identity and auth. Two is payments, including transactions in Ethereum or the blockchain and sometimes intents. The remaining surfaces are tool calls and cooperation. They overlap in practice: one tool call can authenticate an agent, spend money, and disclose information to another service at the same time. It makes market structure visible where an abstract capability becomes a concrete permission, call, or transfer.
This is a very rough mental model, meant to break it down for this section rather than impose a formal taxonomy. When an agent fails to act, gains privileged access, or leaks information, the map helps locate which surface carried the decision.
Put on your market structure hat and privacy becomes part of the mechanism. There are many arguments that the ability to operate privately in the market is paramount to market efficiency. The harness must preserve that ability across each exposed surface, not merely inside the model or memory store. Search is a useful test because a tool call can itself disclose strategy. Protecting memory does not hide the remote query, while encrypting content does not hide network or payment metadata.
The practical question is whether you can do all of these agentic things with your harness and actually preserve your privacy. An agent may inspect local material, derive a query, send it over the internet, receive results, and pay a provider.
Search APIs form a remote market
For this test, an agent has some type of model: it can be local or remote, it has memory, and it has tool calls. The query may summarize what the agent knows, wants, or plans next, making the request a statement of intent as well as a retrieval operation. A local file lookup and a remote web request can satisfy the same need while creating very different ownership, latency, and privacy boundaries for the harness.
That path is one area where information can be leaked. Search therefore has three relevant properties: where retrieval runs, how the provider is paid, and what the interaction reveals. Search crosses those components and reaches the open internet or a private internet.
There are now search engines built for agents, which raised my first question: what makes these search engines agentic? Exa presents itself as the search engine for AI, while Parallel describes infrastructure for intelligence on the web. Both use embedding-based retrieval, but established search providers use similar techniques. Embeddings alone do not define an agent-facing market. An agent service might instead charge through an API, compress results for model consumption, or collect payment per search.
The redistribution mechanism may matter more. Humans get fed ads, and those ads pay for the search engine. It is unclear what that means to an agent; you probably don't want your agent to be fed ads inside its reasoning loop.
Local corpora change who owns retrieval
Human search returns pages and promotions to a person. An agent tool returns material that another model will reason over, so promotional content can affect downstream decisions rather than only attention. A paid API removes the ad, but payment identity and policy join the retrieval boundary. Search goes over the remote internet, and payment may expose the caller again. A lot of agent search is actually local as well, even when operators call it grep, indexing, file lookup, or retrieval.
From the harness perspective, these are still tool calls that locate information. The important distinction is that local lookup works over material already held, while public-web retrieval discloses the immediate question to a remote provider.
Search can be over your local data—what you've already captured—or remote data on the public web. Local retrieval changes when disclosure happens. Operators can collect likely sources ahead of time and let an agent query a private copy later. That moves work from question time to collection time and changes both latency and which observer sees the request. The operator still decides what to capture, how often to refresh it, and whether to trust the cache.
Talk to anyone running agents and they're scraping massive amounts of data. The resulting boundary is porous: an agent may search locally first and use the web only for gaps, or scrape remotely on a schedule and reuse the corpus throughout the day.
Agents can build their own search layer
The examples in the room followed this pattern. One operator learned that the U.S. Patent Office was taking all of the patents off their API and began preserving the material. Another had an agent checking Hacker News, GitHub, and a few other things every morning. Scheduled collection reduced the need for a revealing remote call at task time.
These anecdotes suggest a common stack: a collector makes remote requests in bulk, a local index stores the results, and later reasoning searches what was captured. The workflow can be faster and reveal less at query time. It does not eliminate privacy cost; it moves the cost into collection and storage, while the agent need not make those calls during every task.
Zero-click search points in the same direction. A zero-click search is when a search interface supplies an answer before the user follows a result. I cited talk-reported figures of 58.5% of searches ending without a click in 2024 and 68% by early 2026. Those figures were not independently verified here, but the interface change is the relevant mechanism.
Once a user is not clicking on a link anymore, retrieval, synthesis, and browsing separate. My claim was that this entire portion of the market could get eaten up by local search: an agent captures likely sources, synthesizes over them, and avoids repeated public queries. The shift also disrupts the familiar advertising and referral loop.
TEE and cryptographic search protect different things
Public search offers two broad paths. Conventional services run over the public internet, provide no guarantee around privacy, and remain largely built for humans. A second class consists of search engines that are purposely blind. Some of those search engines run in TEEs; others use more elaborate cryptography. The two approaches protect different trust boundaries rather than supplying one interchangeable privacy label. Paying per search with a standard that does not preserve privacy creates another way an agent's identity can leak, even when query content is protected.
No matter whether an agent is hitting a public search engine or a private one, it is still coming from some type of IP. Query timing, frequency, size, and payment metadata can also link repeated calls.
TIPTOE provided the private-search example. The user or agent has a search request, while on the other end there is an index. Both of these objects are encrypted in this scenario. A party can scrape a useful part of the web, build an index, and publish it as ciphertext; no operator needs to expose its contents to run retrieval.
The user sends the encrypted query to a server, which performs an operation over the encrypted index. The results are also encrypted to the person who initiated the search. Only that person decrypts the returned links. Embedding-based search supplies the matching layer, but I did not explain the underlying cryptography onstage and did not claim expertise in it.
Encrypted answers can still leak identity
The interface suggests a private service: someone builds an index of a useful slice of the web, encrypts it, and lets agents submit protected queries. No one can actually see inside the index or understand what is inside; the server sees an encrypted blob. The deck names a related prototype, Periscope, without establishing ownership, deployment, or current status.
Retrieval quality creates a second tension. Search queries are getting longer and longer over time—by the talk's estimate, roughly two words per year—while in embedding search longer queries often retrieve worse matches. Effective agent retrieval may split one request into many small searches, multiplying the number and pattern of observable calls.
“Even if you have one of these private search engines, you can still be revealed through your metadata.”
Even with encrypted retrieval, this IP can make the same ten queries every single day. A search operator may correlate the source IP, timing, count, and response size, then start to correlate that identity without reading the content. Repetition becomes a fingerprint that links nominally private calls to one agent or organization.
The lesson is that you can still be revealed through your metadata, even if you have one of these private search engines. A private harness must therefore control routing, timing, batching, and payment. It may hide the source IP or mix calls with other traffic before reaching the encrypted index, preventing content and network behavior from recombining into an identity.
Round-based privacy may fit agent search
Trying to hide metadata leads to several network designs. Tor uses onion routing: you take your message and you encrypt it three times for three relays, which peel off one layer at a time. Nym-style mixnets and DC-nets differ because they are round-based protocols. A request may wait for a round rather than leave immediately. The protocol must progress through the rounds before it starts letting the message in.
That delay looks costly for interactive search, so I wanted to explore whether agents would tolerate round-based protocols for search. With Tor, you fire a request off straight away; with a round-based protocol, it may arrive midway through the round and wait.
I augmented my agent with tooling to record when it was using web-search tools, then gave it deep-research tasks. With access to sub-agents, it performed six web searches in parallel in roughly two rounds, thought for a while, fetched more material, and repeated the pattern. The trace was bursty and batched rather than one continuous sequence of clicks.
The tool calls were bottlenecked by the agent's ability to think and reason over responses, especially when another remote-model call followed. In that workload, agents use search differently from humans: they are tolerant of wait times and can schedule things ahead intelligently. That supports testing round-based privacy, not claiming every protocol fits every agent workload.
“Agents don’t have the same profile as humans for search, where they’re quite tolerant to wait times, and they can also schedule things ahead intelligently.”
Appendix
The deck's concept map belongs to the event framing, not to dmarz's first-person talk body. It connects four broad themes—AI for MEV, MEV-aware AI, agentic markets, and the infrastructure path from hardware to harness—and situates this presentation in the last branch. The map is useful orientation for readers, but its labels should not be treated as claims that dmarz developed every adjacent topic. Tina's earlier spoken introduction is likewise excluded from the first-person narrative; this appendix preserves only the slide-attributed relationship among the program themes.
Glossary & further reading
agent harness — An agent harness is the execution layer around a model. It supplies memory, tools, permissions, identity, payments, scheduling, and other controls that turn a model response into action.
trusted execution environment (TEE) — A trusted execution environment is a hardware-based, attested environment intended to protect data while computation is running. It is one approach to confidential service execution, not a complete anonymity system.[6]
private search — Private search aims to return useful matches without revealing the query, corpus, or results beyond the intended parties. Different systems protect different pieces and may still expose traffic metadata.[4]
mix network (mixnet) — A mix network relays messages through intermediaries and mixes them with delays or cover traffic to resist traffic analysis. Its round or latency profile can differ from low-latency onion routing.[5]