How I Built an
AI Hedge Fund

The default pattern many developers adopt is to treat a single AI model as a super-powered full-stack engineer: paste a large PRD into one Claude Code or Cursor session, ask for "the implementation," and accept a wide-ranging diff. This approach degrades as the repository grows because:

• The agent's context becomes noisy, mixing unrelated tasks, half-finished explorations, and outdated instructions ("kitchen sink sessions").
• Architectural decisions drift over time because no explicit entity owns patterns or contracts across features.
• Maintenance becomes random: bugfixes are attempted by fresh, generic agents with no memory of why the original design looked the way it did.

These problems are not solved by "better prompts" alone; they require a shift in how teams structure agent responsibilities and state.

The Agent Development Lifecycle (ADLC) extends the classic Software Development Lifecycle (SDLC) with phases tailored to agents' non-deterministic behavior and tool-driven actions. A practical ADLC for AI-augmented software development can be summarized as:

1. Scope framing & problem definition – Clarify business outcomes, constraints, and success signals; decide what agents vs humans will be responsible for.
2. Agent definition & architecture – Determine which agents exist, their capabilities, tools, communication patterns, and where guardrails apply.
3. Simulation & proof of value – Build small proofs-of-value, golden datasets, and baselines to validate assumptions, accuracy, cost, and ROI.
4. Implementation & inner-loop evals – Integrate agents into developer workflows, refine prompts, and run rapid behavioral evaluation cycles on agent output.
5. Testing & validation – Perform end-to-end scenario tests, red-teaming, performance checks, and compliance verification for agent-assisted flows.
6. Agent activation & deployment – Ship agents behind guardrails with observability, roll-out strategies, and defined escalation paths.
7. Continuous learning & governance – Monitor behavior, drift, cost, and failures, then refine prompts, topology, and policies over time.

This lifecycle gives teams a vocabulary and structure for moving from "we used AI in the IDE" to "we operate an agentic development system with explicit phases and responsibilities."

The orchestrator–workers pattern is a foundational topology for multi-agent systems: a central orchestrator dynamically decomposes complex tasks into subtasks, delegates them to specialized workers, and aggregates results. This pattern offers several benefits:

• Dynamic decomposition: The orchestrator can break down ambiguous, large tasks at run time, rather than relying on pre-defined workflows.
• Parallelization: Subtasks can run concurrently across worker agents, speeding up complex workflows.
• Specialization: Workers can be optimized for specific domains (e.g., frontend, backend, infra), improving quality and predictability.
• Centralized coordination: The orchestrator becomes the single place for reasoning about progress, retries, and failure handling.

For software development, the orchestrator reads epics or PRDs, converts them into a task graph with explicit interfaces between components, and routes implementation work to specialized coding agents.

A practical mental model for development with agents uses four recurring roles that map well to both ADLC and real engineering organizations:

• Orchestrator (Architect / PM): Reads epics and PRDs, decomposes work, defines module boundaries and contracts, and decides which sub-agents to spawn.
• Specialist (Feature owner): Implements code for a narrow domain (e.g., "Checkout UI," "Payments backend," "Restaurant event calendar") using Claude Code, Cursor, or custom coding agents.
• Reviewer (Quality gate): Runs targeted review passes, tests, and static analysis over agent-generated changes, similar to tools like Cursor's Agent Review and Bugbot.
• Maintainer (Long-term operator): Owns bugfixes and refactors over time, relying on stored memory about past decisions and constraints rather than inferring everything from raw code.

Consider a realistic epic: "Implement a Stripe-based checkout with discount codes and invoice emails."

A multi-agent approach could look like this:

1. Orchestrator phase

• Input: Product PRD describing checkout flows.
• Output: Sub-epics (Checkout UI, Payments API, Billing & Invoices), contracts (DTOs, event schemas), and agent profiles.

2. Specialist phase

• CheckoutFrontendSpecialist updates React components and state management.
• PaymentsBackendSpecialist implements Stripe interactions and discount rules.
• BillingWebhooksSpecialist handles webhook endpoints and email triggers.

3. Reviewer phase

• A Reviewer agent or CI job checks DTOs, tests critical flows, and validates security/logging standards.

4. Maintainer setup

• Before merging, a memory artifact is produced (/memory/checkout-epic.md) documenting decisions, trade-offs, known gaps, and edge cases.

Without orchestrated roles, several failure modes appear as systems grow:

• Context overload: "Kitchen sink" sessions mix unrelated tasks; Claude's own best-practices docs warn against this and recommend clearing context or using sub-agents when topics drift.
• Architecture drift: New features are implemented with slightly different patterns and contracts, because no agent consistently owns architecture decisions across epics.
• Risky bugfixes: Generic agents asked to "fix this bug" often propose large, cross-cutting changes that ignore original design intent and create regressions.

These issues are why ADLC guidance stresses explicit responsibility mapping, clear boundaries, and continuous governance instead of unstructured prompting.

In agentic workflows, engineering leverage comes from designing systems of agents rather than manually producing code. Modern guidance for agentic SDLC emphasizes preparing teams to work as "AI orchestrators" who design workflows, define guardrails, and evaluate agent behavior. For developers, that translates to:

• Defining roles and boundaries for agents.
• Designing contracts (types, events, APIs) that multiple agents can share safely.
• Curating memory and documentation that both humans and agents can consume.
• Tuning topologies based on cost, reliability, and team maturity.

Today, most Claude Code and Cursor sessions are treated as throwaway: once the code is generated and merged, the session is closed and its context is lost. Months later, when a bug appears, a new generic agent is asked to repair code it has never "seen" before, guided only by the current state of the repository and an often-brief bug description. This pattern leads to:

• Bugfixes that misunderstand original trade-offs.
• Refactors that accidentally break neighboring features.
• Growing mistrust in agent changes, forcing humans to double-check everything manually.

Epic-bound sub-agents address this by making agents long-lived stakeholders in specific parts of the system.

An epic-bound sub-agent is a specialized agent profile bound to a single product epic or vertical slice, such as Checkout, Calendar Events, or Prediction Markets UI. Each epic-bound agent has:

• A clear mission: what business value it owns.
• A bounded scope: which code and tools it can touch.
• A persistent memory: files in the repo that capture its history of decisions.

Rather than one monolithic assistant, a codebase might have agents like:

• CheckoutEpicAgent
• CalendarEventsEpicAgent
• PredictionMarketsEpicAgent
• RestaurantAdminEpicAgent

Epic-bound agents become predictable when each has three explicit artifacts:

1. Charter (mission & boundaries)

Describes the epic's business goal, responsibilities (what this agent owns), non-goals (what is delegated), and non-functional requirements.

2. Scope (visibility & permissions)

Maps the epic to repository paths it may modify (writable) vs read-only, and tools it can call. Often implemented via .cursorrules for Cursor and CLAUDE.md plus project instructions for Claude Code.

3. Memory (stateful history)

Markdown files under a standard path (e.g., /memory/checkout-epic.md). Summarize architecture, trade-offs, known gaps, and edge cases. Updated as the epic evolves, giving future agents a compact narrative of "why" the code looks the way it does.

Charter:

• Name: CheckoutEpicAgent
• Mission: Own the end-to-end checkout experience for one-time purchases, from cart review to payment confirmation.
• Responsibilities: Frontend flows, backend Stripe integration, billing webhook handling.
• Non-goals: Subscription billing, authentication.
• Constraints: Performance budget, clear error messages for payment failures.

Scope:

• Writable: /apps/web/src/features/checkout/**, /services/payments/**
• Read-only: /apps/web/src/features/auth/**, /shared/domain/**
• Tools: Stripe SDKs, email services. Must not modify infra or deployment pipelines.

Memory template (/memory/checkout-epic.md):

1. Business Context — target users, success metrics
2. Current Architecture — flow from cart to payment
3. Decisions & Trade-offs — Stripe integration type, promo rules
4. Known Gaps — unsupported scenarios
5. Edge Cases — retry logic, partial failures

The key advantage of epic-binding shows up during maintenance.

Scenario: Six months post-launch, support reports that some Stripe webhook events are not marking orders as paid.

Naive flow: Open a fresh session → paste error logs → ask "please fix this bug."

Epic-bound flow:

1. Identify the owning epic — the issue belongs to Checkout / Billing.
2. Load the epic's memory and charter — open /memory/checkout-epic.md.
3. Revive the same epic agent — start a new session with the CheckoutEpicAgent profile, including the memory file, bug report, and relevant logs.
4. Ask for a minimal, aligned change — request the agent to reconcile the bug with documented intended behavior and propose the smallest safe change.
5. Update the memory file with the new decision and any new edge cases.

Because the agent is rehydrated with its own history, it is less likely to apply destructive "simplifications" that contradict earlier design rationale.

Epic-bound sub-agents provide a foundation for more advanced capabilities:

• Automated refactoring suggestions per epic, proposed by Maintainer agents as part of continuous governance.
• Periodic drift detection, where agents compare current code against charter and memory to flag violations.
• CI-integrated evaluations, where Reviewer agents run scenario tests and static analysis on agent-generated PRs before human review.

By giving each epic a durable agent identity, scoped access, and shared memory, teams move closer to systems where agents not only generate code but also help maintain and evolve it in a controlled, auditable way.