Actions

Actions let an agent perform operations through your existing API. Each action describes a request, the inputs it accepts, and the policy that controls whether it can run.

Your organization maintains an action catalog. Each agent is granted a selection of actions from that catalog. Registering an operation and giving an agent permission to use it are separate steps.

Discover actions from your code

Open Actions, choose Scan actions, then Automatic from code. Teaflask reads your connected repositories to discover API operations and proposes changes to the catalog:

• Create a newly discovered operation.
• Update an existing definition to follow changes in the code where you have not edited it. Your edits are kept where the code has not changed that field. If the code changes a field you edited too, the review shows both versions and asks you to choose which to keep. It never silently replaces your edit.
• Deprecate an operation that is no longer available.

Review the proposed definition and policy before approving it. Approval applies the catalog change; the scan itself does not apply it. Approving a new action does not grant it to any agent.

Dismissing a code-change proposal keeps the same change from returning on the next scan. It can return when the code changes again.

You can also upload your API files instead of scanning a repository. Uploads propose catalog changes for review, but never propose removing actions.

Read an action's details

Open an action to see its definition and the chips beside its title:

• Its source shows where it came from: Manual, Scanned, Inferred, Generated, or Uploaded.
• Its effect chip describes what calling it does. An unclassified action has no effect chip.
• A Verified chip shows when a scan last checked the action against its source. After a member edits a source-defined field, Edited by shows who made the edit and when, in place of the verification chip. An approved scan update clears that edit stamp; it does not necessarily discard the edit.

The Endpoint area shows the request's identity and permanent slug, plus Code last checked when available. For GraphQL actions, it also shows the operation document. These facts describe the registered request; they are not a test of your adapter or proof that a request has executed successfully.

Understand the effect classifications

The review queue and catalog group actions by their recorded effect:

Classification	Meaning
Read-only	Reads information without modifying it.
Idempotent	Repeating the same request is intended to have the same effect as making it once.
Destructive	Makes a consequential change to, or removes, data.
Unclassified	Nobody has classified this action yet.

You can set the classification using Effect on the action page.

These are descriptions of the operation's intended effect. They do not replace its execution policy or your API's authorization checks.

Set policies and grant access

Each catalog action has one execution policy:

Policy	Behavior
Allow	Permits execution without approval unless the agent's configuration requires it.
Ask	Requires approval before execution.
Deny	Is excluded from the agent's available actions.

To make an action available to an agent, open that agent's Actions settings and select it. Grants name individual actions; there is no wildcard that automatically includes future catalog additions. Publish the agent's updated configuration to make the grant available to users.

An agent can require approval for an action whose catalog policy is Allow, but it cannot relax a catalog Ask or Deny policy.

How an action executes

Teaflask validates the model's arguments against the action's schema and builds a request using the registered method and path template. If approval is required, execution waits for the user's decision.

The request is passed to the embedded assistant in the browser. Your actions adapter sends it to your API using the authentication you configured and returns the result to the agent. Your API enforces authorization for those credentials. Without an actions adapter, the embedded assistant cannot execute catalog API actions.

See Adapters for connecting actions to your existing API client, session cookies, or authentication headers. Page navigation and form prefilling are separate capabilities under App access.

Update or archive an action

On the action page, you can edit its title, description, effect classification, and policy. Open an argument to edit its description, whether it is required, its allowed values, or a fixed value, where those controls are available. Some constraints come from the request itself: a path parameter is always required, and a GraphQL variable's required status is set by the query. Arguments defined through shared types may be read-only.

An action's catalog definition is shared by the agents that use it. Changing an existing action's policy, description, or argument settings can affect those agents without republishing their configurations. This differs from adding a new action, which still requires an explicit grant.

If published agents grant an action, changes to its description or arguments require confirmation. Policy and title changes do not require that additional confirmation.

The slug and HTTP method are fixed after registration. Changing the endpoint's path shape requires a new action rather than repurposing an existing identifier.

Archiving retains the catalog record but makes the action unavailable in subsequent turns. An agent that still references it receives an unavailable-action result. Archiving does not cancel a request already sent to the browser.

Continue reading

• Upload your API files: propose actions without connecting a repository.
• Adapters: connect API execution to your frontend.
• Action schema: define parameters, request bodies, and validation.
• Tool views: display action results using your own components.
• Conversations: inspect action requests, approvals, and results.