An engineering team is deploying an agent to manage GitHub repository labels — creating new labels, updating colors, and deleting obsolete ones. The team wants the agent to operate autonomously for low-risk actions but require human approval for deletions. Which configuration best implements this tiered autonomy model?
Select an answer to reveal the explanation.
Short Explanation
You want autonomy that matches risk. Let the agent create and update labels on its own, but make deletions wait for human approval before the delete API runs. That keeps low-risk work fast and blocks the higher-risk, harder-to-undo action.
Full Explanation
Tiered autonomy is the practice of calibrating the degree of agent independence based on the risk profile of each action type. Rather than choosing between full autonomy and no autonomy, a well-designed agent has different permission levels for different actions, with guardrails that scale to the potential impact.
The correct configuration is the one that gives the agent permission to create and update labels autonomously, but routes any proposed deletion to a human-approval workflow before the delete API is called. This implements exactly the tiered model. Creating and updating labels are reversible, low-risk actions; if the agent creates a label with the wrong color, it can be corrected easily. Deleting a label is more consequential: it may remove a label that is referenced in open issues, PR filters, or automation rules, and deletion may not be easily undone without manual effort. Routing deletions through a human-approval workflow before the API is called is the right guardrail for this higher-risk action, while leaving lower-risk operations autonomous preserves the efficiency benefit of using an agent.
The configuration that gives the agent full write access to labels and logs all deletions to a Slack channel so the team can review them after the fact is incorrect. Logging deletions after the fact is not a guardrail; it is an audit trail. Post-hoc logging can help with forensics but does not prevent harmful deletions. If a label used by 200 open issues is deleted, the log does not undo the damage.
The configuration that gives the agent read-only access to labels so it can only report proposed changes, and requires a human to perform all create, update, and delete operations manually, is incorrect. Read-only access eliminates the agent's utility for automation entirely. If a human must perform every create, update, and delete, the agent provides no labor savings. This overcorrects by making the agent fully passive.
The configuration that allows the agent full autonomy over all label operations during business hours, and restricts it to read-only access on weekends to reduce risk, is incorrect. Time-based autonomy, with full access during business hours and read-only access on weekends, is not risk-based; it is schedule-based. A harmful deletion is equally harmful on a Tuesday as on a Saturday. The risk of an action does not change with the time of day, and this configuration provides no protection when engineers are actively working.
Key principle: guardrails should be proportional to risk, not binary or time-based. Grant autonomy where actions are reversible and low-impact; require human gates where actions are irreversible or high-impact.