Goal-oriented automations: persistent state and policy-driven next actions

Problem

Codex Scheduled Tasks currently behave like recurring prompts: each trigger wakes an agent, which must reinterpret the prompt and decide what to do. This is useful for some work, but it is too schedule-centric for many recurring user goals.

A timer should often be only a trigger. The next action should be determined by persistent goal state and policy, and the agent should be invoked only when semantic judgment is actually required.

For example, I want a reading automation:

Goal: keep reading every week

State:
  current_book: Book A
  progress: unfinished

Policy:
  weekday_capacity: 1 book
  weekend_capacity: 2 books
  must_finish_before_next: true

At 08:00 on a weekday, the correct next action is not always “generate or recommend a new book.” If Book A is unfinished, the automation should continue Book A. On weekends, the policy could permit two books only after the active book is complete.

Today this logic has to be reconstructed from natural-language instructions on every run. That makes workflows mechanical, wastes model calls on state inspection or deterministic steps, and makes them harder to trust as they grow beyond a simple reminder.

Requested capability

Make a goal-oriented automation a first-class option alongside recurring prompt tasks:

Trigger
  -> read persistent goal state
  -> apply declarative policy
  -> choose next action
       -> deterministic action/check, when sufficient
       -> agent invocation, only when semantic reasoning is needed
  -> update state and run history

An automation could define or expose:

• goal state: current item, progress, blockers, last completed action, optional user-confirmed state;
• policies/invariants: prerequisites, capacity by day/context, ordering rules, stop/continue conditions;
• action types: deterministic check/command, user notification, or agent task;
• a durable automation-level history/state store that is inspectable and editable by the user.

The UI could start small: let users choose “recurring prompt” or “goal-oriented automation,” then configure a few structured fields such as completion gating and allowed actions. The model remains valuable for open-ended judgment, summaries, recommendations, and ambiguity; it should not need to be the front line for every tick.

Relationship to existing issues

This is complementary to:

• #41247, which asks for plugin-owned deterministic monitors so maintenance work does not require a model call;
• #30515, which identifies recurring-task intent drift and proposes structured phase/invariant context;
• #29184, which asks for selected-thread delivery and cron-to-heartbeat conversion.

Those address execution ownership, temporal intent, and conversation continuity. This request is for the higher-level product abstraction: schedules should advance persistent goals according to state and policy, rather than repeatedly execute an isolated prompt.

Why it matters

It would make automations more dependable, more legible to users, and less expensive. More importantly, it matches how users think about ongoing work: they maintain goals with constraints and progress, not a collection of prompts that happen to run on a clock.

Start with the existing Codex Scheduled Tasks entry point and trace how recurring prompts are triggered, state is read, and run history is recorded. Compare that flow with the requested trigger/state/policy/action model; done would require a defined goal-oriented automation option with inspectable persistent state and deterministic-versus-agent action selection.