Framework: mastra (2026-03)
Issue: OM issues in tool heavy environments
Mechanism cluster: M-delegation-fanout
Notes: paper:bu; EXPANDED in v22-batch-30 with deeper architectural-detail analysis per codebook section 10 evidence-deepening policy. Closed Mar 28 2026 by Member @roaminro as completed (5 days filing-to-close) with NO PR LINKED + NO FIX-COMMIT REFERENCED -- closed-without-visible-fix sub-pattern (parallels closed-by-promise-without-PR-link from LLMI-006/DSPY-003). Filed Mar 23 2026 by Member @daneatmastra (Discord-sync from post 1485626452807385108 by @murilo.zaz). Tagged Memory + Tools + bug + impact:medium + effort:high + discord + trio-tb. GOLD-STANDARD ARCHITECTURAL-DETAIL EVIDENCE: Reporter @murilo.zaz (via Discord-sync) quotable architectural-mistake quote: "OM processInputStep counts tokens from the current turn tool results, which are ephemeral -- they are not persisted to DB, they are only used for the current generation step. But OM treats them as new unobserved messages that inflate the token count toward the observation threshold." CONCRETE QUANTIFIED IMPACT PAPER-QUOTABLE (largest single-call amplification in catalog, surpassing LANG-035 254K input): "With default thresholds (messageTokens=30k): Observation threshold crossed in ~4 seconds, blocking the thread for up to 148 seconds while the observer LLM processes the entire conversation. With raised thresholds (messageTokens=200k): Blocking is rarer but when it does trigger, it processes enormous context (up to 2M tokens at blockAfter=10), taking 10-40+ seconds." 2 MILLION TOKENS IN SINGLE OBSERVER LLM CALL. PROCESS DESCRIPTION FROM CHUNK-SUU4IAZJ.js: handleThresholdReached function: totalPendingTokens >= messageTokens (threshold)? -> handleThresholdReached() -> await async buffer op (30s timeout) -> tryActivateBufferedObservations() -> SUCCESS: instant activation OR FAIL: check blockAfter -> tokens >= blockAfter*messageTokens -> SYNC observation (blocks). Reporter exhausted 5 DISTINCT WORKAROUND APPROACHES each documented with failure mode (most exhaustive workaround-documentation in catalog): (1) Raise thresholds to 200k blockAfter=10 -- "Avoids blocking but OM rarely runs, defeating its purpose. When it does run, it is very slow"; (2) Lower thresholds to match Mastra Code (30k) -- "Triggers too often due to tool results inflating token count"; (3) Make OM only process DB-persisted messages -- "This is the desired approach but requires changes to OM internals"; (4) Custom input processor to strip tool results before OM -- "Would work but diverges from native OM behavior"; (5) OM sanitization features (sanitizeToolResultValue, maxToolResultTokens=10k) -- "OM already has some built-in sanitization but it is insufficient -- it caps individual tool results at 10k but does not exclude them from token counting toward the threshold." NEW PATTERN: 5-distinct-workarounds-each-documented-with-failure-mode-pattern. Reporter explicit framework-architectural-mistake: "Tool results are used for the current generation step only -- they should not count toward OM thresholds. System prompt is computed dynamically each turn -- should not be observed. OM should run 100% in background, processing the conversation as it exists in storage." Cross-references Mastra Code (Anthropic deployment): "Mastra Code uses messageTokens=30k, bufferTokens=0.2, blockAfter=2 -- same ratios but works because Mastra Code tool results are smaller (terminal output, short file reads). In a builder agent reading entire files and skills, each tool result is 10-30k tokens." Tool result size scaling: 10-30k tokens each x toolCallConcurrency: 10 = 30-150k tokens of tool results per single agent step. NEW SUB-MECHANISM within M-context-amplification: observability-system-itself-amplifies-cost-during-tool-heavy-runs. THIRD ARCHITECTURAL LEVEL for M-context-amplification cluster: (1) compile-time (DSPY-001 + DSPY-003 MIPROv2); (2) runtime agent-step-loop (SMAG-002, SMAG-006, MAST-004); (3) NEW runtime observability-layer (MAST-014). Strongest single architectural-detail row in catalog. ORIGINAL TRIAGE NOTES PRESERVED: was previously classified as M-delegation-fanout cross-cluster fit; v22-batch-30 reclassifies primary cluster to M-context-amplification observability-layer level with M-delegation-fanout cross-cluster note retained.