AI trading agents do not need a frontier model for every decision. They need a layered system: a large model for research and planning, a fast decision model for bounded judgments, code for hard limits, and a protocol that can execute only the actions the agent is authorized to take.

Jev, TypeSafe's first System One model, makes that middle layer easier to picture. It is not a trading signal, a price predictor, or a strategy. It is a model built to answer constrained questions in a form that software can use.

The missing layer in AI trading agents

Most discussions about trading agents jump from intelligence to execution: give the agent a capable model, then connect it to a protocol. That skips the smaller judgments between a strategy and a signed order.

Does the observed state still match the setup? Which permitted action fits it? Should the case continue or go back to a larger model or a person? A frontier model can answer, but using one for each decision may add latency and make the loop harder to specify; the tradeoff needs testing in the intended workflow. Ordinary code cannot interpret every semantic condition. A bounded decision model sits between them.

What Jev does, and what it does not do

TypeSafe describes Jev as a System One model: an application provides state, asks a typed question, and receives a judgment with probabilities. Its primitives cover three common shapes. Choice selects from a defined set, Score places something on an ordered scale, and Noul estimates whether a condition holds.

That interface encourages a useful design rule: code builds the action space; the model judges among the candidates.

For a trading agent, code might produce four allowed next actions: hold, open small, reduce, or escalate. Jev could judge which action best matches the strategy and the current state. If the answer is uncertain, or if the action carries more consequence than the decision layer is allowed to handle, the system can escalate instead of trading.

The typed response solves an interface problem. It does not prove the judgment is correct. A model can return a valid option and still choose the wrong one. Probabilities help the surrounding system decide what to review, but they are not permission to bypass risk controls.

A four-layer trading-agent stack

A cleaner agent architecture gives each part one job.

Layer Responsibility
Large model Research, form a strategy, revise plans, and handle novel cases
Jev-like decision layer Make bounded semantic judgments over current state and predefined candidates
Deterministic code Calculate size and margin, apply thresholds, enforce limits, and validate fresh data
LeverUp execution path Accept an authorized intent and apply protocol execution, settlement, and risk rules

Suppose the large model writes a plan: consider a small long only while current observations fit a defined trend setup and no exception requires review. That plan should not become an open-ended prompt controlling a wallet.

The application retrieves fresh market and account state, then constructs permitted actions. The decision layer judges whether the evidence still fits the plan. Code checks the proposed action against position size, margin, loss limits, allowed markets, and key permissions. Only then does the system form a trading intent.

The large model plans. Jev makes bounded judgments. Code enforces the rules. LeverUp executes the authorized intent.

This is an architectural proposal, not a deployed TypeSafe-LeverUp integration. The point is to separate responsibilities before an agent is trusted with execution.

Decisions for models, rules for code

The boundary matters more than the model choice.

A decision model helps when a question requires semantic interpretation but has a constrained answer. It can judge whether research supports the active thesis, whether an action matches a written strategy, or whether an unusual state deserves escalation. These are awkward if statements, but they do not need a new essay from a large model.

Financial constraints belong elsewhere. Position sizing is arithmetic. Margin checks depend on current account and protocol state. Exposure, allowed markets, signing permissions, and stop conditions should be explicit and enforceable. Price and balance data should come from their source, not model memory. A prompt saying "never exceed this limit" is not code rejecting the action.

Confidence does not change that boundary. Low-certainty judgments can go to a larger model, while high-consequence actions may require human review. Those thresholds need testing on the real workflow, not copying from a demo.

Where LeverUp fits

LeverUp could provide the execution side of this stack. Its 1CT Hosted Agent flow allows a separately authorized key to submit supported trading intents with configurable action permissions. The key is designed for trading actions rather than general token transfers, and the owner can revoke its authorization onchain. The practical setup is covered in How to Build a Grok Bot Trading Agent on LeverUp.

That permission boundary complements deterministic checks in the application. Even if a model proposes an invalid action, the agent key should not gain capabilities outside its authorization. Scoped permissions and strategy-level limits solve different problems; an agent-ready system needs both.

Execution then moves to the protocol layer. LeverUp uses a protocol-managed virtual liquidity system powered by the VMMV, where trades reference oracle pricing while execution, settlement, and risk management are handled at the protocol layer.

This does not make model judgment safe by itself. It gives the final layer a defined execution environment once the research, decision, and code checks have produced an authorized intent.

What has not been tested

No LeverUp-specific Jev workflow has been tested here. The architecture has no measured accuracy, latency, or cost result in this setting.

Before using a decision model in a trading loop, a team would need representative cases, labeled outcomes, failure analysis, and conservative escalation rules. Testing should distinguish missing evidence from a bad model judgment, stale state, broken composition logic, or a failed service call. High-confidence output can still be wrong. Low-confidence output may simply mean the candidates are close.

Jev should not replace a trading model, and it should not become an informal risk engine. Its more useful role is narrower: reduce how often the system needs open-ended reasoning, while leaving calculations, permissions, and enforceable limits where they belong.

That is a less dramatic pitch than "an AI that trades for you." It is also a much more plausible way to build one.

Related reading

Trade on LeverUp: app.leverup.xyz