Skip to main content
This is the companion reference to Custom agents — start there for the concepts and a walk-through of setting one up. This page lists every setting you can configure on a custom agent, grouped by area, with what each one does, its options, its default, and who can change it. A reminder on the two layers of behavior (covered in depth on the Custom agents page): instructions are the free-text brief the agent does its best to follow, while configuration — everything on this page — is enforced by Nash on every run. When you need a guarantee, put it in configuration.

Who can set these

Almost every setting here is changed through the same managed permission tier that lets you create, edit, schedule, and run custom agents — typically operations managers and admins, not every user. Throughout this page that tier is referred to as agent management. Members with read-only access can view an agent’s configuration but can’t change it. A few settings have an extra requirement on top of agent management; those are called out in the Who can set it column.
Nash ships a set of ready-made global agents that appear in every organization’s list. They’re read-only templates — to change any setting below, duplicate the agent first and edit your own copy.

Identity

How the agent shows up in your list.

Instructions

The free-text brief the agent follows on every run.
Before you save, you can have Nash review a draft’s instructions and flag anything that would be more reliable as a structured setting — for example, a list of providers typed into the prompt that belongs in the scope filter. It only suggests; it never blocks you from saving.

Scope

Narrows what slice of your operation the agent focuses on. Leave a dimension empty for no constraint on that dimension. Setting any of providers, zones, or contracts pins the agent to that slice on every run.
The provider, zone, and contract filters take effect today and constrain every run. The date range is stored but not yet applied — it’s saved on the agent so the setting survives, but it does not currently restrict what the agent looks at. Until that changes, the agent chooses the time window for each question itself. Don’t rely on the date range to limit the agent’s view yet.

Behavior and execution mode

Controls whether the agent can act on its own and which high-stakes actions always pause for your approval.
When you duplicate an agent, the copy’s execution mode is always reset to report only, regardless of what the original was set to. This is a deliberate safety default — a copy never inherits the ability to take action until you grant it.

Confirm-first action keys

Any action key you list here is forced to require your confirmation before the agent runs it, even when the agent is in auto-execute mode. The recognized keys are:
Listing an action key here is an override: it forces confirmation for that action on top of whatever your organization already requires confirmation for. It’s how you ratchet a single agent stricter than the org default.

Skills and tools

What capability the agent can reach beyond its base toolkit.
The text-message and voice-call tools always pause for your confirmation before they send or dial, and they must be turned on for the agent (listed above) before it can use them at all. They also require your account to hold the permission for these tools — without it, they won’t appear as options. They may not be available to every account. Text messaging in particular is opt-in and may not be available on every account yet; voice calling is the more established of the two. See Skills for more on skills.

Knowledge

Reference material that grounds the agent in your operation’s context. See Knowledge for the full picture.

Output and writeback

How the agent reports its results, and whether it records them onto a job. By default an agent reports its findings as a written summary. You can instead define a structured output format so every run fills in the same named fields, and you can optionally have the agent write those results back onto a job’s record.

Output format fields

Each field in an output format has these properties:

Limits

Caps on how much a single run may spend or consume. These work alongside your organization’s defaults — a tighter agent-level cap takes precedence, and you can only ever lower the org cap, never raise it. Leave both unset to fall back to the organization default.
A cap of 0 does not mean “block everything” — it means “no cap from this agent.” If you want to limit a run, set a positive number. To pause an agent entirely, use pause/resume instead.
These per-agent caps are the agent-level overrides of your organization’s per-session defaults. The org-wide defaults they fall back to are set on your organization’s Nash Agent settings, not here. See Usage and cost for the org-wide spend limits these caps sit alongside.

Notifications

Who gets told when a run finishes or fails. You can preview how a notification will read before you save it.

Organizing

How the agent is filed and surfaced in your list.
You can only choose a folder when you first create an agent. To move an existing agent into a different folder (or back to Ungrouped), use the dedicated move action rather than the edit form — folder changes made through a plain edit are ignored. Star, pause, and resume are also their own actions rather than fields on the edit form; see Custom agents for managing an agent over its lifecycle.

Model

Which model the agent runs on.
There’s no validation of the model identifier when you save — any text up to 128 characters is accepted and only checked when the agent actually runs. Stick to a model ID you know is supported (the default, claude-opus-4-8, is a safe choice); a typo or an unsupported value won’t be caught at save time and would only fail at run time.

Scheduling and runs

A custom agent’s recurring runs — their cadence, timezone, and trigger — are configured as separate run definitions attached to the agent, not as fields on the agent itself. Those run settings, including how the agent can work iteratively over time, are covered on the Scheduling and execution page.

FAQ

That’s intentional. Every duplicate is forced into report-only mode as a safety default, no matter what the original was set to. Re-enable auto-execute on the copy once you’re sure it’s scoped the way you want.
The date range is saved but not yet applied to the agent’s work. The provider, zone, and contract scope filters do take effect, but the date range setting doesn’t currently restrict the time window the agent looks at — the agent still picks a window per question. Use the scope filters for hard boundaries today.
No. That capability is controlled at the organization level in your Nash Agent settings, not per agent, so there’s no field for it on the agent.
The agent’s spend and token caps are per-agent overrides that can only tighten — never loosen — your organization’s per-run defaults. If you set a tighter cap on the agent, it wins; if you leave them unset, the agent falls back to the org default. The org-wide defaults are set on your organization’s Nash Agent settings. See Usage and cost.
Not today. The only supported writeback target is a job’s record. When you turn writeback on, you also have to define an output format and a writeback namespace so the agent’s writes are confined to clearly-labeled fields.

Custom agents

The conceptual overview — what a custom agent is, when to use one, and how to set it up.

Scheduling & execution

Configure when and how often an agent runs, and how it works iteratively over time.

Knowledge

Ground an agent with SOPs, policies, and reference links.

Skills

Reusable, named procedures you can hand an agent.