Set Per Schedule Approval Rules in One Config Object

Set Per Schedule Approval Rules in One Config Object

You manage agents that run on fixed schedules yet must still require human approval for actions that touch production systems. The Agent Command Center stores every per schedule approval rule inside one versioned config object so changes remain traceable and every sensitive step routes to the approvals inbox.

Key takeaways

• Per schedule approval rules live inside a single agent config object
• Each schedule window can carry its own autonomy level and approval threshold
• Every real-world action waits for explicit human review
• Execution logs, token usage and cost estimates stream per run
• Config changes support rollback without data loss

Embed Per Schedule Approval Rules in the Agent Config Object

Open the config object for the target agent and add a schedules array. Each entry specifies the cron pattern, the autonomy level, and the approval rule that applies during that window. The structure keeps all settings versioned so prior runs can be audited against the exact rule set that governed them. Store the full object on your agent runtime backend to ensure consistent enforcement across restarts.

• Define the cron expression for the schedule window
• Assign an autonomy level such as read-only or tool-calling
• Set the approval threshold for actions above a stated token count
• Specify the model parameters active during the window
• Record the human reviewer group that receives notifications
• Include a fallback rule for unmatched times

Choose Autonomy Levels for Each Schedule Window

Different times of day carry different risk profiles. A nightly maintenance schedule can allow higher autonomy while a business-hours schedule stays restricted. Store these choices directly in the config object so the agent runtime backend applies the correct level without manual intervention. Teams often adjust levels after reviewing past token usage patterns.

• Low autonomy: agent proposes actions only
• Medium autonomy: agent executes read-only tool calls
• High autonomy: agent may call tools after approval
• Time-bound autonomy: level changes at schedule boundaries
• Default fallback: lowest autonomy when no schedule matches
• Audit autonomy changes quarterly for compliance

Route Sensitive Actions Through the Approvals Inbox

Any action that touches external systems must pass through the approvals inbox. The rule inside the config object determines which actions trigger review and which reviewer group receives the request. Human approval remains mandatory before the agent runtime backend proceeds. This approach aligns with established practices for controlled automation.

• Sensitive database writes always require approval
• External API calls above a token limit enter the inbox
• File system changes route to designated reviewers
• Email or notification actions need explicit sign-off
• Rollback of a prior action also requires approval
• Log every inbox decision with timestamp and approver

See how other teams evaluate approval workflows for regulated agents in the article on regulated approval workflows. For broader context on managing AI risks, review the NIST AI Risk Management Framework.

Compare Rule Configurations Across Schedules

A side-by-side view helps teams verify that per schedule approval rules do not conflict. The table below shows sample settings stored in one config object.

Review the differences between a single config object and isolated settings in the comparison of single config object versus isolated settings.

Track Execution Logs and Token Usage per Run

Live visibility shows logs, intermediate outputs, token usage and cost estimates for every execution. When a schedule window ends, the Agent Command Center records which approval rule applied and whether the run completed inside the stated limits. This data supports accurate forecasting of future token consumption.

• Stream logs to the execution history view
• Capture token counts before and after each tool call
• Surface cost estimates against the current schedule budget
• Flag runs that exceed the configured approval threshold
• Export logs for compliance audits
• Compare usage across versions of the config object

Maintain Version History for Config Changes

Every edit to per schedule approval rules creates a new version of the config object. Rollback restores a prior version without affecting stored execution data. This practice supports safe iteration while preserving audit trails. Reference the OWASP guidance on LLM agent risks when defining change review processes.

• Tag each version with a change description
• Compare diffs between consecutive versions
• Revert to an earlier rule set in one step
• Preserve token usage records across rollbacks
• Require human approval for version promotion
• Notify reviewers of pending promotions

Learn the rollback process in the guide to rollback agent config changes without data loss.

Secure Your Agent Runtime Backend with Permissions

Permissions attached to the config object limit which users can edit per schedule approval rules. Only authorized roles may raise autonomy levels or widen approval thresholds. The agent runtime backend enforces these permissions at execution time. Additional controls can reference external standards such as those in the NIST SP 800-53 access control guidelines.

• Restrict config edit rights to platform administrators
• Require two-person approval for high-autonomy schedules
• Log every permission change with timestamp and actor
• Enforce separation of duties between reviewers and editors
• Audit permission assignments quarterly

Set Execution Timeouts Tied to Schedule Windows

Execution timeouts prevent runaway processes during any schedule window. Add a timeout field to each entry in the schedules array of the config object. The agent runtime backend terminates the run and logs the event if the limit is reached. Pair timeouts with per schedule approval rules so high-autonomy windows receive tighter bounds.

• Set shorter timeouts for business-hour schedules
• Allow longer windows for overnight maintenance
• Trigger an approvals inbox item on timeout
• Record actual runtime versus configured limit
• Adjust timeouts after analyzing token usage trends
• Test timeout behavior in staging before production

Test Rules Before Production Deployment

Run scheduled agents in a staging environment that mirrors the production agent runtime backend. Verify that per schedule approval rules trigger the approvals inbox and that logs capture the correct token usage. Only after successful tests promote the config object version.

• Clone the production config object to staging
• Execute each schedule window with sample workloads
• Confirm inbox routing for every sensitive action
• Measure token usage against stated thresholds
• Document test results before promotion
• Simulate overlapping schedule scenarios

Conclusion

Per schedule approval rules belong inside one versioned config object so every autonomous run stays under human control. Apply the following next steps to implement the pattern.

• Review your current schedules and list the required approval thresholds
• Add the schedules array to the agent config object
• Assign reviewer groups for each window
• Test the rules in a non-production runtime
• Monitor the first live executions through the approvals inbox
• Schedule a quarterly review of version history and token usage

FAQ

How do per schedule approval rules differ from global rules?

Per schedule approval rules apply only during the matching cron window. Global rules serve as the default when no schedule matches.

Can one config object hold rules for multiple agents?

Yes. A shared config object can reference several agents while keeping per schedule approval rules distinct for each.

What happens if an action exceeds the approval threshold?

The action stops and enters the approvals inbox. Execution resumes only after explicit human approval.

How are token usage and cost estimates reported?

The Agent Command Center streams token counts and running cost estimates for each schedule window in real time.

Where can I compare approval rule options?

The approval rules comparison article shows feature differences across control planes.