Directive SLA Enforcement: Governing Your Agent Fleet

When the operator surfaced the Q2 OKR review for the fleet, the directive_completion_rate was 45.5%. Sixteen active SLA breaches. Directives issued weeks earlier that had been acknowledged, logged, and never finished.

This is not a failure state. This is what governance looks like before enforcement exists. The system was doing exactly what it was designed to do — which was nothing, after the acknowledgment was logged.

The Governance Theater Problem

Every agent fleet operator eventually encounters this pattern: a directive is issued, the receiving agent responds with "acknowledged" or "I'll work on X," and the record shows the directive as active. Weeks pass. The directive remains active. The agent has moved on to other tasks.

The problem is structural, not behavioral. The agent was never required to produce anything beyond an acknowledgment. There was no SLA. There was no completion criterion. There was no enforcement loop. The directive system was measuring acknowledgments and calling them completions.

Completion vs. Acknowledgment

The distinction seems obvious but is easy to blur in practice. Here is the operational definition:

Acknowledgment: the agent confirms it received and understood the directive. "I'll work on the budget ceiling implementation." This is a statement of intent. It is not a deliverable.

Completion: the stated deliverable exists, was tested, and the agent provides a verifiable artifact that can be independently confirmed. "Budget ceiling implementation merged as PR #412. Test suite passes. Demo available at endpoint X."

The enforcement loop can only work if completion criteria are defined at directive creation time. A directive with no completion criteria cannot be meaningfully completed — the agent has no target, so any response qualifies. This is the ambiguous criteria failure mode in the stale directive taxonomy.

The Enforcement Loop

A working SLA enforcement loop has five stages:

Stage 1 — Issue with criteria The directive is created with an explicit deliverable (a PR, a report, a log record, a working endpoint) and an SLA window. Non-urgent directives carry a 48-hour SLA. Urgent carry 4 hours.

Stage 2 — SLA timer From the moment of issuance, a timer runs. The directive record holds the issued_at timestamp, the sla_hours, and a computed breach_at field.

Stage 3 — Midpoint status poll At 50% of the SLA window, the system queries the agent for a status update. This is not a check-in — it is a data collection step. The response goes into the directive record.

Stage 4 — Breach event When now > breach_at and the completion artifact has not been verified, the system fires a breach event. The breach event is structured: directive ID, agent ID, issued timestamp, SLA window, elapsed time, last known status.

Stage 5 — Escalation path The breach event routes to the morning feed. The operator sees it before touching a terminal. The escalation decision (re-issue, extend SLA, triage as dead) is made at triage time, not at breach time.

Triaging Stale Directives

When the Q2 triage ran against the fleet's stale directive backlog, the oldest had been active for 455 hours. One hour shy of nineteen days.

A 455-hour directive is not necessarily dead. Before deciding action, classify it:

Genuinely dead: the agent that owned the directive is decommissioned or was a one-time invocation. The directive should be archived, not re-issued.

Agent offline: the directive was issued to an agent that subsequently went down and was not restarted. The completion artifact may already exist on disk somewhere. Verify before re-issuing.

Scope creep: the directive started as a bounded task and expanded through conversation into something the agent cannot complete without further clarification. The directive needs to be split and re-issued as smaller units with explicit criteria.

Ambiguous criteria: the original directive had no clear completion target. The agent acknowledged and stopped because it did not know when it was done. The directive needs to be re-issued with explicit deliverables.

The triage classification changes the action. Archiving a genuinely dead directive is correct. Re-issuing it is wasted work. Re-issuing a scope creep directive as-is will produce another stale entry in 455 hours.

OKR Integration

The power of directive_completion_rate as a metric is that it can govern itself when wired into the OKR stack.

When completion rate drops below a threshold — say 60% — it surfaces in the morning feed as an OKR health event. The health event is not an alert that something is broken. It is a signal that governance pressure needs to increase: more frequent status polls, tighter SLA windows, or a triage sprint to clear the backlog.

This is the difference between monitoring and governance. Monitoring watches the system. Governance changes behavior. A directive completion rate that sits in the morning feed and triggers escalation when it drops is governance. A dashboard that shows the same number but requires a human to decide what to do with it is monitoring.

The Morning Feed-First Rule

Before opening a terminal on a day that involves fleet work, read the morning feed. Every breach event, every OKR health signal, every stale directive notification.

This rule exists because the instinct when starting a session is to open a terminal and start fixing things. The problem is that the things you fix first are the things you happen to look at first — not necessarily the highest priority.

The morning feed-first rule inserts a triage step before the work begins. Sixteen breach events get ranked. The four highest-priority directives get assigned first. The remaining twelve get re-scheduled or triaged as dead.

Without this rule, the session starts with whatever is in front of you. The 455-hour stale directive sits unnoticed while you fix something that is less important but more immediately visible.

Why Governance Is Not Monitoring

This distinction comes up repeatedly when operators build their first enforcement loops. The governance theater problem persists in many fleets because the operator built monitoring (a completion rate dashboard) and assumed it would produce governance behavior (agents completing directives on time).

Monitoring without enforcement changes nothing. An agent that knows its completion rate is being tracked but faces no consequence for acknowledgment-without-delivery will continue to acknowledge and not deliver.

The enforcement loop — SLA timer, breach event, escalation path, triage decision, re-issue or archive — is what changes behavior. Not because the agent "feels pressure." Because the breach event creates a human decision point that allocates resources to clearing the backlog.

Start with one directive type. Wire the SLA timer and the breach event. Run it for two weeks. Review the breach events every morning. Triage one stale directive per session. At the end of two weeks, you will have a completion rate and a process for improving it. That is governance.