Your agent has a strategy.
TMOM gives it boundaries.
From trading discipline
to execution governance.
TMOM began with a simple observation: having a strategy does not guarantee that execution will follow it.
That problem becomes more consequential when execution is delegated to autonomous agents. An agent may reason, adapt, call tools, consume market data, and submit orders—but it should not be solely responsible for deciding whether its own action remains inside mandate.
TMOM now occupies that missing control point. It sits after strategy formation and before execution, independently evaluating what the agent intends to do.
BEFORE
A trading application
Interpret a trader’s rules, monitor discretionary execution, connect to trading infrastructure, and intervene when human behavior deviates.
NOW
An independent policy layer
Receive structured intent from any trading agent, evaluate it deterministically, return an approval decision, and leave execution to the agent’s existing broker client.
The core principle remains the same: the system executing a strategy should not be the only system deciding whether execution is allowed.
Execution agents are built to act.
They should not police themselves.
One policy check
before every order.
The agent owns strategy generation, market-data access, broker connectivity, and execution. TMOM owns policy evaluation, decision explanation, audit logging, and replay.
Represent the trading mandate as a structured, versioned strategy contract.
Compile the strategy contract into deterministic guardrails before the trading session begins.
The agent submits an order intent together with strategy version, account state, and relevant market state.
TMOM evaluates the complete snapshot and returns a structured policy decision with machine-readable reasons.
The decision, policy version, input snapshot, reason graph, and eventual outcome become part of a replayable audit trail.
Five outcomes.
No ambiguous approval.
These are policy decisions returned to the calling agent. TMOM does not submit, cancel, or modify broker orders.
Control infrastructure,
not another trading brain.
TMOM DOES
- ✓ Validate strategy contracts
- ✓ Compile explicit guardrails
- ✓ Evaluate proposed orders
- ✓ Track policy versions
- ✓ Return structured decisions
- ✓ Produce reason graphs
- ✓ Maintain decision records
- ✓ Support deterministic replay
- ✓ Coordinate shared risk state in higher tiers
TMOM DOES NOT
- × Predict market direction
- × Recommend securities
- × Generate alpha
- × Select strategies
- × Hold customer funds
- × Store brokerage credentials
- × Route orders
- × Replace the execution agent
- × Operate as a broker or investment adviser
A hosted decision check is one production evaluation performed through check_order_intent using the Hosted MCP endpoint, REST API or Python Client.
Quintus prepares one mandate. Fabius enforces policy in production. Maximus coordinates multiple agents against shared risk state.
The integration method does not determine the plan. Hosted MCP, REST API and the Python Client are different interfaces to the same TMOM hosted policy service.
Does TMOM execute trades? expand_more
No. TMOM evaluates proposed actions and returns policy decisions. The trading agent retains its own execution client and broker connection.
Does TMOM require my brokerage credentials? expand_more
No. Broker credentials remain inside the user’s or agent’s execution infrastructure.
Does TMOM generate strategies or trading signals? expand_more
No. TMOM does not generate alpha, recommend trades, or select securities. It governs execution against a strategy supplied by the user or agent.
What makes the decision deterministic? expand_more
The policy version, order intent, account state, and market-state snapshot are explicit inputs. Identical inputs produce the same evaluated result.
What does BLOCK actually do? expand_more
BLOCK means TMOM refuses policy approval. The calling agent is responsible for consulting TMOM before execution and honoring the response. TMOM does not directly cancel or block an order at the broker.
Is the Python Client the same as the API? expand_more
The Python Client is the official Python wrapper around TMOM’s REST API. It provides typed models, authentication, validation, retries and structured errors. Developers may call the REST API directly instead.
Does the Python Client contain TMOM’s production policy engine? expand_more
No. Production policy evaluation occurs on TMOM-managed infrastructure. The Python Client only sends authenticated requests and returns structured decisions.
Can the Quintus toolkit be used to bypass Fabius? expand_more
No. Quintus supports contract development, validation, linting, mocks and paper workflows. It does not contain the production policy engine, persistent decision state or hosted enforcement capabilities.
Who should use the Python Client? expand_more
Python algorithmic traders, quantitative developers and Python execution services should generally use the Python Client.
Who should use Hosted MCP? expand_more
MCP-compatible AI trading agents should generally use the Hosted MCP endpoint.
Are MCP, Python and REST separate policy engines? expand_more
No. They are separate interfaces to the same hosted TMOM policy service.
Why would a customer pay for Fabius or Maximus? expand_more
Customers pay for authenticated production evaluation, deterministic policy versions, persistent state, decision history, metering, monitoring, replay and multi-agent coordination rather than for a downloadable rules library.