The hard part of an automated trading system is not making a script produce a signal. The hard part is deciding when a signal deserves a conversation, when that conversation deserves an independent review, and when the whole thing should stop.

That is the problem I have been tightening in the local Trading workspace around Ansem, the paper-first market operations profile.

Ansem cognitive trading loop
Ansem cognitive trading loop Β· swipe sideways or open full size

The operating rule

The control-plane sentence is simple:

Cron jobs detect and schedule. Signals trigger. Ansem thinks. Judges verify. Risk gates decide. Monitors observe. Cleanup closes the loop.

Each verb belongs to a different responsibility. That separation matters because an agent that creates a setup should not be the only thing deciding whether the setup is safe.

What lives in the Trading workspace

The workspace is the local control plane for the loop. It holds the current signals, positions, risk state, decisions, journals, briefs, and lifecycle artifacts. Yahoo Finance is the market-data source for the current scaffold. Kraken CLI is the execution venue being wired behind the gates. Paper execution remains the default while the loop is proven.

The important boundary is this: Ansem can reason about a candidate, but Ansem does not get to turn its own answer into an order.

1. Detect only meaningful edges

The dispatcher reads the latest signal files and normalizes the symbol, action, score, price, and source. It remembers the previous state for each symbol and only creates a conversation when an actionable state changes.

Repeated WAIT states do not create noise. A repeated BUY state does not create duplicate sessions. A transition into an actionable state creates one auditable event.

def research_required(row, action, previous):
    return (action in ACTIVE_ACTIONS and action != previous)

if action == old_action or action not in ACTIVE_ACTIONS:
    continue

write_json(event_dir / "event.json", event)

The event records the source file, generation time, score, price, stop, paper-only status, and whether broader market or social research is required.

2. Give Ansem a bounded question

When an edge is real, the dispatcher starts an asynchronous Ansem session. The prompt tells Ansem to read the Trading workspace, inspect positions and risk state, perform read-only research when needed, and return one strict JSON object.

The response contract includes:

  • decision: BUY, SELL, WATCH, WAIT, REJECT, or HOLD
  • confidence: a number from 0 to 1
  • paper_action
  • live_action: BLOCKED
  • research findings and sources
  • risk-gate status
  • next action
  • timestamp

That contract is not decoration. It makes malformed or overconfident output fail closed instead of becoming an execution input.

3. Let independent judges decide whether reasoning is usable

A valid Ansem verdict is still only an input to the judge layer. The judge checks identity, freshness, research structure, risk fields, and the independent judge artifacts. Then the risk gate checks the things that should never be decided by prose:

  • kill switch
  • NAV drawdown cap
  • gross notional cap
  • leverage band
  • approved trading hours
  • budget and entry limits
  • venue health
  • price sanity
  • required decision artifacts

The maker does not approve itself. Ansem cannot authorize live action. A paper-safe path can still be rejected even when the narrative sounds convincing.

4. Create monitors only after a confirmed fill

A signal is not a position. A submitted order is not a filled order. The monitor lifecycle begins only after confirmed entry-buy fill evidence.

Trading lifecycle state machine
Trading lifecycle state machine Β· swipe sideways or open full size

The lifecycle is:

submitted β†’ fill β†’ watching β†’ stop / target / error β†’ closeout

A confirmed fill can create the exact monitor cron for that position. A stop, target, error, or closeout event can trigger a follow-up Ansem review, but monitoring stays read-only with respect to order placement.

5. Preserve the full audit chain

The useful artifact is not just the final decision. It is the chain around it:

signal file
  β†’ event.json
  β†’ prompt.txt
  β†’ Ansem session
  β†’ dispatch.json
  β†’ verdict.json
  β†’ judge result
  β†’ execution / fill
  β†’ monitor registry
  β†’ lifecycle event
  β†’ closeout

That gives the workspace a way to answer the questions that matter after the fact: What changed? Which signal caused the conversation? What did Ansem see? Which gate rejected or approved it? Was a monitor created only after a real fill? Did cleanup remove the exact monitor when the position closed?

Paper-first is the feature

The current implementation is deliberately conservative. The signal dispatcher never submits orders. The Ansem prompt forces live_action to BLOCKED. The existing execution gates remain in front of Kraken CLI. The examples in this article describe a paper-first control plane, not a promise that the system is free to trade unattended.

That is the point of the architecture. More automation should create more evidence and more stopping points, not fewer.

Why this is better than one giant trading agent

A single agent can look elegant in a diagram, but it hides failure modes. If the same process finds the signal, researches the story, approves the risk, submits the order, creates the monitor, and cleans up the position, there is no meaningful separation of duties.

The cognitive loop is stronger because each part has a narrower job:

  • deterministic scripts detect state changes
  • Ansem handles context and structured reasoning
  • judges challenge the reasoning
  • risk gates enforce hard constraints
  • the venue adapter handles execution
  • monitors observe open positions
  • lifecycle cleanup closes the record

That is how a trading workspace becomes a control plane instead of a pile of cron jobs.

The takeaway

The goal is not to make Ansem β€œtrade by itself.” The goal is to make every meaningful market event produce a bounded, reviewable, auditable conversation that can be accepted, rejected, or safely ignored.

A good system does not ask an agent to be perfect. It makes the consequences of an imperfect answer small, visible, and reversible.

That is the loop we are building.