You can protect an agent with Source Control from the dropdown next to the agent name, or from the dropdown on the All agents page.

Source Control for agents operates similarly to how it does for apps, but with some key differences.

• Agents cannot be moved or renamed. Protected agents and the folders in which they're located cannot be renamed or moved. You must unprotect agents before making name or location changes. Protected agents must have a unique name.
• Agent triggers cannot be protected. You can edit the trigger of a protected agent without creating a commit.
• Evals and Datasets are incompatible. You cannot access evals and datasets from a protected agent.

Enterprise customers can now use Source Control to protect workflow triggers. This prevents changes to a workflow's triggers without review. When you protect a workflow for the first time, triggers are now automatically included.

To enable protected workflow triggers, navigate to Settings > Beta, and enable Allow users to edit triggers on branches.

For workflows that are already protected, you now have the option to protect triggers using a new PR.

Once protected, triggers are versioned and published alongside each release. Information about your triggers is stored in the triggers.yml file in your Source Control repository.

You can now see the output of an agent run with the Result (sync) return type when using the Invoke Agent block in workflows.

• The Result (sync) type is the default setting. This returns the direct result of the agent's output.
• The Run state (async) type returns the agentRunId, agentId, and status only. It does not include the output of the agent.

Enterprise customers can send page load and query traces to Datadog and Sentry using Retool's performance monitoring integration, now in public beta. Customers can respond proactively to regressions and troubleshoot more quickly by creating dashboards and alerts to monitor the performance of their apps and use the spans themselves to help pinpoint where to take action if their apps are degraded.

Internationalization (i18n) is now generally available for organizations on the Enterprise plan. This allows you to localize Retool app content and data.

Retool now supports managing permissions using role-based access control in public beta. You can create roles with granular permissions so groups can manage certain organization settings without full administrator access.

Role-based permissions offer much greater access control than Retool's existing group permissions functionality. For example, a Design team may need access to your organization's branding settings to ensure the Retool organization follows branding styles and guidelines. Rather than give the team members admin access, role-based permissions allow for granular control over what specific settings they can access.

Once you configure the necessary roles to control access, you can apply them to any number of groups. Retool will eventually transition away from per-group permissions to role-based access controls as the method with which you manage permissions.

To enable this feature, navigate to Settings > Beta and enable Permissions v2.

OAuth 2.0 is now supported when adding an MCP server as a tool for an agent.

Retool Agents is available on Retool's stable release 3.253.0.

To enable Retool Agents in Self-hosted Retool 3.253.0 and later, toggle the AI Agents feature flag in Settings > Beta.

Retool now provides a built-in integration for Databricks Lakebase, a fully managed Databricks Postgres database built on lakehouse architecture.

Self-hosted organizations using Source Control to protect apps can opt into the public beta of multi-instance releases. This feature enables you to publish different release versions of apps across multiple deployment instances. This is particularly useful if you want to test a newer version of an app on a test instance first.