القائمة
When the Retainer cog should delegate to the scheduler, how to brief it, what to expect back, and how to verify the result. Read before dispatching to agent_scheduler.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
How the observer specialist works in Retainer — role, expected inputs, output shape, quality bar, common pitfalls. The observer reads this at the start of every dispatch.
How the Retainer scheduler specialist works — role, expected inputs, output shape, common pitfalls. The scheduler reads this at the start of every dispatch.
When the Retainer cog should delegate to the observer, how to brief it, what to expect back, and how to verify the result. Observer is the knowledge gateway — recent (hot index) and deep (full archive). Read before dispatching to agent_observer.
Decision framework for when and how to delegate work to Retainer's specialist agents. Covers the two specialists in this reference cut (observer, scheduler) plus the cog's direct tools.
How dispatching to specialist agents works in Retainer's current shape — the agent_<name> tool shape, what the reply envelope looks like, how errors propagate. Read with `delegation-strategy` (which covers when to delegate).
Recovery patterns in Retainer's current shape for tool errors, agent failures, and cycle abandonment — when to retry, when to narrow, when to escalate. Read after seeing an unexpected error or when planning a multi-step task that might fail partway.
استنادا إلى تصنيف SOC المهني
| name | agents-using-scheduler |
| description | When the Retainer cog should delegate to the scheduler, how to brief it, what to expect back, and how to verify the result. Read before dispatching to agent_scheduler. |
| agents | cognitive |
The scheduler specialist manages autonomous-cycle scheduling.
You reach it via agent_scheduler. Scheduled prompts fire on
their own; the cog runs them with SourceAutonomous so the
policy gate's strict path applies (no operator-typing
demotions).
agent_taskmaster already auto-schedules
a reminder when it has a due:<RFC3339> modification — the
taskmaster bridges to the scheduler internally. You don't
need to ALSO call agent_scheduler for that case; the
bridge has it covered.agent_observer (cycle history), not
the scheduler.agent_taskmaster. The scheduler is for autonomous fires;
the taskmaster is for trackable items.Send a clear instruction containing:
Examples:
schedule_job: confirmation with the assigned ID,
cron/fire-time, and the prompt that will run.list_jobs: a structured list (one block per job)
sorted by next-fire ascending. Pass it through to the
operator verbatim — don't paraphrase.cancel_job: a one-line confirmation with the ID.inspect_job: full record (cron, last/next fire,
fired count, prompt body).If you dispatched schedule_job and the reply confirms a
job ID, trust it. The scheduler service persists every
operation to JSONL; jobs survive restart.
If you later want to know whether a scheduled cycle actually
fired, that's an agent_observer question — recall_recent
shows past cycles regardless of source.
Each agent_scheduler dispatch is one full agent cycle. For
common operations (one cron, one operator) it's negligible.
The scheduled cycles themselves are normal cog cycles; their
LLM cost is whatever their prompt provokes.