Operating the Gap: Configuration, Observability, and Maturity
AutoHedge's trust boundary extends beyond its agents and transaction functions. This chapter examines whether the surrounding system can be configured, observed, reproduced, and evaluated well enough to support the autonomy it claims. By following secret names, logs, experiments, dependency declarations, and CI evidence, the reader can distinguish a tool that is easy to try from a trading service whose decisions and failures can be reconstructed.
Configuration is an executable contract
Configuration is often treated as setup work that happens before the “real” system begins. In AutoHedge, that assumption is unsafe because configuration determines which external services are available and which process can sign a transaction. A name in documentation is not merely a hint to a human; it must agree with the name the running code reads.
The README and example environment file document a Jupiter API key, an OpenAI key, an Anthropic key, a workspace directory, and WALLET_PRIVATE_KEY. The signing code reads SOLANA_PRIVATE_KEY instead. As written, a user who follows the documented wallet name can reach the signer with no usable private key, even though the rest of the configuration appears complete. That is a direct configuration-contract mismatch. The source does not tell us whether a deployment outside the repository supplies an alias, so the appropriate conclusion is not that every installation fails. It is that the checked-in instructions and the code do not describe one unambiguous wallet contract.
The search path has a similar issue. The Exa tool requires EXA_API_KEY, while that variable is not shown in the README's environment section or in the example file. The Sentiment Agent is explicitly constructed with the search tool, so a task that reaches that agent can depend on a secret that the standard setup instructions do not name. The failure is different from the wallet mismatch: one can block research input, while the other affects the component that can authorize a transaction. Configuration review should therefore classify secrets by the capability they unlock, not treat all missing variables as interchangeable startup errors.
The CLI's behavior reinforces the difference between warning and validation. It loads environment variables and checks whether OPENAI_API_KEY is present, but if the key is absent it prints a warning rather than preventing the application from starting. That choice may be convenient for a user who wants to inspect the interface, but it leaves failure timing to later agent initialization or execution. A mature service would make the mode explicit: read-only exploration could start without trading credentials, while any mode that can sign would require a separate, successful preflight for the wallet and venue contract.
The same principle applies to configuration values that are not secrets. A workspace directory, output location, model name, venue, and operating mode all affect reproducibility. If two runs use different values without recording them, a later reviewer may not be able to explain why their outputs differ.