GitHub Repo
AutoGPT 0.9.0 Adds External Action Tiers, Letting a Supervisory Model Judge Some Actions
AutoGPT released platform beta 0.9.0 on October 23, distinguishing how external tools are approved based on the impact of their actions. The update can reduce some manual confirmations, but tests disclosed by maintainers still found cases where actions were mistakenly allowed, so permission rules should be validated before deployment.
AutoGPT released autogpt-platform-beta-v0.9.0 on October 23, adding declarations of tool action impact and a new approval tier system. The change lets Auto mode delegate some external actions to a supervisory model for judgment, while actions such as sending email, making payments, and deleting data retain the default behavior of asking first. This directly changes how agents execute when connected to external services. Release notes
The adjustment affects the platform’s basic execution unit, the block. Official documentation explains that blocks can be connected into workflows that describe agent behavior. AutoPilot can also skip building a complete workflow and directly execute supported blocks, such as conducting research, calling APIs, or running code. The same approval mechanism therefore needs to cover both one-off tool actions in a conversation and multi-step agents. Block development docs, AutoPilot docs
According to the merge notes, the previous Auto mode asked about every external action, and could even block read-only tools whose impact had not been declared. The new EXTERNAL_JUDGED tier lets a supervisory model assess actions such as tagging, drafting, and adding records. Workflows take the tier of their highest-risk step. This adds the meaning of an action to the execution gate, rather than asking only based on whether it connects outside the platform. Technical changes
However, approval by the supervisory model does not mean every step will execute: existing human review gates still block some irreversible actions. The maintainers also noted that the judgment rules were tested on only 53 synthetic cases. The Haiku fallback model mistakenly allowed the action in two of three runs of a case where a private message was sent to the wrong user. These results cannot be used to infer a reliable blocking rate in real-world traffic. Known limitations
For deployment teams, the next step is to replay tests using real tool parameters, with particular attention to recipients, data exfiltration, and existing allow rules. They should also separately verify approval outcomes for direct calls, workflows, and scheduled runs. The benefits of fewer confirmations still depend on whether action classifications and supervisory judgments match the team’s authorization boundaries.