> ## Documentation Index > Fetch the complete documentation index at: https://docs.dualentry.com/llms.txt > Use this file to discover all available pages before exploring further. # How to Test a Scheduled Agent Before You Rely on It > Prove a scheduled agent's instruction, scope, and output path with interactive runs and one live test run, before it starts running unattended. Unattended runs execute without review, so an incorrect entity, an outdated instruction, or a figure that was never traced back to a source record will go undetected. This guide covers the validation path from draft instruction to trusted schedule: first testing interactively within the agent's exact scope, then performing a single live run on a temporary cadence. ## Before you start * Ensure you have the permissions needed to create, edit, pause, resume, and delete a scheduled agent (by default, granted only to the Admin role). Anyone with Copilot access can see that an agent exists and when it runs. * Access to the account that will own the agent. Every run uses the owner's [role scope](../platform-configuration/user-roles-and-permissions) and the owner's own connector credentials, so a test under a different login proves nothing about what the agent will return. * The instruction you intend to schedule (up to 4096 characters), or the `/skill-name` it will invoke. * A decision on entity scope and accounting basis, rather than whatever the composer happens to be set to. * For an agent that calls a connector, confirmation that the owner has personally authorized it. See [how to connect an MCP connector](./connect-an-mcp-connector). ## Test the instruction interactively Everything a scheduled agent does unattended, it does under a fixed entity scope and accounting basis it cannot correct mid-run. These three steps reproduce that scope in the composer and prove the wording against it while you are still watching. ### Step 1: Reproduce the agent's scope in the composer In the [Agents panel](./agents-panel) composer, set the entity selector to the single company the agent will be scoped to, and set the accounting basis to the value the agent definition will carry. Both default to **All companies** and **GAAP**, and both apply to the whole conversation rather than to one message. A scheduled agent takes these two values from its definition, and no one is present at run time to correct them, which is why matching them here is the test rather than a preliminary to it. ### Step 2: Run the instruction verbatim Paste the instruction you plan to schedule into the composer and submit it. If the agent's instructions will begin with `/skill-name`, invoke the skill the same way, with the same trailing arguments. Sign in as the intended owner to do this if that is not you. Read-only questions cannot change the ledger, so repeat this run as often as you need while you adjust the wording. ### Step 3: Check the output against the records Open the source records attached to the response and confirm the figures against them. For a scoped agent, confirm the numbers belong to one company. A consolidated total at this point means the entity selector is still on **All companies**, and the agent will repeat that on every run with nobody reading over its shoulder. ## Fit the instruction to what an unattended run may do A scheduled run has a narrower tool set than the same instruction typed into the composer. These two steps bring the wording inside that boundary before you create the agent. ### Step 4: Reduce the instruction to reporting Keep the instruction to a list, report, or summary that a person then acts on. Unattended runs are barred from creating a workflow, changing a workflow's status, approving or rejecting a record, and applying a bulk reclassification, even when the owner holds those permissions. An instruction that asks for any of them works for you interactively and fails on the schedule. To have the agent support customer-facing work, keep delivery with a person: let the schedule produce the list and do the sending yourself. See [how to send dunning emails with Copilot and Gmail](./send-dunning-emails-with-copilot-and-gmail) for the split in practice. ### Step 5: Expect a connector to read, not to send A connector is the one route an unattended run has to reach outside DualEntry, and it acts with the permissions of the credential that authenticated it rather than the owner's DualEntry role. An unattended run gets the read-only half of that connector: any tool that writes or sends, whether that is emailing a customer, posting a message, or creating a record upstream, is dropped from the agent's tool set before the run starts, whatever the connector's settings say. * Do not schedule delivery. An instruction that asks the agent to email its result works interactively and produces a report instead on the schedule, because the send tool is simply not there. * The connector's **Permissions** section governs interactive runs, which is what its **Interactive Tools** heading means. Nothing set there widens what a schedule can do. * Confirm the owner has personally authorized the connector. Installation is organization-wide but credentials are per user, and a connector showing no tools available is not connected for that person, so the run returns nothing rather than failing loudly. ## Create the agent and prove one live run With the wording settled, create the scheduled agent, let exactly one run land on a throwaway cadence, and confirm the output reaches whoever is meant to act on it. ### Step 6: Create the agent with both scoping fields set explicitly Select **Scheduled Agents** in the Agents panel and create the agent with the wording you just tested. Set: * **Name**, unique in your organization, up to 128 characters, since this is what identifies runs in history. * **Entity scope**. Left unset, the agent queries every company the owner can reach and returns consolidated figures on every run. * **Accounting basis**, even where **GAAP** is what you want. * **Cadence**. The schedule form requires an IANA timezone such as `America/New_York` and pre-fills the browser's, so confirm it is the timezone the report belongs to rather than the one you happen to be sitting in. A schedule created through the API without a timezone resolves against UTC. An agent goes live the moment it is saved; there is no way to create one already paused. To hold it between saving and go-live, save it and then pause it from the agent's actions menu. Pausing keeps both the definition and the history, while deleting an agent deletes its conversation along with it. ### Step 7: Take one live run on a throwaway cadence Set a cadence that fires within minutes: an interval of five minutes (the shortest allowed) or a weekly time a few minutes out. Let exactly one run land, then edit the cadence to the schedule you actually want. A calendar cadence set to a fixed minute can land up to four minutes late: DualEntry spreads those runs across a five-minute window so that agents set to the same round hour do not fire together. An interval cadence is not spread, and fires on time. ### Step 8: Confirm the output reaches a reader Open the agent's conversation. Every run appends one prompt and one response there, and that conversation is the only place output goes. There is no email digest, no Slack delivery, and no notification of any kind: nobody learns a run happened unless they open it. The conversation is also read-only. You cannot reply in it or ask a follow-up, so take any follow-up question to an ordinary composer session. The owner and organization admins can open it. Anyone else needs the session shared with the organization. Confirm that whoever is expected to act on the output can read it before you treat the schedule as done. ## If the agent invokes a skill Test the skill under the same scope, not only the agent that calls it. The skill supplies the wording and constraints; the agent definition supplies cadence, entity scope, and accounting basis. Any constraint the output depends on belongs in the skill's instructions rather than in the invoking message, because an unattended run has nobody to correct it. Editing a skill creates a new version and the audit trail records which version ran, so a result stays traceable to the wording that produced it. Ensure you have the permissions needed to edit a skill (by default, Admin only). Skill edits apply organization-wide, so a change you make to pass your test also changes what your colleagues get from the same slash command. ## Verify The agent is ready when all of these hold: * The interactive run, under the same entity and basis as the definition, returned figures you traced to source records. * The agent's detail view still reads **Active**, with no **Last Error**. * That run's prompt and response are in the agent's conversation. * The run appears in the [audit trail](../platform-configuration/audit-trail-and-compliance) with the same detail as an interactive conversation, attributed to the owner and tagged as a scheduled run. * Nothing in the instruction depends on sending, drafting, or writing through a connector, since an unattended run cannot call those tools. ## Troubleshooting Scheduled agents fail quietly, so most symptoms show up as an absence rather than an error. The table below maps what you see on a scheduled agent to the cause and the fix. | What you see | What to do | | -------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | You cannot find the output at all | Open the agent's conversation. Output goes there and nowhere else, with no notification sent. | | Nothing ran at the minute you set | On a fixed-minute calendar cadence, wait up to four minutes for the spread window. If it is hours off, the schedule is resolving against a timezone other than the one you meant. | | The agent ran for a while, then went quiet | Three consecutive failures move an agent to an errored state and stop the schedule, and nobody is notified. Read **Last Error** on the agent, fix the instruction, then resume. Resuming clears the failure count. | | Figures are consolidated | Entity scope is unset on the definition. Scheduled runs take scope from the definition, not from a selector. | | It worked interactively but failed on the schedule | The instruction asks for an action barred in unattended runs (workflow creation or status change, approval, bulk reclass), or it calls a connector tool that sends or writes, or the owner's role scope or connector credentials differ from yours. | | A run produced nothing and the agent still looks healthy | The previous run was still going when this one fired. Overlapping ticks are skipped rather than queued. Lengthen the cadence, or narrow the instruction so a run finishes well inside it. | | The agent reads **Errored** but ran again anyway | An errored agent whose underlying schedule is still enabled is promoted back to active at its next tick. Pause it if you want it to stay stopped. | | The connector reports no tools available during the test | The owner has not authorized that connector personally. Installation is organization-wide, credentials are not. | | The new agent will not save | The name is not unique, or your organization already holds 50 scheduled agents. | | You cannot pause, edit, or delete the agent | These actions are restricted to organization admins. | ## Related reading * [Scheduled Agents: Cadence, Scoping, and Permissions](./scheduled-agents) * [Copilot Skills: Slash Commands and Built-in Set](./skills) * [Accounting Copilot: Agents Panel Reference](./agents-panel) * [How to Connect an MCP Connector](./connect-an-mcp-connector) * [How to Send Dunning Emails with Copilot and Gmail](./send-dunning-emails-with-copilot-and-gmail) * [Audit Trail and Compliance](../platform-configuration/audit-trail-and-compliance)