Autonomy engine

This page covers the governance mechanics of Curia’s autonomy engine — how the score controls what skills can execute, how blocked actions route to the approval workflow, and how the score adjusts automatically over time. For the conceptual overview and calibration guidance, see Autonomy.

​

How action_risk connects to autonomy

Every skill declares an action_risk level in its manifest. This field establishes the minimum autonomy score at which that skill can be invoked.

​

Hard execution gates

The execution layer enforces action_risk thresholds at invocation time — not just through prompt guidance, but as a hard gate in the runtime. When the live autonomy score is below a skill’s declared floor, the skill is blocked before it runs. A blocked invocation:

1. Emits an autonomy.skill_blocked audit event (skill name, required score, actual score)
2. Returns an advisory failure to the coordinator describing what score is needed
3. Triggers an approval request so you can decide whether to allow the specific action

OutboundGateway.send() has an independent gate: direct sends are blocked when the score is below 70. Drafts are always available as the fallback — Curia can still compose and save a draft even when it cannot send.

​

Principal bypass

When you send a direct instruction to Curia (via Signal, email, CLI, or any channel), the task is marked as principal-originated. Both execution gates — the action_risk floor check and the outbound send gate — are skipped for the duration of that task. The rationale: the autonomy score governs autonomous behavior (scheduled jobs, agent-initiated actions). When you explicitly tell Curia to do something, you are the authorization. A low autonomy score should not prevent you from issuing a direct command. This bypass applies only to tasks that trace back to a message from you. Scheduled jobs, agent-to-agent delegations, and other autonomous work are still subject to the full gate logic regardless of autonomy score. The bypass is logged at every invocation — you can see principal-originated gate skips in the audit log.

​

Approval requests

When a skill is blocked by a hard gate, Curia does not silently fail. Instead, it creates an approval request and notifies you so you can decide whether to allow the specific action. See Approval workflow for the full picture — how requests are created, how to approve or deny them, and how the lifecycle (expiry, daily digest) works.

​

Score history

Every change to the autonomy score is written to an append-only history record in Postgres. No entry is ever updated or deleted. The history records:

• The new score and band
• The previous score
• Who made the change (ceo or system for automatic adjustments)
• An optional reason you provided
• The timestamp

You can view the full history in Settings → Autonomy or by asking Curia directly: “Show me my autonomy score history.” The get-autonomy skill also surfaces the trend direction (improving / declining / stable), lastSetBy, and the count of scored actions.

​

Automatic score adjustment

The autonomy scoring pass runs as part of the dream engine and evaluates Curia’s recent actions to nudge the score based on performance:

• Competence (45%) — task success rate, accuracy of information retrieved, follow-through on commitments
• Commitment (35%) — reliability on recurring tasks, consistency with stated preferences
• Compatibility (20%) — alignment with your communication style and decision patterns

Automatic adjustments require a minimum of 30 scored actions before any change applies, use time-decay weighting so recent behavior matters more, and are capped at ±5 per pass. A 7-day CEO cooldown prevents the system from immediately overriding a manual score you just set. All automatic changes are written to the audit record — you can always see exactly what changed and why.