Skip to main content
A scheduled agent is an Accounting Intelligence instruction that runs on a cadence without anyone in the composer. Use Agents for recurring work: a Monday list of newly overdue invoices, a daily close-status summary, an unreconciled-items report before a period lock. Scheduled agents appear under Scheduled in the Agents panel. Each entry shows the agent’s name and an indicator for the state of its latest run (see Run states). Every run gets its own chat session, opened from the runs list in the agent’s drawer.

Definition fields

A scheduled agent is defined by four fields, set from Scheduled Agents in the Agents panel. One of them, accounting basis, determines the figures every run returns. The entity a run reports on comes from the wording of the instruction. Scheduled agents are private to the person who creates them. Creating, editing, pausing, resuming, running, deleting, and rolling back an agent are restricted to organization admins, and an admin sees only their own agents in the list. There is no way to share an agent or its runs with a colleague. Someone else who needs the same report creates an agent of their own. The table below lists every field on the agent definition. There is no entity field. An instruction that names no company runs across every company the owner can reach and returns consolidated figures, the same as a question typed into the composer. Agents created while the definition still carried a company selector keep the company they were created with, and every run of those agents stays scoped to it. An organization can hold 50 scheduled agents at a time. There is no per-agent connector selection. An agent reaches the same connectors as the person who owns it, which are the ones that person has personally connected. See how to connect an MCP connector for why connections are per-user rather than per-organization.

Cadence options

Cadence is either a repeating interval or a calendar schedule, and the picker offers five modes. Every calendar mode carries its own timezone. There is no separate daily mode. For a once-a-day agent, set an interval of one day, or use Weekly with every weekday selected if you want it to skip weekends. Times resolve against the timezone stored on the schedule. Any IANA timezone is accepted, such as America/New_York. A schedule saved without one resolves against UTC. The minute you choose is adjusted by up to four minutes when the schedule is saved. DualEntry spreads scheduled runs across a five-minute window so that agents created on the same round hour do not all fire at once. An agent set for 09:00 may therefore run at 09:03.

Where results appear

Every run of a scheduled agent gets its own chat session, and the runs list in the agent’s drawer is where you find them. Open the agent from Scheduled in the Agents panel or from the Scheduled Agents page to reach its drawer. The drawer carries the definition, the current status, the last error, and the most recent runs. Each run row shows when the run started and its status. A finished run opens as an ordinary chat: the instruction as the first message, the agent’s response beneath it, and a composer you can reply in. Open latest run in the drawer footer opens the agent’s most recent run when it reads Completed, Failed, or Waiting on you. It is disabled while that run is still running. It does not skip back to an earlier run. A run that is still running cannot be opened. The sidebar entry, Open latest run, the running row in the list, and a direct link to the run all fall back to the drawer. The controls are disabled, and a tooltip explains that the run is still in progress. Once the run finishes, the same controls open it. There is no email digest and no Slack delivery. The agent’s card and its entry under Scheduled show a badge such as 2 New counting the finished runs you have not opened yet, and each finished scheduled run also adds a Run ready for review card to the Tasks board. Both tell you there is something to read without telling you what it says. If nobody opens an agent’s output, DualEntry eventually pauses it (see Automatic pauses). Runs are private to the agent’s owner. Nobody else can open a run chat, and a run cannot be shared with the organization. If a colleague needs to act on the output, pass it on from the run, or have them create an agent of their own. Runs stay out of Recents until you reply in one. Recents lists conversations you started, and a daily agent would bury them. A run you have replied in has become your conversation, so it appears there from that point on. A run you only read stays findable from the agent’s runs list. Deleting an agent removes it and its runs list from the panel and closes every run chat. A closed chat is read-only and no longer appears in chat lists; it is not deleted. Pause the agent instead when you want the schedule stopped and the runs list kept where it is.

Run behavior

A scheduled agent runs unattended, which changes what its permissions, its scope, and its failures mean compared to the same instruction typed into the composer. An agent runs under the permissions of the user who owns it. Results reflect that person’s role scope, which matters when the owner changes teams or leaves. Review agent ownership when roles change. Accounting basis comes from the agent definition rather than from a selector someone sets at run time. For agents created without a company, entity scope comes from the instruction. An instruction that names no company returns consolidated figures on every run, with no one in the composer to catch it. Agents created while the definition still carried a company selector keep that stored company on every run, whatever the instruction names. Rewording the instruction does not move such an agent to a different entity. Each run is written to the audit trail with the same detail as an interactive conversation, attributed to the owner and tagged as a scheduled run, so an unattended result is as traceable afterwards as one you asked for yourself. A run left in Running because the worker behind it died is marked Failed after about five minutes, with an error noting that the turn was abandoned. A schedule therefore cannot stay stuck behind a dead run. If the previous run is still running when the next tick fires, the tick is skipped rather than queued. A skipped tick produces no run at all, so it shows up as a gap in the runs list rather than as a row with a status. A run that is waiting on you doesn’t hold up the schedule. The next run starts on time in its own chat session and leaves the waiting run, and its approval card, as it is. One agent can therefore have several runs waiting on you at once. Open each one from the runs list and respond to it separately. A failed run increments a failure counter on the agent. Three consecutive failures move the agent to an errored state and stop the schedule, which keeps a broken instruction from running every day indefinitely. The owner is not notified when this happens beyond the red warning icon on the agent’s card and its Scheduled entry. Pausing an agent stops the schedule and keeps both the definition and the runs list. Resuming restarts it on the same cadence and clears the failure counter. The drawer carries the current status, the last error, and the version history of the definition, so a result you cannot reproduce interactively can be traced to the wording it ran under.

Run states

A run shows one of four states while it needs your attention. The agent shows the state of its latest run in the same way on its card on the Scheduled Agents page, its entry under Scheduled in the Agents panel, and the runs list in its drawer. Indicators update while the page is open, without a refresh. The table below lists each state and how it appears. A run that finished with nothing to report is still Ready to view, with a short answer, not a separate state. When more than one applies, the card and entry show only one indicator, in this order: Paused, then Running, Failed, Waiting on you, and finally the New badge. A failed latest run therefore hides the count of unread runs. A paused agent shows a Paused badge on its card and entry in place of any run state. An agent with no runs yet, or whose runs you have all opened, shows its schedule summary on the card and no indicator in the Agents panel. The Run Now button stays on the card in every state. While a run is still running, a new one is refused; see Run Now. A run started with Run Now doesn’t add a card to the Tasks board.

Automatic pauses

DualEntry pauses an agent on its own in two cases, so a schedule nobody is reading doesn’t keep running. A paused agent shows Paused on its card and entry, and its drawer shows an alert that the agent is paused and the reason it was paused.
  • Five unread runs in a row. If the agent’s last five scheduled runs since it was last resumed are all unopened, the next tick pauses the agent instead of running it. A run waiting on you counts as unread until you open it, so an agent whose every run stops on an approval still pauses. Opening any of the agent’s runs resets the count, and so does starting a run with Run Now.
  • The owner loses access. If the agent’s owner leaves the organization or the organization is archived, the agent pauses at its next tick.
To restart an agent paused for unread runs, open a run you want to read and resume the agent from its drawer. The count starts again from zero after you resume.

Run Now

Run Now starts a run immediately, outside the cadence. The button sits on each agent card and in the drawer footer, and it is restricted to organization admins, the same gate as Edit. A manual run takes the same path as a scheduled tick: the same instruction, the owner’s permissions, the same tool set, and its own chat session at the top of the runs list. The difference is in the health counters. A manual run that fails records Last Error on the agent but does not count toward the three consecutive failures that stop the schedule. Run Now works on a paused agent, so you can check an instruction without resuming the schedule. An errored agent has to be resumed first. Two conditions block a manual run:
  • A run is already in progress. The latest run is still running. Wait for it to finish. A run that is waiting on you doesn’t block Run Now; the new run starts in its own session.
  • The agent just ran. Run Now is refused for one minute after a run starts, so a double click cannot stack two runs. Try again after the minute passes.
For how to use Run Now to prove a new agent before it runs unattended, see how to test a scheduled agent.

Read and write boundaries

A scheduled agent is built to read and report. It does not draft records for someone to review, and it cannot write or send through a connector. Unattended runs are barred from a set of actions that an interactive conversation can take. A scheduled agent cannot do any of the following, even when the person who owns it holds those permissions:
  • Create an approval workflow or change a workflow’s status
  • Approve or reject an individual record
  • Archive a record
  • Apply a bulk reclassification or mass-apply a field value
  • Create an anomaly detector, or dismiss or restore an anomaly alert
  • Save or delete a bank rule
  • Start a reconciliation
Those actions require someone present to authorize them. An action that pauses for approval in a conversation pauses a scheduled run too, and the run shows Waiting on you until someone responds. For how approvals, permissions, and the audit trail apply to AI actions generally, see How Approvals and Controls Apply to AI Actions. Connectors are held to the same boundary, and it is enforced rather than left to configuration. An unattended run receives only a connector’s read-only tools. Everything grouped under Interactive Tools on the connector, Gmail’s draft and send tools among them, is removed from the agent’s tool set before the run starts, whatever that tool’s permission is set to. A scheduled agent can search an authorized mailbox; it cannot put a message in one. Those per-tool permissions govern conversations you are present for, which is what the Interactive Tools heading means. Nothing set there widens what a schedule can do, so a scheduled connector workflow only ever takes one shape: the agent assembles the list and a person acts on it. For a worked example of the split, see how to send dunning emails with Accounting Intelligence and Gmail, where the schedule produces the list and the person sends the mail. To prove a new agent’s scope and output path before it runs unattended, see how to test a scheduled agent.

Troubleshooting

Most scheduled-agent problems show up as a failed run, a paused or errored agent, or a missing run. For a failed run, start from the error text on its row in the drawer, also shown as Last Error on the agent. The table below lists common causes and fixes. For checks to run before you rely on a new agent, see how to test a scheduled agent.
Last modified on October 29, 2026