Your data agent’s release manifest needs five moving parts—not just a model version

Enterprise data agents are increasingly packaged as applications, but their behavior is assembled from components that can change independently. Four first-party systems expose the same operational lesson from different directions: a model name or application commit is not enough to identify what actually ran.

The five-part manifest

A defensible release record should pin model, prompt/orchestration, data or semantic assets, tool set, and execution identity/destination.

AWS provides the clearest failure example. Its Field Sales agent combines specialized agents, including a Data Insights Agent that generates SQL. AWS says a mismatch among a data change, tool change and paired prompt update cut a pre-production pass rate from 78% to 38%, even though the system still responded. Its framework evaluates tools, individual agents and the multi-agent system separately, and continues semantic canaries after release because upstream data refreshes can change behavior without an application deployment. AWS’s production account makes data, tools and prompts part of the release unit.

Snowflake shows why the tool graph belongs there too. The company says Cortex Analyst semantic views and verified queries carry into Cortex Agents unchanged, while the surrounding system gains planning and access to other tools. It also documents that a run may continue with only the tools the caller can access. The semantic asset can therefore stay fixed while routing and available capabilities change. (transition notice; Cortex Agents docs)

Identity and destination are versioned inputs

Oracle’s shared Select AI teams separate permission to invoke a workflow from the database privileges used during execution. Oracle says the package runs with the caller’s privileges, and a team-access grant does not grant credentials, object access or permission to owner-defined tool functions. The same stored team can therefore produce different capability sets—or fail—under different consumer roles. (Oracle sharing guide; prerequisites)

Google Cloud adds a destination boundary. Data Agent Kit lets operators configure the Scheduler project and region separately from the extension’s Common project and region, and choose a Managed Service for Apache Airflow environment. Its Notebook MCP code-execution tool is also controlled by a separate opt-in IDE setting. (configuration guide) A release record that names only the project visible in the IDE can therefore omit where scheduled work is sent and whether generated cells may execute.

The practical gate

For every promoted agent version, store one manifest containing the model identifier; prompt and orchestration revision; semantic-view, schema or retrieval snapshot; enabled tools and their versions; caller role or service identity; and runtime project, region and scheduler target. Replay the same acceptance set whenever any one field changes.

This does not make every answer reproducible: live data and external services still move. It does make regressions diagnosable. Without the manifest, “the agent version did not change” is not evidence that the system stayed the same.