What causes "[Agent:${this.name}] - Input step processor error" in mastra-ai/mastra?

Inspect `details.processorId` to identify the failing step processor and fix its implementation

mastra-ai/mastra · error · MastraError

AGENT_INPUT_STEP_PROCESSOR_ERROR

AGENT_INPUT_STEP_PROCESSOR_ERROR

Error message

[Agent:${this.name}] - Input step processor error

What it means

A MastraError (id AGENT_INPUT_STEP_PROCESSOR_ERROR, category USER) thrown when an input *step* processor fails while processing the agent's input step (workflow-style input processing). Like the plain input-processor error, it wraps the underlying processor error with the agent name, processorId, and retry metadata.

Source

Thrown at packages/core/src/agent/agent.ts:4443

          nextTools = convertedTools;
        }
      } catch (error) {
        if (error instanceof TripWire) {
          tripwire = {
            reason: error.message,
            retry: error.options?.retry,
            metadata: error.options?.metadata,
            processorId: error.processorId,
          };
          this.logger.warn('Input step processor tripwire triggered', {
            agent: this.name,
            reason: error.message,
            processorId: error.processorId,
            retry: error.options?.retry,
          });
        } else {
          throw new MastraError(
            {
              id: 'AGENT_INPUT_STEP_PROCESSOR_ERROR',
              domain: ErrorDomain.AGENT,
              category: ErrorCategory.USER,
              text: `[Agent:${this.name}] - Input step processor error`,
            },
            error,
          );
        }
      }
    }

    return {
      messageList,
      tools: nextTools,
      tripwire,
    };
  }

View on GitHub (pinned to 75dd419e61)

Solutions

Inspect `details.processorId` to identify the failing step processor and fix its implementation
Make the step tolerate missing/empty prior-step output (validate before operating)
Configure retry options on the processor if the failure is transient (network flake)
Temporarily remove the step processor to confirm it is the source, then reinstate with guards

Example fix

// before
const step = { process: async ({ data }) => enrich(await db.find(data.id)) };
// after
const step = { process: async ({ data }) => {
  if (!data?.id) return { data };
  const rec = await db.find(data.id);
  return rec ? { data: enrich(rec) } : { data };
} };

Defensive patterns

Strategy: try-catch

Type guard

function isInputStepProcessorError(e) {
  return e instanceof Error && 'id' in e && e.id === 'AGENT_INPUT_STEP_PROCESSOR_ERROR';
}

Try / catch

try {
  await agent.stream(prompt, opts);
} catch (e) {
  if (e?.id === 'AGENT_INPUT_STEP_PROCESSOR_ERROR') {
    logger.error(`step ${e.details.processorId} failed: ${e.details.reason}`, { retry: e.details.retry });
    return degradedResponse();
  }
  throw e;
}

Prevention

Validate prior-step output shape at the start of each step processor
Configure retry options for transient failures in step processors
Make every step return a well-defined no-op result when inputs are missing
Integration-test the full processor chain, not each step in isolation

When it happens

Trigger: Calling `agent.generate()`/`stream()` with multi-step input processors configured, where one step processor throws instead of returning a result; non-recoverable failure after any configured retry was exhausted.

Common situations: Step processors performing DB lookups, auth checks, or enrichment that fail at runtime; steps that assume prior step output exists but it was filtered out; version drift where a step returns an unexpected shape and downstream code throws.

Related errors

AI-assisted analysis of mastra-ai/mastra@75dd419e61 (2026-08-30). Data as JSON: /api/errors/c23477a16b2f818a. Report an issue: GitHub.