What integration details should we settle before loading a pilot into our agent harness?

Begin with an adapter contract between your agent harness and the generated environment. Map your internal identifiers to supplied fields such as `entry_id`, `adjustment_id` and `account_id`. Specify whether amounts use decimal strings or integer minor units, and whether timestamps include offsets. Ambiguous conversions can change the task before the agent sees it.

Map each business action to the tool your agent will call. Record whether an update replaces a whole object or patches selected fields, how pagination works and which errors are retryable. If the environment uses different names from your production tools, make that translation visible in the adapter specification.

Ask MirrorFirm for a versioned schema and a small compatibility fixture containing representative field values and documented error responses. The fixture can verify loading and tool mapping without revealing evaluation answers. Keep its purpose separate from the business task score.

Before running the pilot, record the adapter version, environment version and configuration used. Define how an incompatible schema change will be detected rather than silently accepted. This gives developers a repeatable starting point and makes it possible to attribute a failed run to an integration mismatch or to the agent's decisions.