Skip to main content

Execution Rules Guide

This guide covers the choices and the criteria for deciding how much of an operation to allow an agent.

The mechanism itself is covered in How much to delegate, including how it differs from a guardrail.

Where a section has a place on screen, you will find where to set or check what it asks you to decide at the end of it.

They apply to a project's runs and nothing else​

Execution rules apply to a project's steps as they run, and to a cycle's rounds. They do not apply to ordinary conversations, or to schedules that run outside a project.

They inherit the execution rules set for the whole tenant. All a project can do is tighten them; it cannot go looser than the global rules.

Choosing the basic rules​

There are three basic rules, from loosest to strictest.

  • Open — classified operations pass as they are
  • Guarded — operations classified as destructive are stopped
  • Strict — only reads pass

Basic rules looser than the global basic rules cannot be chosen. Where the whole tenant is on Guarded, a project cannot go back to Open.

The basic rules can only judge the operations built into the product. The classes are settled on the product side, and a user cannot change them (How much to delegate).

To stop something for certain, write it as a forbidden operation​

Where you know what you want stopped, write it into “Forbidden operations added by the project” rather than reaching for the basic rules. That is the way to stop something for certain.

A forbidden operation is judged before the basic rules. That is what sets it apart from the basic rules.

An operation that was blocked — whether by the basic rules or as a forbidden operation — is not allowed even where a reviewer advances the step. It cannot be overridden by a person's decision (How much to delegate).

“What to forbid” is one of three.

  • Internal tools — pick the operation kind from Text write / File read / File transfer / Command execution / Browser automation / Desktop automation
  • External integration — choose the connection. For an external service you also give a tool name, which takes a pattern (for an agent-to-agent integration, the connection is all)
  • Tool name pattern (legacy) — give a pattern for the tool name, whatever the connection

Global forbidden operations cannot be removed from the project. Only what the project added can be taken away.

Where on screen The Settings tab ＞ “Execution rules” ＞ choose the basic rules with the radio buttons, and add forbidden operations under “Forbidden operations added by the project”

A connector is only stopped as a forbidden operation​

Neither an external service nor an agent-to-agent integration is judged by the basic rules. They pass even on the strictest, Strict.

The only way to stop one is a forbidden operation. But how you name it differs by kind.

  • External services — give the connection and a tool name. The tool name takes a pattern
  • Agent-to-agent integrations — give the connection only. It stops the calls as a whole; you cannot name anything finer

Where there is no connection to choose, the screen says so. That is the state where no active connector is registered in the environment.

When it takes effect​

A change is saved immediately. What it takes effect on is every agent that starts after it.

It does not reach an agent that has already started. Where a workflow run is part-way through, the agents on the later steps — the ones that start after the change — are held to the new rules.

Changing the rules alone will not stop what is running. In a workflow, cancel that run (an agent that is already working is sent a stop, and the run goes no further). In a cycle, switch off that placement's rounds — but whatever has already been accepted is not cancelled (Trigger Guide).

Checking what is in effect​

What the screen shows is the basic rules, and the forbidden operations this project added.

  • Global basic rules — the basic rules settled for the whole tenant
  • Restrictions added in this project — the basic rules this project chose, and how many forbidden operations
  • Basic rules in effect — the basic rules now in effect, given both

🚨 Global forbidden operations do not appear on this screen. They are in effect all the same when something runs. However loose the basic rules look, an operation forbidden for the whole tenant does not get through.

The class of each operation is not edited on this screen. The classes are settled on the product side. A forbidden operation this project added is judged separately from the basic rules.

Where on screen The Settings tab ＞ “Execution rules”. “Global basic rules”, “Restrictions added in this project” and “Basic rules in effect” appear there

Distinctions worth keeping straight​

These are the distinctions that cut across the sections above.

  • Thinking the basic rules stop connectors too. Neither an external service nor an agent-to-agent integration is judged by the basic rules. To stop one, write the connection as a forbidden operation (and the tool name, for an external service)
  • Thinking a review step can pick and choose operations. A blocked operation is not allowed even where a reviewer advances the step. And the other way round: a review step only settles whether the work goes on to the next step — it cannot pick out individual operations and stop them (Review Guide)
  • Thinking a project can loosen them. Basic rules looser than the global basic rules cannot be chosen, and global forbidden operations cannot be removed
  • Thinking they apply to ordinary conversations. They apply to a project's steps as they run, and to a cycle's rounds, and nothing else
  • Thinking the classes can be changed. The classes are settled on the product side. What you can change is the basic rules and the forbidden operations the project adds
  • Thinking the screen shows all the rules. Global forbidden operations do not appear on it. They are in effect when something runs, so an operation may not get through without the screen telling you why
  • Thinking that tightening the rules stops what is running. It takes effect on every agent that starts after it. To stop it, cancel the run in a workflow (an agent that is already working is sent a stop), or switch off the rounds in a cycle (what has been accepted is not cancelled)