AutoHedge
AutoHedge architecture: a director with handoffs is not an enforced four-step pipeline
Follow the actual wrapper, module-level workers, conversation state and unconnected tool registry instead of treating the README diagram as executable control flow.
What you will learn
- Trace the executable entry
- Understand object lifetime
- Separate data access from signing
Before you start
- Basic Python, Git and dependency-management knowledge
- A fictional evidence task with no wallet or signing authority
Explain the inspected implementation and its counterexamples without mistaking a simulation or generated text for a verified financial outcome.
Key takeaways
- Handoff availability does not prove a mandatory role sequence.
- Wrapper conversation state differs from module-level agent state.
- Tool attachment, schema enforcement and signing policy are separate concerns.
Trace the executable entry
AutoHedge.run adds the user task to its Conversation, calls director_agent.run(task=task), adds the returned director output and converts the conversation to list, dictionary or string. Unknown output_type values fall back to a list. Extra positional and keyword arguments accepted by the wrapper are not forwarded in the inspected call.
The README depicts Director → Quant → Risk → Execution. The implementation instead passes four workers, including sentiment, to the director through handoffs. This assembly does not itself impose that fixed order or demonstrate that every role runs. Actual dispatch and model behavior depend on the resolved Swarms implementation, which was not exercised here.
Understand object lifetime
Workers are module-level objects. Their shared date/time suffix is computed once at import using datetime.now; it is not refreshed automatically for each task by this file. A long-lived process can therefore keep an old “current” time in prompts. The source does not justify assuming a refreshed market timestamp from that suffix.
An AutoHedge instance keeps one conversation across repeated run calls. The isolated fake-director probe produced four messages after two successful calls. The REPL creates a new wrapper for each task, but this does not reconstruct the module-level director. Wrapper history lifetime and worker lifetime must be tracked separately.
Separate data access from signing
The sentiment worker explicitly receives Exa search. Risk, quant and execution workers are configured for string output and are not given the Jupiter registry in this module. Their prompts request structured metrics, but those requests are not an application-level numeric validation schema or a hard risk gate.
The registry lists search, price, order, holdings and execution functions in a separate file. Attaching it would materially change authority and requires a reviewed integration, not merely a documentation edit. The architecture diagram deliberately leaves that boundary visible; this series does not wire the registry into live workers.
Implementation steps
- 1
Trace imports from the console entry to workers.
- 2
Record which worker explicitly receives which tool.
- 3
Test wrapper state with injected collaborators.
- 4
Review any future signing integration as a distinct authority change.
Copy-ready example
{"wrapperCalls":"director_agent.run(task=task)","handoffWorkers":4,"fixedRoleSequenceEnforcedByWrapper":false,"promptClock":"module import","conversationMessagesAfterTwoFakeRuns":4,"liveWorkerStateTested":false}Frequently asked questions
Are all four specialist roles guaranteed to run in order?
The inspected wrapper does not enforce that sequence; it calls the director, whose handoff behavior belongs to the external agent framework.
Does a new REPL task recreate all worker objects?
It creates a new wrapper, while workers remain module-level objects after import.
Sources
- README.mdSource checked 2026-09-08
- autohedge/main.pySource checked 2026-09-08
- autohedge/workers.pySource checked 2026-09-08
- autohedge/prompts.pySource checked 2026-09-08
- autohedge/tools/tools_registry.pySource checked 2026-09-08