Agents

TRUE doesn’t run on a single model responding to questions. It runs on a coordinated system of specialized AI agents — each purpose-built for a narrow domain, each calling only the tools it is authorized to use, each operating within strict latency and safety budgets. The result is answers that are grounded in live data, traceable to specific sources, and consistently safe to act on.

What it is

DARS — the Dynamic Agent Response System — is the orchestration layer that sits between every user message and the response they see. When a message arrives, DARS doesn’t immediately send it to a language model. It first classifies the request, estimates the reasoning depth required, selects the right combination of specialist agents, runs their tool calls in parallel where possible, and then synthesizes a single grounded answer with citations. Every frame the user sees in the chat — reasoning chunks, tool-use indicators, the final streaming answer — is produced by this pipeline.

Disclaimer. TRUE provides information, analysis, and tooling. Nothing on this platform constitutes financial advice, investment advice, or a recommendation to buy or sell any asset. Users remain solely responsible for their own decisions and outcomes.

Who it’s for

• Users who want to understand why TRUE’s answers are more grounded than a general-purpose chatbot’s — and what to do when they disagree with an answer.
• Partners embedding TRUE’s chat surface who need to understand the compliance framing around agent outputs.
• Developers building on the TRUE API who want to consume agent frames programmatically and display reasoning traces in their own interfaces.

How it works

The DARS pipeline

Every user message enters a five-stage pipeline before a response is composed.

Specialist agents

The TRUE agent registry runs six core specialists. Each agent is stateless — it receives a scoped context for the current turn, executes its tool calls, and returns a structured result. No agent holds memory between turns; context continuity lives in the orchestrator.

Model escalation

Most chat turns are handled by Claude Haiku 4.5, chosen for its latency profile at scale. When the orchestrator’s complexity score crosses a configured threshold — long-context reasoning, multi-tool synthesis, ambiguous multi-asset queries — it escalates to a Sonnet-class model. Escalation decisions are logged with reason codes; users can see which model answered in the response trace view. Repeated escalations within the same conversation trigger a circuit-breaker that stabilizes the model for the rest of the session, preventing runaway latency.

How tool-use is gated

Every tool call is gated by three controls before it reaches the network:

1. Agent allow-list. Each specialist has an explicit list of tools it may call. A news agent cannot call a swap-routing tool, regardless of what the user asked.
2. Argument validation. Tool arguments are validated against a schema before execution. Malformed or out-of-range arguments are rejected before any network call is made.
3. Per-turn budget. A single turn has a maximum number of tool calls it can make across all agents. This prevents a complex query from consuming the entire rate-limit bucket in one shot.

Trace IDs propagate from the turn through every tool call, so any misbehaving call is traceable back to the exact user message that triggered it.

The rules it enforces

• No auto-execution. Agent outputs are never automatically executed. Every path that touches funds — swaps, stakes, agentic strategies — requires an explicit user action after the agent has spoken.
• Tool scope per agent. Agents cannot call tools outside their allow-list. Cross-agent contamination is architecturally prevented, not just policy-restricted.
• Partial answers over silent failure. If a specialist agent exceeds its latency budget or an upstream tool is unavailable, the orchestrator composes the best available answer from the remaining agents and clearly marks the missing piece. The user is never shown a confident answer that is secretly incomplete.
• Off-policy output filtering. Any agent output that resembles an unsolicited execution instruction is filtered by the orchestrator before it reaches the user.
• Confidence surfacing. When the agent system is working with sparse or uncertain data — a long-tail token with no oracle pricing, a newly listed asset — the response is marked with a confidence qualifier. High confidence is reserved for answers grounded in multiple corroborating data sources.

Safety, security & trust

Traceability. Every turn emits a trace that records which agents were selected, which tools they called, which data sources returned results, and which model produced the final synthesis. Traces are retained and can be reviewed if an answer needs to be audited.

Hallucination containment. The orchestrator is designed to prefer “I don’t have reliable data for this” over a confidently wrong answer. When tool calls return no usable data, the system surfaces that clearly rather than filling the gap with model-generated content that cannot be attributed to a source.

Rate limiting per agent. Specialist agents have independent rate limits. A surge in memecoin queries does not crowd out price lookups or news queries.

Abuse detection. Patterns consistent with prompt injection — messages designed to override agent behavior or extract system prompts — are detected and refused. Suspicious patterns are logged for review.

Data privacy. Agent context includes user watchlist and preferences to personalize answers, but this data never leaves the TRUE infrastructure. It is not sent to third-party models; it is injected into the orchestrator context that runs inside TRUE’s own environment.

Why it’s well thought through

Narrow agents are safer agents. A specialist that can only call three tools and has a hard latency budget is far less dangerous than a generalist that can call anything. Narrowness limits the blast radius of a misbehaving agent and makes the system’s behavior predictable.

Symmetry with the MCP surface. The tools agents call internally are the same tools exposed through the MCP server. This means external clients get the same data quality as the internal agents, and any regression in tool quality is immediately visible in the product’s own answers.

Escalation is auditable. The decision to use a heavier model is logged with a reason code, not made silently. This means model cost is observable, escalation patterns are analyzable, and the system can be tuned over time based on real data rather than guesswork.

Citations as a first-class output. Every response includes a done frame with citations to the data sources that informed it. This makes the answer verifiable — users can follow a citation to the underlying data and form their own judgment.

for await (const frame of parseSSE(res.body)) {
  switch (frame.event) {
    case 'reasoning':   render.reasoning(frame.data); break;
    case 'tool_call':   trace.push({ tool: frame.data.name }); break;
    case 'tool_result': trace.push({ preview: frame.data.preview }); break;
    case 'token':       render.token(frame.data); break;
    case 'done':        render.citations(frame.data.citations); break;
  }
}

Common questions

Why does TRUE use multiple agents instead of one powerful model? Narrow agents with defined tool access are more predictable, cheaper to run, and safer to audit than a single generalist with unbounded tool access. Routing the right question to the right specialist also produces better answers — a model focused on on-chain security analysis is more reliable for that task than a general-purpose model that happens to know about it.

Which model actually answers my question? Claude Haiku 4.5 handles the majority of turns. Escalation to a Sonnet-class model happens when the orchestrator scores the request as high-complexity. The response trace shows which model produced the final synthesis.

Can I see which tools were called for my answer? Yes. The reasoning frames visible in chat show tool-use events as they happen. Developers consuming the SSE stream receive discrete tool_call and tool_result frames for programmatic use.

What happens if an agent fails mid-turn? The orchestrator composes the best available answer from the agents that succeeded and marks the missing piece explicitly. You will never receive a silently incomplete answer presented as complete.

Can an agent place a trade on my behalf without me approving it? No. Agent outputs are advisory. Any execution action requires an explicit confirmation step and, where funds are involved, a wallet signature from the user.

How does the system handle questions outside its knowledge? If no agent has reliable data for the query, the system says so clearly rather than synthesizing a plausible-sounding answer it cannot attribute to a source.

What does “confidence flag” mean on a response? It indicates the answer is grounded in sparse or uncertain data — a newly listed asset, a long-tail token with no oracle pricing. Use these responses as a starting point for your own research, not as a definitive data point.

How do I report a bad answer? Use the Report an issue button on any response. Include the turn if you can reproduce it. The report links to the server-side trace for that turn and feeds the agent quality pipeline.

Does the agent system store my questions? Chat turns are logged for quality review, personalization, and abuse prevention. The privacy controls for your conversation history are in Settings → Privacy. See Compliance & Jurisdictions for retention schedules.

Can I use the agent system via the API without the chat UI? Yes. The Chat API exposes the full DARS pipeline over HTTP with SSE streaming. The MCP server exposes individual tools for direct access without the full pipeline.

Related features

• Chat — the streaming runtime that renders DARS frames into the user-visible interface.
• MCP — the tool surface DARS uses internally, exposed externally for direct access.
• Signals — AI-generated trade ideas produced by the signal specialist agent.
• Agentic Trading — the opt-in execution layer that acts on agent outputs.