A database maintenance agent is currently configured to autonomously run VACUUM, ANALYZE, and REINDEX operations on a PostgreSQL cluster. An operator wants to expand its capabilities to include write operations — specifically UPDATE and DELETE statements for data cleanup tasks. Which change must accompany granting write access to the agent?

The autonomy level of an agent must be calibrated to the reversibility and blast radius of its actions. VACUUM and REINDEX are essentially idempotent — running them incorrectly might cause performance degradation but won't corrupt or lose data. UPDATE and DELETE are irreversible mutations that can permanently destroy production data. These categories require different governance controls.

The correct change is to add a human-in-the-loop approval gate specifically for write operations before execution; read-only maintenance operations may remain autonomous, but irreversible writes require human confirmation. The human-in-the-loop pattern is the correct architectural response to expanding an agent into irreversible write operations. The existing autonomous read-only maintenance operations can remain unchanged — they have an established safety record. Write operations, being irreversible, must route through a human approval gate that surfaces the exact SQL to be executed (rows affected estimate, filter conditions, table name) before any execution occurs. This preserves the value of automation (the agent plans and drafts the operation) while keeping a human in the accountability chain for destructive actions. This is also the least-privilege complement: the agent is given write capability in the database role, but workflow-level governance gates its exercise.

Increasing the agent's context window size to ensure it can hold the full schema and row count data needed for safe write operations is wrong because context window size affects how much information the agent can process in a single inference, not the safety of the operations it executes. An agent with a large context window can still execute a DELETE WHERE 1=1 just as easily as one with a small context. Context capacity is an operational concern, not a governance control.

Adding comprehensive unit and integration tests for the new write operation logic before enabling the capability in production is wrong because testing is essential engineering practice and should absolutely be done, but tests validate that the agent does what it is programmed to do — they do not protect against cases where the agent is programmed to do the wrong thing, or where the task input leads to an unintended high-impact query. Tests and human-in-the-loop controls serve different purposes; tests verify correctness, while human oversight provides accountability for consequential actions in production.

Deploying the agent in a staging environment for 30 days to validate write operation behavior before enabling in production is wrong because staging validation is another good practice that belongs in any deployment pipeline, but 30 days of staging runs do not address the fundamental governance question of who authorizes irreversible writes in production. Staging validates behavior in a controlled environment; it does not substitute for human oversight of production write operations.