Saltar al contenido principal

Órdenes permanentes

Las órdenes permanentes otorgan a tu agente autoridad operativa permanente para programas definidos. En lugar de dar instrucciones de tareas individuales cada vez, defines programas con un alcance, desencadenantes y reglas de escalación claros, y el agente se ejecuta de forma autónoma dentro de esos límites. Esta es la diferencia entre decirle a tu asistente “envía el informe semanal” todos los viernes frente a otorgar autoridad permanente: “Tú eres responsable del informe semanal. Compílalo todos los viernes, envíalo y solo escala si algo parece estar mal”.

¿Por qué usar órdenes permanentes?

Sin órdenes permanentes:
  • Debes indicarle al agente cada tarea
  • El agente permanece inactivo entre solicitudes
  • El trabajo rutinario se olvida o se retrasa
  • Te conviertes en el cuello de botella
Con órdenes permanentes:
  • El agente se ejecuta de forma autónoma dentro de límites definidos
  • El trabajo rutinario ocurre según lo programado sin necesidad de indicaciones
  • Solo intervienes para excepciones y aprobaciones
  • El agente aprovecha el tiempo de inactividad de forma productiva

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 hacer referencia a él desde AGENTS.md. Cada programa especifica:
  1. Alcance: lo que el agente está autorizado a hacer
  2. Desencadenantes: cuándo ejecutarse (programación, evento o condición)
  3. Puertas de aprobación: qué requiere autorización humana antes de actuar
  4. Reglas de escalación: cuándo detenerse y pedir ayuda
El agente carga estas instrucciones en cada sesión mediante los archivos bootstrap 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 cron jobs para la aplicación basada en tiempo.
Coloca las órdenes permanentes en AGENTS.md para garantizar que se carguen en cada sesión. El bootstrap 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 + Cron Jobs

Las órdenes permanentes definen qué está autorizado a hacer el agente. Los Cron Jobs 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
La indicación del cron job debe hacer referencia a la orden permanente en lugar de duplicarla:
openclaw cron add \
  --name daily-inbox-triage \
  --cron "0 8 * * 1-5" \
  --tz America/New_York \
  --timeout-seconds 300 \
  --announce \
  --channel bluebubbles \
  --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 eventos)

## 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     |

El patrón Ejecutar-Verificar-Informar

Las órdenes permanentes funcionan mejor cuando se combinan con una disciplina estricta de ejecución. Cada tarea en una orden permanente debe seguir este ciclo:
  1. Ejecutar: realizar el trabajo real (no solo reconocer la instrucción)
  2. Verificar: confirmar que el resultado sea correcto (el archivo existe, el mensaje se entregó, los datos se analizaron)
  3. 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.
Este patrón evita el modo de fallo más común del agente: reconocer una tarea sin completarla.

Arquitectura de varios programas

Para agentes que gestionan múltiples ámbitos, organiza las órdenes permanentes como programas separados con límites claros:
# Standing Orders

## 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]
Cada programa debe tener:
  • Su propia cadencia de activación (semanal, mensual, impulsada por eventos, continua)
  • Sus propias puertas 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 comienza otro)

Prácticas recomendadas

Haz esto

  • Comienza con una autoridad limitada y amplíala a medida que crezca la confianza
  • Define puertas de aprobación explícitas para acciones de alto riesgo
  • Incluye secciones de “Qué NO hacer”: los límites importan tanto como los permisos
  • Combínalas con cron jobs para una ejecución confiable basada en tiempo
  • Revisa semanalmente los registros del agente para verificar que se estén siguiendo las órdenes permanentes
  • Actualiza las órdenes permanentes a medida que evolucionen tus necesidades: son documentos vivos

Evita esto

  • Otorgar una autoridad amplia desde el primer día (“haz lo que creas que es mejor”)
  • Omitir las reglas de escalación: todo programa necesita una cláusula de “cuándo detenerse y preguntar”
  • Suponer que el agente recordará instrucciones verbales: pon todo en el archivo
  • Mezclar asuntos en un solo programa: programas separados para ámbitos separados
  • Olvidar aplicar la ejecución con cron jobs: las órdenes permanentes sin desencadenantes se convierten en sugerencias

Relacionado

  • Automatización y tareas: todos los mecanismos de automatización de un vistazo
  • Cron Jobs: aplicación de programación para órdenes permanentes
  • Hooks: scripts impulsados por eventos para eventos del ciclo de vida del agente
  • Webhooks: desencadenantes de eventos HTTP entrantes
  • Espacio de trabajo del agente: dónde viven las órdenes permanentes, incluida la lista completa de archivos bootstrap inyectados automáticamente (AGENTS.md, SOUL.md, etc.)