System Architecture
Four cooperating layers, designed so that honesty and safety are properties of the system, not a hope pinned on a prompt.
Warren is the flagship application built on Kodeus, an agentic orchestration platform for running autonomous systems at scale. Warren supplies the trading intelligence and the honest-fund-manager persona; Kodeus supplies the generic machinery to run it continuously, safely, and per-user. The four layers below trace that split.
The architecture follows from a few commitments: agent behavior is a pluggable overlay on a generic runtime (no fork, the agent is configuration, not code); the domain intelligence lives in a runtime-agnostic analysis engine any agent can attach; every piece of state is scoped to a single user; heavy work is asynchronous and routed to right-sized compute; and safety rules are hard mechanisms that can replace an answer or veto an action.
Powered by Kodeus. The split is deliberate: Warren is what to say and what to refuse, Kodeus is how to run it safely for many users at once. Because the agent is a declarative overlay rather than a fork, its honesty and safety properties are enforced by the platform, not left to the model's goodwill.
Layer 1: the agent
Warren itself is a declarative spec, role, goals, skills, and the intelligence engine it attaches, plus a small extension that plugs into the runtime through open hook protocols. Three hooks are enforcement, not advice:
- A house-rules injector reasserts the honest-uncertainty persona and the abstention contract every turn.
- A final-answer guard replaces the entire answer with a standardized honest abstention whenever the abstain condition fires (the model cannot soften it) and forbids fabricated numbers.
- The tool-call gate vetoes state-changing actions on unattended runs unless autonomous execution was deliberately armed (see Autopilot).
Layer 2: the Kodeus runtime
A single generic execution engine, the Kodeus runtime, turns any agent spec into a running, multi-user agent. It owns only generic stores, configuration, conversation, memory, encrypted credentials, and the knowledge corpus, and no trading tables at all, which is what keeps it generic. Isolation is two-tier: one container per agent, and per-user contexts inside it, with every stored row keyed to the individual user.
Layer 3: the intelligence engine
The engine is where the "be right" work concentrates: roughly 64 capabilities spanning market data, strategy authoring, backtesting and optimization, execution, analytics, and the marketplace. Every request is resolved to a per-user context that scopes all data access. Its honesty guarantees, closed-candle discipline, out-of-sample gating, deflated-Sharpe reporting, coverage verdicts, live inside the engine, so any agent that attaches it inherits them rather than re-implementing them.
Layer 4: compute and async jobs
Backtests and optimization never run in the conversation path. Each is submitted as a job: a router estimates its weight (pairs × days × candle density) and dispatches light jobs to a serverless function and heavy or tuning jobs to a container task; the worker writes results to object storage and marks the job done; polling returns the results with their risk-adjusted statistics computed at read time and infrastructure details stripped. Stale jobs whose compute died out-of-band are reconciled to failed rather than left "running" forever. Strategies are content-addressed, so every result ties to the exact code that produced it.
End to end: ask, regime read, backtest, deploy
A single request threads all four layers, and passes two hard guard moments where the system can override the model: the coverage verdict can end the turn with an honest abstention before any directional claim is made, and the tool-call gate can veto a deploy on an unattended run while reads still pass.
The regime engine supplies the coverage verdict at the first guard moment, and the validity layer supplies the caveats and the earned-or-withheld deploy option before the second. An in-sample result is never framed as "go live," deploys are validated against the venue registry, and money movement stays confirm-gated throughout.
The load-bearing points are all mechanisms, not intentions: the coverage verdict can end a turn before any directional claim, backtests arrive with their statistical honesty attached, deploys pass venue-registry guardrails, and unattended runs cannot change state unless deliberately armed. None of these properties depend on the model choosing to comply.
Where this fits
The Validity Layer
One deterministic check for each way a naive backtest number misleads, composed into a single honest verdict.
Runtime Configuration
Set trading defaults for new deployments, then let account-wide risk limits (leverage cap, drawdown caps, per-strategy limits, loss-streak pauses) act automatically in code.