Should AI agents have working hours and operational schedules?

Treat the schedule as a service contract

Calling an agent's policy “working hours” can obscure what must actually be designed. A sound operating contract specifies at least five independent things:

• Availability: when the agent can accept an event, request, or batch.
• Initiation authority: when it may start a workflow without a new human instruction.
• Action authority: which effects it may produce, such as sending a reply, changing a record, issuing a refund, or disabling an account.
• Supervision and escalation: who receives an exception, by which channel, with what expected response time.
• Recovery: what happens to queued and partially completed work after an outage, maintenance window, budget stop, or missed run.

This contract is more precise than a single on/off switch. For example, an executive assistant can accept calendar changes at any time, draft a reply at any time, and send a non-urgent message only during the recipient's declared quiet-hours policy. A security monitor can run continually, automatically isolate a clearly compromised test credential, and page an on-call responder only after a severity threshold is met. The agent is technically available in both cases, but its authority differs by action and time.

Four operating modes

Most useful systems combine these modes. An event-driven support agent may operate 24/7, but place non-urgent issues in a scheduled daytime response queue. A finance agent may schedule nightly matching and variance detection, then route exceptions into a human-supervised queue. A monitoring agent may run continuously while its recovery actions are limited to a reversible playbook.

Start with user-facing objectives

Choose schedules from user needs and measurable service requirements. A service-level objective (SLO) is a target for the reliability users experience. Google’s SRE guidance recommends choosing explicit service-level indicators (SLIs), such as the proportion of requests that succeed, finish below a latency threshold, or produce sufficiently fresh data, then using them to make tradeoffs. Google SRE on implementing SLOs This makes it possible to decide whether overnight coverage is valuable rather than merely impressive.

For an agent, write the objective in the user’s terms. “Respond to every ticket” is weak because it can reward an immediate but useless message. Better measures include the percentage of urgent tickets acknowledged within five minutes, the percentage of standard tickets with a correct first classification within one business hour, the percentage of approved reports delivered before a stated deadline, or the percentage of reconciliation records processed correctly by the next business day. Pipeline services often need freshness, correctness, and coverage measures in addition to availability. Google SRE’s pipeline SLI examples

Decide whether the service needs to operate around the clock, then set a separate reliability target. Running 24/7 does not mean promising 100 percent successful operation; higher reliability also has a cost. Google SRE on reliability targets and error budgets Instead, define separate objectives for each class of work. A customer may accept a standard billing explanation tomorrow but not a locked account during an active purchase. A batch report may tolerate a planned two-hour window if its freshness objective is still met.

A small objective set

Keep the first version measurable and limited. A practical set is:

The numbers are examples, not universal targets. They become useful only after the product owner, operations team, and people accountable for the outcome agree that the target is both valuable and feasible. A schedule should then be tested against the actual arrival pattern, capacity, and dependencies.

Design the queue before choosing the hours

An unattended agent is still a distributed system. When arrivals exceed the ability to process them, a schedule that simply keeps accepting work turns a manageable delay into a large, expensive, and possibly unsafe backlog. Queued requests consume resources and add latency; when a service is overloaded, early rejection, load shedding, degradation, and bounded queues can protect the useful work that remains. Google SRE on queue management and overload

Give every workflow a work class, maximum backlog, expiry time, and behavior at capacity. For instance, an urgent account-security report may preempt a newsletter draft. A daily summary that cannot be delivered before its freshness deadline may be discarded and regenerated rather than sent late. A reimbursement request can be acknowledged and held, but not retried indefinitely. If a task invokes paid models or third-party APIs, its queue limit must also consider token, tool-call, and vendor-rate budgets.

Backpressure and rate limits

Backpressure means slowing, deferring, rejecting, or simplifying work before a downstream system fails. It is not a failure of an agent to tell a user that it will respond later. It is often more honest than generating a response that relies on an unavailable or throttled dependency.

• Assign a priority and deadline at intake. Do not allow a bulk import to compete equally with a security alert.
• Use bounded queues, per-tenant quotas, and concurrency limits. Export queue age and the number of expired or rejected jobs as operational metrics.
• Treat retries as a controlled policy. Require idempotency keys for effectful work, cap attempts, use backoff with randomness where appropriate, and stop retrying after the task’s useful deadline.
• Reserve capacity for critical traffic. If a tool is rate limited, fall back to a cheaper safe action such as acknowledging receipt, collecting missing context, or queuing a review.
• Pause new discretionary work when a daily spend or tool-call budget is reached. Preserve enough budget for monitoring, recovery, and approved urgent work.

Retries deserve special care. Under overload, retries can amplify traffic and prolong the incident, especially when requests have already waited past the caller’s deadline. Google SRE on cascading failures An agent should therefore record whether an action was completed before retrying it, distinguish a temporary dependency outage from a permanent policy failure, and send one coherent status update rather than a stream of repeated messages.

Batch windows and dependency maintenance

Scheduled work needs explicit overlap and recovery rules. If a nightly run may take 90 minutes, a 60-minute cadence must not silently create concurrent executions. Scheduling platforms expose this choice directly. Kubernetes CronJobs, for example, support allowing, forbidding, or replacing overlapping runs, and let a job schedule name a time zone. Kubernetes CronJob API reference The technical mechanism varies, but the operational question is universal: should a late run finish, be skipped, or be replaced?

Maintain a calendar of planned vendor, database, model, and identity-provider maintenance. During a dependency window, the agent should enter a known degraded mode such as read-only lookup, draft-only output, or queued intake. It should not diagnose every expected dependency error as a new incident. After the window, run a health check, drain queues in priority order, verify data freshness and duplicate protection, and notify affected users only if their promised outcome was actually missed.

Quiet hours and time zones

Quiet hours are usually a notification policy, not an availability policy. The agent can receive a request, prepare the result, and retain an audit record during quiet hours. It should defer a non-urgent push notification, chat message, email, or calendar invitation until the recipient’s chosen delivery window. This is especially important for assistants that operate across customer time zones, where a fixed headquarters schedule makes a considerate system intrusive for someone else.

Store a recipient’s time zone and quiet-hours preference separately from the agent’s server time. Use an IANA time-zone identifier rather than a fixed UTC offset so daylight-saving changes are handled correctly. If no preference is known, choose a conservative default, make it visible, and offer a simple override. A contract should also state what breaks quiet hours: imminent fraud, an active service outage, a time-sensitive approval about to expire, or an emergency that the recipient has explicitly opted to receive.

Avoid an apparent emergency created by the agent itself. A routine weekly report that was generated late is normally not a reason to wake someone. Escalation should depend on severity, confidence, affected scope, and the remaining time to mitigate harm. Messages should state which condition triggered the exception and provide a concise action, so an on-call person does not have to reconstruct the agent’s reasoning at 03:00.

Human supervision and handoffs

Human oversight is a design property, not a button labelled “approve.” Before assigning a schedule, name the role that can approve, override, pause, investigate, and communicate about the agent’s actions. NIST’s AI Risk Management Framework calls for documented roles and responsibilities for human-AI configurations and post-deployment monitoring that includes appeal, override, incident response, recovery, and change management. NIST AI RMF Core

If no qualified person is reachable outside business hours, limit the actions the agent can take during that period. It can intake the case, preserve context, make a reversible containment change covered by a playbook, and create a handoff for the next staffed window. It should not make an irreversible judgment merely because it can call an API at night.

An effective handoff packet contains the event time and time zone, user or account context, the agent’s classification and confidence, actions already taken, links to evidence, the decision required, the deadline, and a clear owner. Human on-call practice uses written handoffs, explicit escalation paths, and response playbooks because availability without those details produces noisy pages and slow recovery. Google SRE on on-call operations

Approval boundaries

Use a risk-based approval matrix rather than a single rule for all agent outputs.

Organization policy, contracts, and applicable rules may require stronger controls than this general matrix. In financial, legal, medical, employment, or safety-sensitive workflows, have the accountable compliance or domain owner define the authority boundary and the evidence required for release.

Decision rules by use case

Customer support

Run intake and basic self-service continuously when customers reasonably expect access outside local business hours. Let the agent authenticate where appropriate, classify the issue, retrieve approved help content, acknowledge urgent requests, and route security or service-outage signals immediately. Do not use a fake 24/7 promise for cases that need specialist judgment. If no specialist is staffed, say when the case will be reviewed, preserve the customer’s place in the queue, and avoid repeated status messages.

For routine proactive support, use the customer’s time zone and quiet hours. A useful default is to send a non-urgent resolution during local business hours, while allowing the customer to pull the result from a portal at any time. Escalate outside quiet hours only for a defined set of events, such as suspected account takeover, an active outage affecting the customer, or a deadline they have opted to receive. Measure acknowledgement and meaningful resolution separately so the schedule does not optimize for an empty automatic reply.

Finance operations

Schedule low-risk preparation work around data availability and business cutoffs, not around a chatbot’s availability. An agent can continuously ingest statements or invoices, run matching and anomaly checks overnight, and create a traceable proposal during a batch window. Set a completion deadline that leaves time for review before the business or settlement cutoff. If a bank feed, accounting system, or approval service is in maintenance, hold the work in a visible queue rather than guessing from partial data.

Keep release authority separate from preparation. Before a payment, ledger posting, external filing, or material customer commitment, require the authorized human or the organization’s formally approved control. Outside staffed hours, the agent may flag a suspected duplicate payment or prepare an emergency packet, but it should not resolve ambiguity by moving money. A finance schedule is successful when it improves timely, auditable preparation while preserving the controls needed for actual execution.

Overnight monitoring

Use continuous, lightweight monitoring when delay increases harm. The agent can collect health signals, correlate alerts, deduplicate repeats, check a runbook’s preconditions, and execute a narrowly preapproved reversible containment step. Its operating target should emphasize detection time, false-page rate, and time to a useful handoff, not the number of alerts produced.

Page a person only when an alert crosses a documented severity and confidence threshold, affects a stated service objective, or requires authority beyond the playbook. Route lower-severity anomalies to a morning review with evidence and trend context. After a dependency outage or agent downtime, backfill monitoring data where possible, mark gaps rather than inventing a clean history, replay missed checks that remain useful, and verify that alerts have not become duplicated before resuming normal paging.

Example weekly schedule with exceptions

This hypothetical example is for a B2B operations agent that handles support intake, nightly reconciliation preparation, and service monitoring. Times are deliberately different by function. The schedule does not assume one global human workday.

The exceptions are the part that makes the schedule trustworthy. A P1 security incident overrides normal quiet hours but still follows the incident playbook. A customer who opts out of emergency notifications is never contacted through that channel. A vendor maintenance notice suppresses expected dependency alerts and pauses affected jobs. A budget threshold can stop nonessential model calls while leaving monitoring and emergency intake alive. A missed batch is replayed only after checking that it will not duplicate an already completed effect.

Recovery after downtime

Every schedule needs a recovery policy because timers, workers, models, and dependencies will eventually be unavailable. First, record the gap: when did the agent last complete healthy work, which inputs arrived during the gap, and which promises might have been missed? Next, protect against duplicate effects before replaying anything. An email may be safe to regenerate if it has not been sent; a payment, calendar change, or ticket closure requires durable evidence of its prior state.

Then recover in priority order. Process expiring and safety-critical work first, then work with customer-visible deadlines, then ordinary backlog, then discretionary summaries. Re-evaluate old tasks before acting because their context or deadline may no longer be valid. A 12-hour-old fraud alert may still require escalation; a 12-hour-old “welcome” message may be better discarded. Report any breach of a service objective through the normal incident or customer-communication path rather than quietly catching up.

Test this procedure. Simulate a missed scheduled run, a full queue, a rate-limited model provider, an unavailable approval system, and a daylight-saving transition. The result should be a documented state transition, not an operator improvising at midnight. A schedule is mature when recovery is observable, bounded, and safe even when the agent cannot immediately reach a human.

A practical implementation checklist

1. List the agent’s events and effects. Separate observation, drafting, communication, record changes, financial actions, and containment actions.
2. Classify each effect by reversibility, impact, required evidence, and accountable owner.
3. Define a small set of user-facing objectives with an explicit measurement window and time zone.
4. Choose an operating mode for every work class: event-driven, scheduled, continuously available, human-supervised, or a combination.
5. Set priority, maximum queue age, capacity, cost budget, rate limit behavior, retry policy, and idempotency requirement for each class.
6. Configure quiet hours per recipient and write the exact conditions that can override them.
7. Publish approval rules, escalation contacts, incident severity levels, maintenance calendars, and handoff templates.
8. Define overlap, missed-run, dependency-outage, and restart behavior for every scheduled workflow.
9. Instrument queue age, dropped work, duplicate prevention, latency, freshness, approval delay, cost, and false escalations.
10. Review the data after a few operating cycles and change the schedule when evidence shows that it is either interrupting people needlessly or missing a real service promise.

Common failure modes