Restricting an AI agent to business hours is one of the cheapest reliability wins available. Most agent incidents are not catastrophic; they are awkward. An automated follow-up arriving at 3 a.m. looks like spam. A re-categorisation pushed during a planned outage looks like a bug. A cleanup loop firing on a weekend nobody is watching turns a small mistake into Monday's emergency. The schedule is the cheap fix.

Not every agent should be restricted. Read-only digests want to run overnight. The rule below is simple: anything that writes externally or that needs human supervision should respect business hours. Anything that produces output for the morning can run any time.

Why restrict at all

Two reasons. First, supervision: if the agent does something wrong, you want a human awake to notice. Detection time at 2 a.m. is hours; at 11 a.m. it is minutes. The schedule does not eliminate incidents, but it shrinks the recovery window.

Second, optics. Customer-facing actions arriving at 3 a.m. look like a robot regardless of how warm the copy reads. The schedule is the cheap signal that a human is on the other side of the conversation, even when an agent did the work.

For the broader supervision framing, see how to monitor agent activity and how to limit agent actions.

Read-only vs write-side

The split is binary and useful:

An agent that mixes both follows the stricter rule: business hours. If you find yourself wanting overnight runs from a write-side agent, the agent has been over-scoped and probably should be split into a read-only digest plus a separate write-side agent.

Set the schedule

The minimum schedule is two windows: weekdays and weekends. Most teams pick weekdays 09:00 to 18:00, weekends paused. That's a starting default; tune for your business. Customer-support agents may run later; recruiting agents may run earlier; agents that interact with international customers may need a wider window.

Express the schedule explicitly in the agent configuration, not in the prompt. Schedules belong to the runtime; prompts are about behaviour. Mixing the two means the agent sometimes runs because the runtime allowed it but produces no output because the prompt said "it's after hours". Confusing for everyone, especially auditors.

Mon Tue Wed Thu Fri Sat 00:00 09:00 18:00 24:00
Default schedule: weekdays 09:00 to 18:00 active, weekends in blackout. Tune for your business.

Handle time zones

The agent should run in the recipient's timezone, not the operator's. A US team running an agent that emails customers in Europe should configure Europe business hours, not "9 to 5 our time", or the customer receives messages at midnight local.

For internal agents, the timezone is the recipient team's. For multi-region agents, split into per-region agent variants rather than averaging timezones. Averaging is what produces the "agent ran at 4 a.m. for half my customers" outcome.

Use IANA zone names (America/New_York, Asia/Kolkata, Europe/Berlin), not UTC offsets. Offsets break across daylight-saving transitions and your weekend agent runs at 4 p.m. on the wrong weekend twice a year.

Blackout windows

Blackouts are paused windows on top of the schedule. Common cases:

Blackouts are the cheap way to avoid the "we knew that was happening, why didn't we pause the agent" post-mortem. The cost of a missed run is tiny. The cost of a wrong run during a known-bad window is large.

What happens to triggers outside the window

Three options when a trigger arrives outside the active window: queue, defer, or reject. Most platforms default to queue, which is correct for the majority of cases. The agent processes the queue when the window opens.

Defer is queue plus deduplication: if multiple identical triggers arrive overnight, the agent processes one. Useful for "send the morning summary" agents where you only want one summary even if the trigger fired three times.

Reject is fine for low-priority or speculative triggers. Don't reject anything that represents a real customer interaction, because the customer does not see the queue and assumes silence is a bug.

For the underlying topic of how agents get triggered in the first place, see how to write prompts for recurring agents.

When 24/7 is the right answer

Some agents should run continuously regardless of the schedule rule. Three patterns:

The pattern that connects them: the agent's actions are either expected by the recipient or invisible. Schedule the agents whose actions are unexpected and visible. Free the rest.

Rotational coverage and on-call

For teams that need broader hours than one timezone supports, the answer is rotation, not a 24/7 schedule on every agent. A US team and an EU team can each own the agent during their respective business hours, with a hand-off note in the audit log when ownership rotates. The agent is operating under continuous human supervision, but no single human is on call all the time.

Rotation works only if the audit trail is good enough that the receiving owner can pick up immediately. The handover ceremony is one line: "rotation start, no open incidents, schedule unchanged". Clear handovers are how rotational coverage avoids the "the agent did something while I was asleep" complaint.

Common mistakes

Frequently asked questions

Why would I restrict an AI agent to business hours?

Two reasons. First, supervision: if something goes wrong, you want a human awake to catch it. Second, optics: customer-facing actions sent at 3 a.m. look automated in a way that erodes trust. Internal read-only agents can run any time. Anything that writes to a customer should respect the calendar.

What is a blackout window for an AI agent?

A blackout window is a period when the agent is paused regardless of schedule. Common examples: weekends, public holidays, the week of a major release. The agent queues incoming triggers and processes them when the window ends. Use blackouts to avoid sending follow-ups during a known incident or to give the team a recovery day.

How do I handle time zones when restricting an AI agent?

Set the schedule in the timezone of the recipient, not the operator. An agent that emails customers in Europe should respect Europe business hours. The owner timezone matters only for alerting and rollback. Most platforms accept an explicit IANA zone like America/New_York or Asia/Kolkata; avoid 'UTC offset' shortcuts that break around DST.

Should I restrict read-only AI agents to business hours?

Generally no. Read-only agents (digests, summaries, monitoring) deliver value when the human reads the output, which is often morning. Run those overnight so the digest is waiting. The restriction is for write-side agents whose actions are visible to others or have a meaningful blast radius.

What happens when an AI agent is triggered outside its allowed hours?

The trigger is queued, deferred, or rejected depending on platform. Queue is usually correct: the agent runs as soon as the window opens. Rejection is fine for low-priority triggers. Don't run the agent silently in the wrong window because the trigger looked urgent; the schedule exists because urgency at 2 a.m. is rarely real.

Three takeaways before you close this tab

Sources