What integration contract should be agreed before a pilot is connected?

Ask for a release manifest containing `release_id`, `schema_version`, `task_bundle_version`, file checksums and declared dependencies. Agree which fields are required, how null values are represented and how schema changes are communicated. Unknown optional fields should not silently alter task semantics.

For a simulated environment, define a reset action that restores the selected starting snapshot and returns a fresh `run_id`. Reset should clear agent-created attachments, notes and pending actions while preserving the versioned source bundle. Test that two runs cannot read each other’s working state.

For downloadable delivery, specify an archive layout separating agent inputs, schemas and evaluator-only assets. For an MCP interface, agree tool names, argument schemas, error responses and session boundaries. Choose the interface that matches the pilot’s needs rather than requiring every delivery form at once.

Also define how upgrades affect existing results. A changed policy, corrected record or revised answer key should produce an identifiable version change. The first integration exercise can load the manifest, start a run, submit a package and reset it. That verifies the operational contract before substantive benchmark results are collected.