An agent autonomously creates feature branches and opens pull requests as part of its workflow. The team is concerned about agents cluttering the repository's branch namespace and making it difficult to distinguish human-created branches from agent-created branches. Which branch naming strategy MOST effectively addresses this concern?
Select an answer to reveal the explanation.
Short Explanation
Branch named 'fix-dependency' could be from human or bot, so you'd have to check commit author to know. Branch under reserved prefix like 'agent/dep-update-agent/task-20240729-001' is unambiguous at a glance. Reserved prefix gives machine-enforceable convention and human-readable signal, and agent name plus task ID gives traceability.
Full Explanation
Branch namespace management in agent systems is an operational hygiene concern with real consequences for repository usability, CI cost, and incident response.
The strategy that lets agents use any branch name they choose is the anti-pattern. Mixed namespaces make it impossible to build automation that targets agent branches, such as auto-deleting stale agent branches, applying different CI rules to agent PRs, or filtering the branch list. Incident response is hampered when you cannot quickly identify which open PRs were created by agents.
The strategy that requires all agent-created branches to use a reserved namespace prefix, such as 'agent/' or 'bot/', enforces that at the GitHub branch protection or rulesets layer, and includes the agent name and task ID in the branch name is the most effective one. It works for three compounding reasons. First, the reserved namespace prefix creates a machine-readable and human-readable signal. Engineers scanning the branch list immediately know which branches are agent-created. GitHub Branch Rulesets can apply different rules to 'agent/' branches, such as a required merge queue or different reviewer requirements. Automation can target 'agent/' for cleanup jobs. Second, including the agent identity in the branch name, such as 'dep-update-agent', answers which agent created the branch without looking at commit metadata. This is critical when an agent is misbehaving and you need to find all its branches. Third, including a task ID in the branch name enables direct correlation between a branch and the task that created it, linking the branch to logs, audit trails, and the triggering event. The full name 'agent/dep-update-agent/task-20240729-001' is self-describing and uniquely identifiable.
The strategy that has agents append '-automated' to whatever branch name they would naturally generate is better than nothing but provides less information and is harder to enforce mechanically. GitHub Rulesets cannot target branches ending in '-automated' as cleanly as they can target branches starting with 'agent/'. Also, appending a suffix to a natural branch name means 'fix-dependency-automated', so the branch name still looks like a human branch name with a suffix rather than a clearly distinguished namespace.
The strategy that stores a separate registry file in the repository listing all agent-created branches requires manual maintenance, creates a race condition when multiple agents create branches simultaneously, and is a secondary lookup rather than an inline signal. Engineers must open a file to answer questions that should be answerable from the branch name alone.