The Data Layer Decides What the Agent Can See
CloddsBot’s market-data problem is not simply how to fetch a price. It is how to give one agent a common view of venues whose APIs, update speeds, and market semantics differ. This chapter follows a datum from a configured feed through search, caching, subscriptions, and the signal bus, then examines the crucial boundary between a native orderbook and an approximation. The reader will be able to judge market evidence by source, freshness, depth, and event path before treating it as a basis for action.
From configured venue to shared evidence
CloddsBot places a FeedManager between the agent and individual market providers. The manager exposes a common set of operations: find a market, search markets, read a price, retrieve an orderbook, subscribe to updates, and obtain related news or edge information. The value of that interface is organizational. The agent can ask for a market without knowing whether the answer comes from a centralized exchange API, a prediction-market service, a sports exchange, or a blockchain-connected adapter.
The interface is not a claim that the venues are equivalent. It is a translation layer with a known responsibility: return data in a shape that downstream components can consume. The feed adapter still owns the platform-specific request, authentication, conversion, and connection behavior. If those details are flattened too early, the agent may receive a clean-looking price while losing the information needed to interpret it.
The lifecycle begins when the gateway creates the feed manager from configuration. Only configured integrations are initialized, alongside a few read-oriented feeds that the application enables by default. Starting the feeds is deliberately isolated. The manager attempts to start each one and records an error for a failure rather than allowing one unavailable venue to reject the whole startup. This is valuable in a multi-venue system: an operator can still inspect available markets when one optional provider, SDK, or credential is broken.
The trade-off is partial availability. “All feeds started” does not mean every venue is usable. It means the startup procedure completed its attempts. A feed may have been skipped after an error, may expose only public data, or may be connected but return stale or incomplete information. The control plane must preserve that distinction so a degraded data source is not silently treated as a healthy one.
A market search without a platform restriction fans out across the active feeds in parallel. The results are combined and sorted by recent volume. This makes a natural-language query useful: the agent can search for a topic across venues without issuing separate platform-specific calls. It also means the response is a composite view. The result set may mix different market types, liquidity conditions, currencies, outcome conventions, and update times. Sorting by volume improves discoverability; it does not make the first result the correct market.
The manager places a short-lived cache in front of individual market lookups. In the current implementation, the market cache is bounded by both an entry limit and a time-to-live. A successful lookup can be reused briefly, and a failed or empty lookup can also be cached to avoid hammering a provider. This reduces repeated network work during one agent turn or several nearby requests.