Skip to main content
Parameterized Agents let you define an input schema on any agent so it accepts runtime variables, an org ID, a department name, a list of assets to analyze, or a recipient email. One agent definition can then run for multiple subscribers, each with its own parameter values. Every run executes with the agent owner’s data access, not the subscriber’s. This guide walks you through defining input parameters, configuring subscriptions, and managing templates.

​
How it works

An adaptable execution workflow that maps central logic templates to individual subscriber environments through a four-stage process.

Define input parameters

Open your agent in edit mode and define an input schema: variable name, type, description, and an optional default value. Supported types are text, number, boolean, email, and Slack.

Collect runtime parameters

When a user manually triggers a parameterized agent, a generated input form collects their values. Submitted values are injected wherever you reference the parameter throughout the agent’s prompts and node configurations.

Iterate over parameter value sets

Provide multiple value sets and the agent runs once per set, each in an independent context. This is how you iterate over a collection, since input parameters don’t support a list type.

Manage subscriptions and templates

Admins can publish an agent as a template and push-enroll users as subscribers. Each subscriber has their own parameter bindings. When the agent runs:
  • Each subscriber receives a run with their own parameter values. The run executes with the agent owner’s data access.
  • Runs execute under the runner’s (owner’s) identity, and RLS/CLS are enforced based on the runner’s permissions, not the subscriber’s.
  • Failures are isolated: one subscriber’s error does not affect any other subscriber’s run.

​
Subscription visibility

Depending on your subscription status, agents will appear in one of two distinct tabs within your workspace:

​
Target users

Parameterized Agents are available to:
  • Admins: Define input schemas, publish templates, and push-enroll subscribers.
  • Agent Builders: Build parameterized workflows and test with different input values.
  • All users: Once push-enrolled by an admin, trigger agents with their own parameters via the input form.

​
FAQs

Text, number, boolean, email, and Slack. File and attachment input support is on the roadmap.
Yes. Scheduled fan-out is supported in the latest version.
No. Runs execute under the runner’s (owner’s) identity, and RLS/CLS are enforced based on the runner’s permissions, not the subscriber’s.
No. Each subscriber can only see their own runs. Run logs and outputs are not shared across subscribers.
Yes. Template updates propagate to all subscribers on the next run. Existing subscriber parameter bindings remain valid unless the input schema changes in a breaking way.
Viewer access (IAM) controls who can see that the agent exists at all. Subscription controls who runs the agent and receives its output. These operate independently—an admin can push-enroll a subscriber, which implicitly grants viewer access if it isn’t already present.

​
Next steps

Understand domains

Learn how domains organize the data logic and permissions your agents run against.

Domain Health

Measure and improve your domain’s readiness before opening it to subscribers.