> ## Documentation Index > Fetch the complete documentation index at: https://docs.usenash.com/llms.txt > Use this file to discover all available pages before exploring further. # Custom agents > Configure a scoped, instruction-driven Nash agent for a recurring job, then run it on demand or on a schedule. A custom agent is a reusable Nash agent you set up once for a specific, recurring job. You give it a name and a set of instructions, tell it what data it should focus on, decide whether it can take action or only report what it finds, and then run it whenever you need — manually, on a schedule, or in response to an event. Think of a custom agent as a specialist you've briefed. Where the main Nash assistant is a generalist you chat with, a custom agent is purpose-built: "watch our late deliveries each morning and flag anything trending the wrong way," or "every Monday, summarize last week's provider performance and notify the team." ## When to use this Reach for a custom agent when you have work that: * **Repeats on a cadence** — a daily late-delivery sweep, a weekly performance summary, an end-of-month reconciliation. * **Should follow the same playbook every time** — consistent instructions, the same data scope, the same output format. * **Needs to run without you in the loop** — kicked off by a schedule or an incoming alert rather than a chat message. * **Has a clear boundary on what it can touch** — limited to certain providers, zones, or contracts, and limited in whether it can act or only advise. For one-off questions or ad hoc investigation, just talk to the main Nash assistant. Reach for a custom agent when you want that work to happen the same way, again and again. A few shapes teams commonly run: a **daily ops briefing** that summarizes exceptions before the morning standup, an **SLA guardrail** that investigates any delivery trending toward a breach, a **cost drift watcher** that flags weekly spend variance by provider or zone, and a **provider scorecard** that compiles monthly performance summaries. ## How it works A custom agent has two layers of behavior, and understanding the difference is the key to setting one up well. **Instructions** are the free-text brief you write — what the agent should do and how it should think about the job. The agent does its best to follow them, but instructions are guidance, not a hard rule. Over a long run, an agent can drift from a wordy prompt. **Configuration** is everything you set with structured controls — scope, execution mode, skills, knowledge, output format. These are enforced by Nash on every run, outside the agent's discretion. If you need a guarantee ("only ever look at these two contracts," "never take action without my approval"), put it in configuration, not in the instructions. A good rule of thumb: write the *intent* in instructions, but pin the *boundaries* in configuration. When you're drafting an agent, Nash can review your instructions and point out anything that would be more reliable as a 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. ## Set it up Name the agent, and pick an icon and color to make it easy to spot in your list. You don't write a description — Nash generates one for you from the agent's name and instructions. Describe the job in plain language — what the agent should look at, what it should do, and how to present its findings. This is the brief the agent follows on every run. Narrow what the agent focuses on by selecting specific providers, zones, or contracts. Leaving these empty means no constraint — the agent considers your whole operation. Scope keeps the agent on-task and focused on the slice of your operation that matters for this job. Pick the agent's **execution mode**: * **Report only** — the agent investigates and writes up what it found and what it *would* do. It surfaces changes as recommendations rather than performing them; acting on one is a step you take yourself. This is the safe default and a good place to start. * **Auto-execute** — the agent carries out routine actions itself without waiting on you. Actions your organization's guardrails keep in the Confirm tier — like canceling a delivery or reassigning a provider — still pause for your approval (see [Guardrails & confirmations](/nash-agent/guardrails)). On top of those org-level guardrails, you can require confirmation for additional specific high-stakes actions (see below). * **Skills** are named bundles of capability you can hand the agent. Leave the default set, or pick an explicit list. * **Tools** extend what the agent can reach. Connected third-party systems become available here too — see [Connectors](/nash-agent/connectors). * **Knowledge** is reference material — your SOPs, policies, or business context — that grounds the agent's answers. Custom agents inherit your organization's shared knowledge by default; you can turn that off and give an agent its own. See [Knowledge](/nash-agent/knowledge) for the full picture. Attach a schedule or a trigger so the agent runs automatically, or just save it and run it on demand. Scheduling is covered in depth on the [Scheduling and execution](/nash-agent/scheduling-and-execution) page. ### Keeping high-stakes actions safe You can name specific destructive actions that always require your sign-off before the agent runs them — even when the agent is in auto-execute mode. These cover things like canceling a delivery, requesting a refund, reassigning a provider, rescheduling, or sending a message to a customer or driver. When the agent wants to take one of these actions, it pauses and surfaces a confirmation for you to approve or decline. The action doesn't happen until you say so. Reaching customers or drivers directly — by text message or outbound voice call — always asks for your confirmation, and these tools must be turned on for the agent before it can use them. They may not be available to every account. ### Structured output and writing results back By default, an agent reports its findings as a written summary. If you want each run to produce consistent, structured fields instead — a risk level, a status, a headline, a short summary — you can define an **output format** for the agent. Each run then fills in those fields the same way, so results are easy to scan and compare over time. You can also have the agent **write its results back onto a job's record**, so the conclusions it reaches live alongside the delivery they're about. This keeps an agent's output to its own clearly-labeled fields so it can't disturb anything else on the record. ### Run limits You can cap how much a single run is allowed to spend or how many tokens it can use. These caps work alongside your organization's defaults — a tighter agent-level cap takes precedence. Leave them unset to fall back to the organization default. ## Managing your agents Once you have agents, you manage them over their lifecycle: | Action | What it does | | -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Star** | Marks an agent as the canonical one of its kind for your org. Starred agents float to the top of the list. | | **Pause / resume** | Silences all of an agent's automated runs at once without deleting anything. A paused agent reports its status as paused and stops firing on schedules or triggers until you resume it. | | **Duplicate** | Creates a fresh copy you can customize. Duplicates always start in report-only mode as a safety default, so a copy never inherits the ability to take action until you grant it. | | **Move to a folder** | Organizes agents into shared folders so your team can find them. Move an agent to "Ungrouped" to take it out of a folder. | | **Run now** | Triggers an immediate run, regardless of any schedule. A run-now you start is owned by you and shows up in your own chat history. It runs even if the agent is paused — an explicit override on your part. | | **Delete** | Archives the agent and tears down its scheduled and triggered runs. | Nash ships a set of ready-made global agents that appear in every organization's list. These are read-only templates — to customize, star, schedule, or file one into a folder, **duplicate it first** and edit your own copy. ## FAQ Creating, editing, scheduling, and running custom agents is a managed permission, typically granted to operations managers and admins rather than every user. If you can view agents but can't edit them, you likely have read access without management access. Check with whoever administers your Nash account. Pausing is an agent-level off switch — it quiets *every* automated run the agent has at once. Disabling a single schedule or trigger affects only that one. Pausing leaves everything in place so you can resume cleanly later. Manual "run now" still works on a paused agent. Yes. You can set an agent to revisit a job on a cadence — checking back every so often and continuing in follow-up passes until the thing it's watching is resolved. This is configured as part of its run setup; see [Scheduling and execution](/nash-agent/scheduling-and-execution). That's what [Entity monitor](/nash-agent/entity-monitor) is for — a custom agent that keeps an eye on one in-flight delivery, order, return, route, or job and flags problems as they emerge. ## Related Talk to an agent directly — it answers and works under its own brief, scope, and execution mode. Run an agent on a schedule or in response to an alert — and have it work iteratively over time. Set a custom agent to watch a single delivery or route until it reaches a final state. Ground your agents with SOPs, policies, and reference links — for your whole org or a single agent. Connect external systems so your agents can use them as tools.