The God Squad: Inside the Architecture

Five systems. One persistent memory layer. Zero days off.

That's the architecture in one sentence. But one sentence doesn't tell you how data flows between them, where the boundaries are, or why the system is structured the way it is. This is that explanation.

The Five Components

Component	Role	Connects To
OpenClaw	Orchestrator — always-on, handles comms, runs crons, spawns agents	All components
Claude Code	Builder — implements tasks, writes code, opens PRs	GitHub, Asana, CLAUDE.md
Tesseract Intelligence	Analyst — deep reasoning, post-mortems, pattern analysis	InDecision, OpenClaw
InDecision	Trader — 6-factor crypto bias model, PolyMarket execution	Tesseract, market data feeds
Asana	Memory — task lifecycle, intent tracking, project history	OpenClaw, Claude Code

No component is optional. Remove any one of them and the system degrades immediately.

OpenClaw: The Nerve Center

OpenClaw runs on a Mac Mini that hasn't rebooted in three months. It's the only component that's truly always-on — the others are invoked, OpenClaw is persistent.

Its responsibilities break into three categories:

Communication. OpenClaw monitors Discord and handles inbound messages when I'm AFK. Simple queries get resolved inline. Anything that requires implementation gets flagged for a Claude Code spawn. The routing decision is based on complexity heuristics built over months of iteration — they live in lessons files and get refined every time OpenClaw makes a wrong call.

Scheduling. Morning cron at 0700: review Asana for blocked tasks, check recent Claude Code session outputs, scan lessons files for new patterns that need to be promoted to CLAUDE.md. Evening cron at 2200: summarize the day's activity into a dated memory log. Weekly cron on Sunday: generate a retrospective that feeds into the global context.

Agent spawning. When a task crosses the complexity threshold, OpenClaw constructs a context package — CLAUDE.md, the relevant project's lessons.md, the Asana task description, any relevant prior session outputs — and spawns a Claude Code agent. It hands off cleanly and monitors for completion.

The key architectural decision with OpenClaw was keeping it thin. It doesn't reason deeply. It routes, schedules, and monitors. Deep reasoning is Tesseract's job.

Claude Code: The Builder

Claude Code is stateless by design. It wakes up, gets a context package, executes the task, commits to a feature branch, opens a PR, and terminates. It doesn't accumulate state between sessions.

What accumulates instead is the context package itself. The lessons.md file for each project is a living document — every session that runs on that project inherits all the hard-won rules from every previous session. A session that runs today on the blog-autopilot project knows about the Leonardo AI image path bug from November, the MDX table rendering fix from January, and the cover image verification rule that prevents silent failures.

The compounding effect is real. Early sessions on a new project are rough — lots of corrections, lots of new lessons. Sessions six months in are remarkably clean. The accumulated rule set handles most failure modes before they happen.

The branch policy is non-negotiable: never commit to main. Every task lands on a feature branch, goes through CI, and gets merged via PR. This isn't bureaucratic — it's the safety valve. When Claude Code ships something that breaks the build, the failure is contained. The PR never merges. OpenClaw sees the CI failure, creates an Asana task to fix it, and spawns a new session with the error context appended to the task description.

Tesseract Intelligence: The Analyst

Tesseract is where the system thinks, not just acts.

The core use case is post-mortem reasoning. When InDecision takes a loss on a trade, the raw outcome data — entry price, exit price, which factors were active in the bias model at the time, market conditions — gets packaged and sent to Tesseract for analysis. Tesseract doesn't just look at whether the trade was profitable. It looks at whether the reasoning was sound.

A losing trade with sound reasoning is a different problem than a losing trade with flawed reasoning. The first is market noise. The second is a model defect. Tesseract makes that distinction, and the output feeds directly into InDecision's model update cycle.

Tesseract also does architectural analysis. When Knox is evaluating whether to add a new component, refactor an existing one, or change how two systems interact, that question goes to Tesseract. It's the system's design reviewer — the part that asks whether the proposed change creates downstream complexity before the change gets built.

The tesseract-intelligence site exists partly as documentation and partly as an interface for human-readable analysis outputs. When Tesseract completes a deep analysis, the output gets formatted as a structured report that I can read and act on.

InDecision: The Trader

InDecision runs a six-factor crypto market bias model. The six factors aren't public yet, but they cover macro liquidity conditions, on-chain flow signals, derivatives market positioning, network activity, sentiment divergence, and technical structure.

Each factor generates a directional signal. The six signals are weighted by recent accuracy (factors that have been right more often get more weight) and combined into a composite bias — bullish, bearish, or neutral — with a confidence score.

That composite bias feeds two downstream applications:

PolyMarket execution. The PolyMarket bot reads InDecision's current bias and positions accordingly on prediction markets. It's not day trading — it's taking multi-day directional views and sizing them proportionally to confidence. High confidence, larger position. Low confidence or neutral, stays flat.

Trade logging for Tesseract. Every position, win or loss, gets logged with full factor context. When the position closes, the outcome goes to Tesseract for analysis. Winning trades get their factor signature reinforced. Losing trades get dissected for the specific factor that generated the bad signal.

The model doesn't stay static. Tesseract's analysis feeds back into factor weighting every Sunday during the weekly retrospective cron. The model six months from now will be meaningfully different from the model today, and those differences will be traceable to specific trade outcomes.

Asana: The Memory

Every system needs memory. For Knox, Asana is the external brain that persists across all component boundaries.

The structure is intentional: each major subsystem has its own Asana project. Blog autopilot is a project. InDecision model refinement is a project. The Knox core infrastructure work is a project. Each project has its own backlog, active tasks, and completed history.

What makes Asana interesting in this architecture is that tasks don't only come from me. OpenClaw can create tasks. Claude Code can create tasks (it does this when it completes a feature and identifies obvious follow-on work). Tesseract analysis outputs can generate tasks. The system is capable of populating its own workload without my involvement.

The check before any Claude Code spawn: is there an Asana task for this? If not, create one. This isn't bureaucracy — it's provenance. Six months from now, if the system is behaving unexpectedly, I can trace every architectural decision back to the Asana task that generated it and the session that implemented it.

The Data Flows

The system has three primary data flows:

The build loop: I create or review an Asana task → OpenClaw packages context → Claude Code implements → PR opens → CI runs → merge → lessons updated → global context updated next morning cron.

The trading loop: Market data → InDecision processes factors → bias signal generated → PolyMarket bot positions → trade closes → outcome logged → Tesseract analyzes → factor weights updated → model improves.

The memory loop: Claude Code session ends → lessons.md updated → morning cron reads lessons files → patterns promoted to CLAUDE.md → next Claude Code session inherits updated rules → system performs better.

All three loops run in parallel, continuously. They don't have a beginning or end — they just run.

Why This Architecture Works

The honest answer is that it works because each component does exactly one thing well and doesn't try to do anything else.

OpenClaw doesn't reason. Claude Code doesn't persist state. Tesseract doesn't execute. InDecision doesn't build software. Asana doesn't make decisions.

The temptation in system design is to make each component smarter and more capable. The discipline is to keep them focused and let the system-level behavior emerge from clean interfaces between simple components.

That's what I got right. Everything else I've been iterating on ever since.