What the System Can Know: Data, Tools, and Instrument Identity
AutoHedge's next engineering boundary is information. This chapter asks not which APIs appear in the repository, but whether their output actually enters the Director or Quantitative Agent's decision path, with enough freshness, completeness, and identity to support a grounded thesis. Following a connector from definition to attachment—and then checking whether it refers to the right instrument—lets the reader judge what AutoHedge can know before judging what it should do.
A connector is not yet an input
A trading system can contain a data capability in at least three different senses. A client can be callable: some code knows how to make a request. It can be registered: a central list exposes the function to another component. Or it can be attached: a running agent has access to it at the point where a decision is being made. Those states are often collapsed into one word—“integrated”—but they carry very different evidence.
AutoHedge contains examples of the first state. Its stock-oriented code includes retrieval for recent quotes, historical prices, company information, financial statements, and related data. A separate HTTP client exposes ticker overviews, balance sheets, and daily summaries through a Massive/Polygon-compatible interface. These clients are meaningful building blocks because they define possible routes to external information. Their presence does not show that a Director has received a particular response, that the Quant Agent used it, or that the response was current when a thesis was formed.
The Jupiter code provides another set of callable capabilities for Solana tokens: token search, price lookup, wallet holdings, order construction, and execution. A tool registry returns several of those functions as a list. Registration is a step closer to use, but it is still not the same as use. In the visible AutoHedge path, no core agent or entrypoint calls that registry. The repository therefore gives us evidence that the functions can be offered, not evidence that a live analysis run consumed their output.
The Sentiment Agent supplies the clearest contrast. In the worker definitions, exa_search is explicitly passed as a tool when that agent is constructed. That is direct evidence of an agent-tool relationship: the Sentiment Agent has been given a defined search capability. It still does not prove what query it will issue, which results it will receive, or how the Director will weigh them. But it is materially stronger evidence than a function sitting in an unconsumed registry. The distinction is not about whether one external service is inherently better. It is about whether the repository shows the connection at the decision boundary.
This three-state model changes how AutoHedge's architecture should be read. Counting clients can make a project look data-rich while hiding a thin path from observation to judgment. Conversely, a small number of attached tools can be valuable if their inputs, timestamps, errors, and outputs are explicit. For each connector, the important questions are: who calls it, when, with what identifier, what does it return on failure, and which later component is responsible for interpreting the result?
Those questions also reveal why the Quantitative Agent's prompt cannot supply its own evidence. The prompt asks for technical scores, volatility, probability, and key price levels. Unless the agent is given a defined observation window and a reliable data object, those fields describe an expected answer rather than a calculation with known provenance. A model may know general market concepts, but general knowledge is not a current quote or a reproducible measurement. AutoHedge's source contains retrieval clients, yet the core worker construction does not visibly bind the stock or token clients to the Quant Agent.
That separation has a useful trade-off. Keeping clients separate from agents can make the system easier to replace and can prevent one specialist from owning every external dependency. It can also leave the application with an attractive toolbox and no clear dataflow. Modularity helps only when ownership is explicit. A connector should have a defined caller, a representation of freshness, an error state that downstream code can understand, and a rule for whether analysis may continue when the connector fails.
The repository's stock-data code anticipates that external information is not always complete. Its Yahoo Finance client retrieves historical data first and has handling for rate-limited or invalid quote responses, allowing partial information in some conditions. That is an important implementation detail because a market-data failure is not binary. A recent price may be available while company information is missing; a history series may be present while a summary request is blocked. If a downstream agent sees only an empty field or a generic string, it may treat missing evidence as neutral evidence. If the failure is carried as an explicit status, the system can lower confidence, request a retry, or decline to trade.
The same principle applies to search and token services. A search result has a collection time and a selection process. A token price has an asset identifier and a market context. A wallet balance has an address and a point in time. Returning a value without those qualifiers makes it difficult to tell whether two agents are discussing the same observation. AutoHedge's repository exposes several external-service interfaces, but it does not define a common evidence envelope that would carry these meanings from a tool into a thesis.
Instrument identity is a safety boundary
Data can be fresh and still be wrong for the decision. AutoHedge's prompts repeatedly use the language of stocks: company tickers, earnings, analyst reports, technical indicators, and US exchange symbols. The ticker-discovery prompt specifically asks a model to return an array of US stock symbols. Its concrete execution functions, however, accept Solana mint addresses and amounts in the network's smallest units. The stock clients and the Solana clients do not identify the same kind of object.
This is more than a vocabulary mismatch. A stock ticker is a human-facing symbol whose meaning depends on an exchange and sometimes on an asset class. A Solana mint is a blockchain address that identifies a token on a network. A stock quote, a token price, a wallet balance, and a swap amount have different units, sources, and settlement assumptions. A thesis about one cannot safely become an order for the other merely because both can be represented as strings.
The current source does not show an adapter that maps a stock thesis and symbol into a Solana asset, nor a venue-aware policy that prevents such a mapping from being assumed. That is a bounded conclusion about this snapshot. The project may be in transition: its README names Solana as the current supported venue, while its prompts and data clients retain stock-oriented language and its experiments explore other crypto venues. But until an explicit identity layer exists, the system cannot be credited with solving the cross-domain problem simply because it contains both kinds of code.
A useful identity layer would settle several questions before analysis becomes actionable. Which venue is being discussed? Which canonical identifier represents the instrument there? What currency and unit does each price use? Is the observation a quote, a historical close, a token price, or a simulated value? Are the data and the proposed action about the same asset, or only about related narratives? These are not implementation niceties. They determine whether a risk calculation refers to the position that an execution function can actually submit.
Ticker discovery shows why a prompt is not a stateful dataflow. The repository contains a prompt asking the Director to produce only a JSON list of relevant US symbols. If used as an application stage, that result would still need to be stored, parsed, checked for empty or ambiguous values, associated with a venue, and passed to a data request. The visible runtime passes the original task directly to the Director; it does not show a call to the discovery template, a loop over the resulting symbols, or an attachment of market-data snapshots. Natural-language intent is present, but the transitions that would turn intent into a reliable input are not locally demonstrated.
The difference can be pictured as a path with several possible stops:
The diagram does not claim that every branch is executed. It separates three kinds of evidence: a task can name an object; a client can retrieve information about an object; and an attached tool can provide information to an agent. Between those points sit identity, freshness, completeness, and provenance. If any of them is unresolved, the result should remain an unresolved analysis input rather than being silently promoted to a trade thesis.
When incomplete data changes the decision
The practical consequence of data lineage is not that AutoHedge must reject every imperfect response. Real external services fail, rate-limit, return partial records, or disagree about timing. The consequence is that the system needs a declared response to each condition. A current history series with a missing quote summary might support a narrow technical observation but not a broad fundamental conclusion. A search failure might leave sentiment unknown rather than negative. A token lookup that returns multiple candidates might require clarification rather than letting a model choose by name similarity.
These distinctions matter because an agent's confidence is not an independent measurement. It is an interpretation of the evidence available in its context. If missing fields are invisible, the model may fill the gap from prior knowledge or linguistic expectation. If stale and current observations are mixed, the model may produce a coherent narrative with no coherent time basis. If a ticker is valid in one market but not the execution venue, a technically correct analysis can still produce an invalid action.
AutoHedge's separation between clients and workers makes this a design choice that still needs an owner. The data layer could return a structured observation with source, timestamp, completeness, and failure status. The Director could decide whether the task is answerable. The Quant Agent could calculate only from supplied observations. The Risk Manager could refuse to size an exposure whose identity or holdings are unresolved. The source does not show those contracts, so these are the control boundaries that a future implementation would need to make explicit, not features that can be credited to the current one.
There is also a trade-off between breadth and traceability. AutoHedge's repository points toward several classes of information—stock fundamentals, historical prices, web search, token metadata, token prices, and wallet state. More sources can broaden an agent's view, but they also multiply opportunities for conflicting timestamps, different units, and unequal reliability. A smaller evidence set with clear provenance may support a more defensible decision than a larger, loosely connected set of responses. The relevant measure is not how many tools a project contains. It is whether a reviewer can reconstruct which observation caused which conclusion.
This is why the explicit Exa attachment matters without being sufficient. It gives one agent a visible route to search, so a reviewer can ask what query was made and how the result was incorporated. The unconsumed Jupiter registry gives a reviewer a different question: where, if anywhere, is token data requested during a core run? Both questions are useful, but they are not interchangeable. An attached tool can be tested at its boundary; a registered tool first needs a caller and a place in the decision graph.
For AutoHedge, the immediate lesson is precise. The project has enough data-client and tool code to suggest several possible trading workflows, but the current evidence does not establish one unified information path from task to grounded thesis. Its stock-oriented prompts, Solana-oriented execution interfaces, and experimental crypto components make instrument identity especially important. Before asking whether an agent's conclusion is persuasive, a reviewer must be able to answer what the conclusion is about, which observations support it, and what the system does when those observations are incomplete.
That answer will shape the first major judgment in the series. AutoHedge has a recognizable agent design and a set of external-service building blocks, but those facts do not yet say how much of a complete trading system is present. The next checkpoint brings the promise, call path, and information boundary together. It asks what a hypothetical task can legitimately establish—and why even a well-grounded analysis still stops short of authorizing a transaction.