Skip to main content

Documentation Index

Fetch the complete documentation index at: https://reasonblocks.mintlify.app/llms.txt

Use this file to discover all available pages before exploring further.

E-traces are the steering mechanism ReasonBlocks uses to guide your agent away from failure modes. When the health monitors detect trouble — or when the agent is on its first call — ReasonBlocks retrieves relevant guidance from the ReasonBlocks API and appends it to the system message. The agent reads that guidance as part of its context and adjusts its behavior without any change to the conversation history. There are three tiers, each operating at a different scope and with different retrieval logic. Understanding which tier fires when helps you reason about what guidance your agent is receiving at any given step.

​
The three tiers

E1 patterns are customer-scoped, retrieved by semantic similarity, and gated behind the health monitors.E1 retrieves the single most similar pattern (top_k=1) from your organization’s pattern library. The similarity threshold enforced by the API is 0.8 — only a very close match triggers an injection. Because E1 queries involve a vector search, it is only invoked when the session shows signs of trouble.E1 fires when any of the following is true:
  • At least one monitor has fired on the current step (score ≥ 0.6).
  • The composite monitor score on the current step exceeds 0.15.
  • At least one monitor fired on either of the two previous steps in the session.
If no monitors have ever been configured, E1 is allowed to fire unconditionally, preserving backward compatibility.E1 never fires more than once per run by default (max_calls=1). This prevents repeated injection of the same instance-level guidance once it has been delivered.
E1 is completely skipped — no query is issued — when the FSM is in FAST state. When the agent is sailing through easy steps, instance-level guidance would add latency without benefit.

​
How injections reach the system message

All retrieved patterns are assembled and appended to the system message as a single block: 
[REASONBLOCKS]
<rendered guidance text>
This block is a separate content block from your base system prompt, which means it can be cached independently. ReasonBlocks marks the base system prompt with an Anthropic cache_control: ephemeral marker so it hits the prompt cache on every step. The [REASONBLOCKS] block rides uncached — its content varies per step, so it must never bust the base prompt’s cache key.
The cache_control marker is a no-op on non-Anthropic providers. It is safe to use ReasonBlocks with OpenAI or Gemini models; the marker is simply ignored.
On steps where no injections are warranted (for example, a FAST-state step), the [REASONBLOCKS] block is omitted entirely. The base system prompt is still wrapped with cache_control unconditionally so every step benefits from cache hits.

​
The E1 gate in detail

The E1 gate exists to avoid issuing vector search queries on every step of a healthy run. Pattern retrieval adds latency, and most steps in a well-functioning agent do not need instance-level steering. The gate uses a lookback window of two prior steps in addition to the current step’s signal: 
allow E1 if:
  current_eval.fired is non-empty
  OR current_eval.composite > 0.15
  OR any monitor fired on the previous 2 steps
This means a single monitor firing opens the E1 gate for the next two steps, ensuring continuity of guidance even if the monitor score dips briefly.
If you disable monitors entirely, E1 falls back to firing unconditionally on every eligible step. Consider this tradeoff when deciding whether to include monitors in your configuration.

​
Summary

TierScopeRetrievalTop-kSimilarity gateFires when
E1InstanceVector search10.8Monitor fired or composite score > 0.15
E2Pattern sharedVector search20.7 (API-side)Any scored step (not FAST)
E3UniversalScroll-all32NoneFirst call only