Las órdenes permanentes otorgan a tu agente autoridad operativa permanente para programas definidos. En lugar de indicarle al agente cada tarea, defines programas con alcance, activadores y reglas de escalamiento claros, y el agente ejecuta de forma autónoma dentro de esos límites: “Tú eres responsable del informe semanal. Compílalo todos los viernes, envíalo y escala solo si algo parece estar mal.”
Por qué usar órdenes permanentes
Sin órdenes permanentes: le indicas al agente cada tarea, el trabajo rutinario se olvida o se retrasa, y tú te conviertes en el cuello de botella.
Con órdenes permanentes: el agente ejecuta de forma autónoma dentro de límites definidos, el trabajo rutinario ocurre según lo programado, y tú solo intervienes para excepciones y aprobaciones.
Cómo funcionan
Las órdenes permanentes se definen en los archivos de tu espacio de trabajo del agente. El enfoque recomendado es incluirlas directamente en AGENTS.md (que se inyecta automáticamente en cada sesión) para que el agente siempre las tenga en contexto. Para configuraciones más grandes, también puedes colocarlas en un archivo dedicado como standing-orders.md y referenciarlo desde AGENTS.md.
Cada programa especifica:
- Alcance - lo que el agente está autorizado a hacer
- Activadores - cuándo ejecutar (programación, evento o condición)
- Puntos de aprobación - qué requiere autorización humana antes de actuar
- Reglas de escalamiento - cuándo detenerse y pedir ayuda
El agente carga estas instrucciones en cada sesión mediante los archivos de arranque del espacio de trabajo (consulta Espacio de trabajo del agente para ver la lista completa de archivos inyectados automáticamente) y las ejecuta, combinadas con trabajos Cron para la ejecución basada en tiempo.
Pon las órdenes permanentes en AGENTS.md para garantizar que se carguen en cada sesión. El arranque del espacio de trabajo inyecta automáticamente AGENTS.md, SOUL.md, TOOLS.md, IDENTITY.md, USER.md, HEARTBEAT.md, BOOTSTRAP.md y MEMORY.md, pero no archivos arbitrarios en subdirectorios.
Anatomía de una orden permanente
## Program: Weekly Status Report
**Authority:** Compile data, generate report, deliver to stakeholders
**Trigger:** Every Friday at 4 PM (enforced via cron job)
**Approval gate:** None for standard reports. Flag anomalies for human review.
**Escalation:** If data source is unavailable or metrics look unusual (>2σ from norm)
### Execution steps
1. Pull metrics from configured sources
2. Compare to prior week and targets
3. Generate report in Reports/weekly/YYYY-MM-DD.md
4. Deliver summary via configured channel
5. Log completion to Agent/Logs/
### What NOT to do
- Do not send reports to external parties
- Do not modify source data
- Do not skip delivery if metrics look bad - report accurately
Órdenes permanentes más trabajos Cron
Las órdenes permanentes definen qué está autorizado a hacer el agente. Los trabajos Cron definen cuándo ocurre. Funcionan juntos:
Standing Order: "You own the daily inbox triage"
↓
Cron Job (8 AM daily): "Execute inbox triage per standing orders"
↓
Agent: Reads standing orders → executes steps → reports results
openclaw cron add \
--name daily-inbox-triage \
--cron "0 8 * * 1-5" \
--tz America/New_York \
--timeout-seconds 300 \
--announce \
--channel imessage \
--to "+1XXXXXXXXXX" \
--message "Execute daily inbox triage per standing orders. Check mail for new alerts. Parse, categorize, and persist each item. Report summary to owner. Escalate unknowns."
Ejemplos
Ejemplo 1: contenido y redes sociales (ciclo semanal)
## Program: Content & Social Media
**Authority:** Draft content, schedule posts, compile engagement reports
**Approval gate:** All posts require owner review for first 30 days, then standing approval
**Trigger:** Weekly cycle (Monday review → mid-week drafts → Friday brief)
### Weekly cycle
- **Monday:** Review platform metrics and audience engagement
- **Tuesday-Thursday:** Draft social posts, create blog content
- **Friday:** Compile weekly marketing brief → deliver to owner
### Content rules
- Voice must match the brand (see SOUL.md or brand voice guide)
- Never identify as AI in public-facing content
- Include metrics when available
- Focus on value to audience, not self-promotion
Ejemplo 2: operaciones financieras (activadas por evento)
## Program: Financial Processing
**Authority:** Process transaction data, generate reports, send summaries
**Approval gate:** None for analysis. Recommendations require owner approval.
**Trigger:** New data file detected OR scheduled monthly cycle
### When new data arrives
1. Detect new file in designated input directory
2. Parse and categorize all transactions
3. Compare against budget targets
4. Flag: unusual items, threshold breaches, new recurring charges
5. Generate report in designated output directory
6. Deliver summary to owner via configured channel
### Escalation rules
- Single item > $500: immediate alert
- Category > budget by 20%: flag in report
- Unrecognizable transaction: ask owner for categorization
- Failed processing after 2 retries: report failure, do not guess
Ejemplo 3: supervisión y alertas (continuo)
## Program: System Monitoring
**Authority:** Check system health, restart services, send alerts
**Approval gate:** Restart services automatically. Escalate if restart fails twice.
**Trigger:** Every heartbeat cycle
### Checks
- Service health endpoints responding
- Disk space above threshold
- Pending tasks not stale (>24 hours)
- Delivery channels operational
### Response matrix
| Condition | Action | Escalate? |
| ---------------- | ------------------------ | ------------------------ |
| Service down | Restart automatically | Only if restart fails 2x |
| Disk space < 10% | Alert owner | Yes |
| Stale task > 24h | Remind owner | No |
| Channel offline | Log and retry next cycle | If offline > 2 hours |
- Ejecutar - Hacer el trabajo real (no solo confirmar la instrucción)
- Verificar - Confirmar que el resultado es correcto (el archivo existe, el mensaje se entregó, los datos se analizaron)
- Informar - Decirle al propietario qué se hizo y qué se verificó
### Execution rules
- Every task follows Execute-Verify-Report. No exceptions.
- "I'll do that" is not execution. Do it, then report.
- "Done" without verification is not acceptable. Prove it.
- If execution fails: retry once with adjusted approach.
- If still fails: report failure with diagnosis. Never silently fail.
- Never retry indefinitely - 3 attempts max, then escalate.
Arquitectura multiprograma
Para agentes que gestionan varias áreas, organiza las órdenes permanentes como programas separados con límites claros:
## Program 1: [Domain A] (Weekly)
...
## Program 2: [Domain B] (Monthly + On-Demand)
...
## Program 3: [Domain C] (As-Needed)
...
## Escalation Rules (All Programs)
- [Common escalation criteria]
- [Approval gates that apply across programs]
- Su propia cadencia de activación (semanal, mensual, basada en eventos, continua)
- Sus propios puntos de aprobación (algunos programas necesitan más supervisión que otros)
- Límites claros (el agente debe saber dónde termina un programa y empieza otro)
Prácticas recomendadas
Hazlo
- Empieza con autoridad limitada y amplíala a medida que se construya confianza
- Define puntos de aprobación explícitos para acciones de alto riesgo
- Incluye secciones de “Qué NO hacer”: los límites importan tanto como los permisos
- Combina con trabajos Cron para una ejecución confiable basada en tiempo
- Revisa los registros del agente semanalmente para verificar que se sigan las órdenes permanentes
- Actualiza las órdenes permanentes a medida que evolucionen tus necesidades: son documentos vivos
Evita
- Otorgar autoridad amplia desde el primer día (“haz lo que creas que sea mejor”)
- Omitir reglas de escalamiento: cada programa necesita una cláusula de “cuándo detenerse y preguntar”
- Suponer que el agente recordará instrucciones verbales: ponlo todo en el archivo
- Mezclar áreas en un solo programa: programas separados para dominios separados
- Olvidar aplicarlas con trabajos Cron: las órdenes permanentes sin activadores se convierten en sugerencias
Relacionado
- Automatización: todos los mecanismos de automatización de un vistazo.
- Trabajos Cron: ejecución programada para órdenes permanentes.
- Hooks: scripts basados en eventos para eventos del ciclo de vida del agente.
- Webhooks: activadores de eventos HTTP entrantes.
- Espacio de trabajo del agente: dónde viven las órdenes permanentes, incluida la lista completa de archivos de arranque inyectados automáticamente (
AGENTS.md, SOUL.md, etc.).
