📄 Full write-up (all 7 requests): https://gist.github.com/CallMeCJ/59eeb39c4eb459e89eab22a2b34da6e5
Summary. There's no supported configuration to disable a built-in agent or restrict the built-in set to an allow-list.
Current behavior. The built-in agents are always live: the task tool can dispatch any of them, and there is no supported configuration to turn an individual built-in agent off — or to disable the built-in set as a whole. There is no allow/deny list and no kill-switch. If a built-in agent misbehaves, there's no way to stop it from being dispatched short of not using the task tool at all.
What we want. A supported disable / kill-switch for built-in agents — scoped per agent type and/or to the entire built-in set — so a deployment can guarantee specific built-in agents are never dispatched. Ideally expressed as an allow-list (only these built-ins are enabled) so new built-ins added by the SDK are opt-in rather than automatically exposed.
Potential impact. Without a disable switch, a built-in agent that misbehaves (e.g. fails to terminate, loops, or repeatedly dispatches — cf. #864) cannot be fenced off; it consumes tokens and can hang the turn, with no supported mitigation. The control is needed both reactively (take a known-bad built-in out of rotation until a fix ships) and proactively (restrict the built-in set to the agents validated for production).
Related: #1770 (configurable execution limits — defense-in-depth), #1767 (curating the built-in agent menu)
Summary. There's no supported configuration to disable a built-in agent or restrict the built-in set to an allow-list.
Current behavior. The built-in agents are always live: the
tasktool can dispatch any of them, and there is no supported configuration to turn an individual built-in agent off — or to disable the built-in set as a whole. There is no allow/deny list and no kill-switch. If a built-in agent misbehaves, there's no way to stop it from being dispatched short of not using thetasktool at all.What we want. A supported disable / kill-switch for built-in agents — scoped per agent type and/or to the entire built-in set — so a deployment can guarantee specific built-in agents are never dispatched. Ideally expressed as an allow-list (only these built-ins are enabled) so new built-ins added by the SDK are opt-in rather than automatically exposed.
Potential impact. Without a disable switch, a built-in agent that misbehaves (e.g. fails to terminate, loops, or repeatedly dispatches — cf. #864) cannot be fenced off; it consumes tokens and can hang the turn, with no supported mitigation. The control is needed both reactively (take a known-bad built-in out of rotation until a fix ships) and proactively (restrict the built-in set to the agents validated for production).
Related: #1770 (configurable execution limits — defense-in-depth), #1767 (curating the built-in agent menu)