How Faultmap works

The check that runs before the build, not after.

Point Faultmap at the goal and your data. It returns the map of where your agent will break and the first test suite it has to pass. There is nothing to instrument, nothing to deploy, and no code to write to get the first map.

Run a free Faultmap See use cases
faultmap · support-agent.mapread-only

Goal

Resolve customer support tickets end to end

  • 01

    Read CRM record

    Read-only, scoped fields

    Mapped safe
  • 02

    Call refund API

    Retry loop, no timeout cap

    Likely break
  • 03

    Update ticket record

    Schema drift on write

    Structural risk
  • 04

    Hold multi-turn state

    Deadlock past 8 turns

    Likely break
  • 05

    Pass context to model

    PII leakage vector

    Structural risk

First test suite · generated

  • ›Refund API: enforce timeout and cap retries at 3
  • ›Record write: assert schema contract before commit
  • ›Long session: guard against deadlock past 8 turns
  • ›Prompt: redact PII before the model call
01

Goal, personas, data, tools

What it must do, who it serves, the data it reads, the tools it calls. No prompts, no traces.

02

Failure map

We map every step and mark where it breaks, in the design phase, before any code.

03

Test suite

The first tests it has to pass, generated from the failures we found.

Why this is possible

We map the paths your agent will travel.

Your agent does not wander at random. Its goal, its user personas, the data it reads, and the tools it calls fix the paths it can take. We lay every path out and mark where it breaks, before the agent exists. The failure classes repeat across domains, so a pattern mapped once is recognizable in yours.

Goalwhat it must doUser personaswho it servesData sourceswhat it readsTools & APIswhat it callsPattern mappaths enumeratedRead CRM recordCall refund APIUpdate ticket recordHold multi-turn stateRedact PII for model
Mapped safeStructural riskLikely break

The failure classes we map for, again and again

Retry loop

No timeout, no cap. The agent calls until something gives.

Schema drift

The write target moved. The agent does not know yet.

State deadlock

Multi-turn memory locks past a turn threshold.

PII leakage

Private data reaches the model prompt unredacted.

What you get

A map, a test suite, and one link to share.

The failure map

Every step the agent takes, marked mapped safe, structural risk, or likely break, with the reason for each.

The first test suite

Concrete tests generated from the failures we found. The bar your agent has to clear before it ships.

A shareable artifact

One link your team, your client, or your reviewer can read in thirty seconds. A mark of craft, not a private report.

What you do with it

Map it. Fix it. Or have it built to pass.

Faultmap outputsupport-agent
  • 01Read CRM recordMapped safe
  • 02Call refund APILikely break
  • 03Update ticket recordStructural risk
  • 04Hold multi-turn stateLikely break
  • 05Pass context to modelStructural risk
Where it sits

One step in front of your stack.

Design phase
OptimalARCFaultmap

Before the agent exists. The only step where you can move a break point for cents instead of a sprint.

you build here
After the build

Prompts, evals, traces, production. The whole stack you already use starts here, once the agent runs.

LangSmithGalileoPatronusBraintrustArizeLangfuseHeliconeDatadog

OptimalARC does not replace your stack. It owns the one step in front of it.

See Faultmap vs each tool →

See where your agent breaks.

Run a free Faultmap on your goal and your data. No card, no code.

Faultmap your agent, free