In a multi-agent pipeline, a worker agent returns a tool result claiming it successfully executed a database schema migration. Before the supervisor proceeds to deploy the application code that depends on this schema change, what is the correct validation approach?
Select an answer to reveal the explanation.
Short Explanation
Here's the deal — you should have the supervisor issue a follow-up verification tool call before proceeding. In critical multi-agent pipelines, an agent's reported outcome should be independently verified before dependent steps. Tool execution can succeed partially, report success despite side effects, or return stale cached data.
Full Explanation
The correct approach is to have the supervisor issue a follow-up verification tool call, such as querying the schema to confirm the new table or column exists, before proceeding, treating the worker's success claim as unverified until independently confirmed. In critical multi-agent pipelines, an agent's reported outcome should be independently verified before proceeding to dependent steps. Tool execution can succeed partially, report success despite side effects, or return stale cached data. Having the supervisor issue an independent verification query converts an unverified claim into a verified state. For irreversible downstream actions like deployment, this validation gate is architecturally essential. The trust-the-worker approach is wrong because agent-to-agent communication is not inherently reliable — worker agents can misinterpret tool results, tools can return false positives, and errors in complex pipelines are common. Blind trust violates defense-in-depth principles. The three-independent-worker voting approach is wrong because running three independent migrations and voting creates database conflicts and race conditions — it is appropriate for read operations, not destructive write operations like schema migrations. The log-and-proceed-with-rollback approach is wrong because relying on rollback as the primary validation strategy is reactive rather than preventive; failed deployments on top of a bad schema can cause cascading data corruption that rollback cannot fully reverse.