Checkpoint: Trace One Candidate without Calling It a Trade
CloddsBot’s first four layers—gateway routing, capability loading, session continuity, and market feeds—become meaningful only when they are followed together. This checkpoint uses one hypothetical request to connect those layers and to draw a firm line between a routed request, a loaded capability, a returned datum, and an actionable trade candidate. The reader should leave able to say not only what CloddsBot found, but what the system still has to establish before external action would be justified.
A request has a chain of custody
Imagine a user asks CloddsBot to compare two markets about the same economic event and report whether a price difference matters. The wording is intentionally incomplete. It asks for a comparison, not a fully specified order, and the system should preserve that incompleteness while it gathers context.
The request first arrives through a channel or WebChat. CloddsBot normalizes the platform-specific event so the rest of the application can work with a common message shape. The gateway checks for a recently processed duplicate and may apply channel-level limits. It then associates the message with a session belonging to the relevant user and conversation. At this point, nothing about the market has been established. The system has established where the request came from and which conversation should own the result.
That distinction is the first part of the request’s chain of custody. A message identifier helps prevent one transport event from being processed twice, but it does not tell the system which market the user meant. A session preserves continuity, but it does not make an old reference current. An access check can allow the user to proceed, but it does not validate the requested event. Each control answers a different question.
The gateway next checks whether the message is an explicit command. If it is, the command registry may handle it directly. If it is not, the agent manager receives the normalized message and the session. The command branch and the agent branch share the same broad destination—an answer delivered through the original channel—but they reach it differently. A deterministic command can avoid model interpretation. A conversational turn can use the agent to select a capability, ask for more context, and combine several results.
For the hypothetical comparison, suppose the conversational path is used. The agent manager checks access and its own rate limit, then runs the configured before-message hooks. It builds the user’s trading context, which may include available credentials, a maximum order size, and a dry-run setting. It loads the relevant session history and memory, selects a model, and makes the tools needed for market lookup available. These steps prepare the question; they do not answer it.
A capability is now available in a second sense. The model can call a market-search or market-data tool because the tool definition has been exposed and the corresponding handler is available. That does not mean the tool will find the intended event, that the result will be fresh, or that the user has permission to place an order. “The agent can use the tool” describes a capability transition, not a market transition.
The handler then asks the feed layer for evidence. If the search spans venues, FeedManager may query active feeds in parallel, combine the results, and sort them by a useful discovery field such as recent volume. The returned objects may have different origins and different data quality. One may be a public read-only observation; another may be associated with an executable venue.