Version 3.0
Build
Verified actions

Author a Verified action

Your compliance team needs to know what the agent has been authorized to do, not just what it has done. A Verified action is a discrete operation your team has reviewed and approved: approving a journal post over $10,000, releasing a production hold on a batch, issuing a refund above policy threshold.

Once approved, the action is callable by name from any Runbook or chat. The audit ledger captures every invocation. "What decisions has the agent been authorized to make?" becomes a clean, enumerable list.

Audience: builders

Two names for one feature. The product nav reads Verified logic under Shared Context. The URL, the folder name, and the API still use the older name verified-actions. Both point to the same workspace.

What a Verified action is

A Verified action is a named, reviewable package the agent can call from a Runbook or from chat. Each package contains:

  • A guide. The plain-language description of what this action does and when to use it.
  • A source. The implementation the agent runs when the action is invoked.
  • Examples. Anchor cases that teach reviewers (and the agent) what right looks like.

Once approved, the action is callable by name. Every call lands in the audit ledger with the inputs, the outputs, and the approval that authorized it.

Author a Verified action

Scaffold a Verified action from Shared Context > Verified logic in the left nav. The Build-side entry point is the same surface; choose the scope before you scaffold:

  • Team. Available to one team. Approved by team admins.
  • Workspace. Available to the whole tenant. Approved by workspace admins.

Open the create dialog

Click Logic in the section header. The dialog reads "Create verified logic" with the subtitle "Scaffold the starter first, then edit the generated files in place before submitting a proposal."

Name the entry

Set the title, an optional slug, and a one-sentence summary. The slug becomes part of the reference path.

Edit the package contents

The row lands in the list as a Draft. Open it and work through the guide, the source, and the examples in the drawer.

Submit a proposal

When the package is ready, click Submit proposal in the drawer footer. The entry moves to the Pending proposals queue.

Review states

Every row in the list carries a state badge:

  • Draft. Scaffolded but not yet submitted. Visible only to the author.
  • Live. Approved. Callable by Apps, Projects, and Data Collections in scope.
  • Pending update. A live entry has a fresh proposal in review. The current Live version keeps serving until the proposal lands.

A separate Pending proposals section sits above the list when the scope has candidates waiting on a reviewer.

Call a Verified action

The agent calls a Verified action the same way it calls any tool: by name, with arguments that match the action's contract.

  • From a Runbook. Reference the Verified action by name in the procedure. The compiler resolves the name and the agent picks the call when the Runbook reaches that step.
  • From chat. Mention the action by name in your prompt, or let the agent pick it on its own when the user's request matches.

Every call writes to the audit ledger: the actor, the inputs, the outputs, and the version of the action that ran.

Versions and supersession

A Live entry that needs to change does not get edited in place. You open the row, edit the package, and click Submit proposal. The row stays Live with a Pending update badge until a reviewer approves the new proposal. On approval, the proposal becomes the new Live version and the previous version supersedes.

Why this exists

The Verified actions surface answers a specific governance question: "what discrete operations has my team authorized the agent to take, and on whose approval?" Every approved action carries the reviewer, the timestamp, and the package contents at the moment of approval. Every call carries a link back to the approved version that ran.

That chain is the audit artifact. It is what a controller asks for when the agent has touched a process they care about.

See also

SkillsBuild patterns