Skip to main content
Your coding agent connects a real entry point to a recipe. The recipe describes scenarios, configuration variations, repetitions, and any synthetic Tools needed around the application.

​
The execution flow

  1. Choose scope. Authorize Firedrill and select the project and environment.
  2. Describe the simulation. Put task input and optional checks, rubric, or multi-step sequence into scenarios.
  3. Prepare surroundings. Pin synthetic Tool definitions and datasets if needed. Tool-free agents need none.
  4. Run the agent. Your CLI, SDK, or CI runner invokes the application. Independent runs receive separate synthetic state.
  5. Retain evidence. Firedrill saves inputs, outputs, activity, measurements, and files actually submitted.
  6. Inspect or compare. Read the report, compare configurations, repeat trials, or reuse the recipe in CI.
A remote operator MCP can prepare and inspect work. It cannot execute a process on your laptop by itself. The customer-owned runner must attach to admitted work.

​
Use the right kind of assessment

Simulations do not require a pass/fail verdict. Observation-only runs are useful for exploration, demonstrations, and understanding behavior. When assessment matters, exact checks protect hard requirements. Rubrics score meaning or behavior on authored anchors and allow different correct wording. Missing evidence is not zero. Execution, assessment, and CI policy remain distinct.

​
Data stays aligned

The CLI, SDKs, MCP, and web app read the same project/environment-scoped records. Saving or running from your repository does not make the report local-only. A synthetic Tool’s API, MCP interface, and available browser application operate on that instance’s data. An authored starter dataset is synthetic input—not a customer result. See first run, Tools, and reports.