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?
Select an answer to reveal the explanation.
Short Explanation and Infographic
When you hand someone the keys to the vault, you add a second lock — that's exactly what Answer D does. Expanding an agent's capability from idempotent maintenance (VACUUM, REINDEX) to irreversible mutation (UPDATE, DELETE) is a qualitative jump in blast radius. The required architectural change is a human-in-the-loop gate on write operations. Context window size, tests, and staging runs are good engineering hygiene but don't address the governance requirement when you escalate destructive capability.
Full explanation below image
Full Explanation
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.
Why D is correct: The human-in-the-loop (HITL) 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.
Why A is wrong: 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.
Why B is wrong: 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 HITL serve different purposes; tests verify correctness, HITL provides accountability for consequential actions in production.
Why C is wrong: 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.