Your agent builds.
You decide the behavior.

Describe the customer feature.

Ask your coding agent to add the feature, write an end-to-end test and check it with Filibuster. You supply the product goal; you do not need to name the service that might fail or prescribe a retry strategy.

The agent implements the feature and writes a test with meaningful assertions. The test owns its requests, setup and checks. Filibuster executes the test file across different fault scenarios.

Connect the test and observations.

• A runnable end-to-end test. The agent adapts it to the supported test adapter. The demonstrated adapter is a Node test file using the Filibuster SDK protocol; arbitrary test frameworks do not work without an adapter.
• Supported dependency instrumentation. After SDK setup, supported HTTP, gRPC or SMTP calls can be intercepted automatically. The agent still needs to configure service identity and context propagation for the relevant adapter. Availability differs by language and protocol.
• Repeatable state and independent observations. Each execution needs isolated or resettable state. To check a charge or booking, the test must observe that state. Tracing a call does not automatically prove its business side effect committed.
• An explicit search bound. Choose the fault kinds and maximum faults per execution. A completed search is a result within that scope, not every possible behavior.

The healthy test runs first and becomes the observed reference. No initial approval of a golden path is required. The diagram lets you inspect what ran; Filibuster does not establish that an AI-written test fully captures your feature.

The agent brings the evidence to the conversation.

In the recorded Claude desktop workflow, Filibuster’s result is shown in the browser pane beside Claude’s question. You inspect that view and answer in the conversation; Claude handles the commands and files. See the actual workspace ↗

The agent runs the same test under internal dependency failures. Compare the healthy and faulted paths: locate the injected fault, missing calls, added recovery calls, changed replies and independently observed effects.

A changed trace is not automatically a bug. It may match an approved failure policy. Conversely, assertions can pass because the agent guessed a permissive policy you never approved. An unresolved behavior needs clarification even when the current assertions pass.

The agent explains the specific outcome and recommends choices grounded in the implementation. It should reuse applicable approved rules; materially different outcomes still require a decision.

Say what should happen.

The agent should explain whether it is changing the app, the test or both. A missing-notification exception must not silently remove money or booking checks. Permission for either of two omissions separately does not automatically approve both at once.

Replay what you already learned.

After a change, replay the original failure and all retained cases, then continue exploring within the bound. Assertion controls check that known invalid outcomes are rejected; they reduce the risk of a vacuous test but do not prove the assertions are complete. Run the application’s ordinary test suite before closing, to check existing behavior outside the retained fault cases.

The closing summary compares the original request with the refined requirements. It names assumptions the agent made, the user’s decisions, resulting implementation or test changes, verification results and remaining gaps. A locally passing repair may still have design limitations; use them to choose the next experiment.