How I structured the SOP behind an agentic trading system

When I first started building my trading platform, I thought an SOP was mainly a detailed description of the strategy: what conditions create an entry, how risk is managed, and when a position should be exited.

As the project grew, I realized that wasn’t enough.

A trading agent doesn’t only need to know what it should do when everything works. It needs to know what information it is allowed to trust, who has authority at each stage, what evidence must exist before a decision is valid, and what happens when something cannot be determined.

The SOP eventually developed into several layers.

1. Purpose and scope

Every component starts with a clearly bounded job.

It defines:

What the component is responsible for
What it is explicitly not allowed to do
What information it may consume
What outputs it may produce
Which system has authority over its output

This helped prevent specialized agents from gradually becoming general-purpose decision-makers.

2. Inputs and evidence contracts

Each required input is defined before the decision process begins:

Source
Expected format
Timestamp
Maximum acceptable age
Required or optional status
Validation method
Behavior when missing, stale, or contradictory

A price, news article, indicator value, or position state isn’t accepted merely because it exists. The system must also determine whether it is current, valid, and appropriate for that decision.

3. Numbered operational steps

The normal workflow is written as an explicit sequence:

Receive and validate the input snapshot.
Determine whether the system has sufficient evidence to continue.
Evaluate market and strategy conditions.
Apply deterministic risk and authority gates.
Produce a recommendation or management action.
Record the evidence and reasoning.
Route the result to the appropriate human or system boundary.

Numbering matters because every output and failure response must point back to the step that produces it.

4. Decision branches—including “cannot evaluate”

Originally, many decisions had only two branches: yes or no.

That was a mistake.

A condition can also be unknown because the data is missing, stale, conflicting, outside the component’s authority, or impossible to evaluate reliably. “Unknown” must not silently become “no,” and it definitely must not become permission to continue.

Every important decision now needs three possible outcomes:

Condition confirmed
Condition rejected
Condition cannot be evaluated

The third branch normally results in a safe hold, escalation, or stop.

5. Authority boundaries

The SOP distinguishes among:

Observation
Interpretation
Recommendation
Risk approval
Human authorization
Execution
Position management

An LLM may interpret context or coordinate information, but that does not give it execution authority. Hard risk limits and execution permissions remain deterministic.

A recommendation is not an order, and a human approval step is only meaningful if the human receives enough evidence to independently evaluate it.

6. Outputs and traceability

Every output is mapped to:

The numbered step that produces it
The evidence required to support it
The validator that checks it
The authority that may act on it
The response if validation fails

Each decision also receives an identity so the input snapshot, supporting evidence, contradictory evidence, validation result, recommendation, authorization, and eventual outcome can be replayed together.

7. Failure modes

Failure handling is part of the main SOP, not a paragraph added at the end.

It covers situations such as:

Stale or missing market data
Conflicting sources
Provider disconnection
Uncertain broker or order state
Duplicate or delayed events
Agent disagreement
Ambiguous interpretation
Risk-limit violation
Partial completion of a workflow

For each failure, the SOP defines detection, containment, evidence capture, recovery authority, and whether the system may resume automatically.

8. Change control

The live system is not allowed to rewrite its own operating rules because a recent result looks promising.

Proposed changes move through a separate path:

Record the observation.
Form a testable hypothesis.
Test it through replay or controlled simulation.
Compare it against the current version.
Validate it across different conditions.
Approve and version the change.
Promote it deliberately.

That keeps learning separate from uncontrolled self-modification.

The biggest lesson for me was that an SOP is not complete because it explains the intended behavior clearly. It is complete only when every output has a producing step, every decision has an authority boundary, and every foreseeable failure has a defined safe response.

I’m still refining this structure as real testing exposes assumptions I didn’t know I had. I’d be interested to hear how others separate agent instructions, deterministic rules, failure handling, and change authority in their own builds.

3 comments

How I structured the SOP behind an agentic trading system