Incident-Driven Configuration

• An agent's rules aren't designed up front; they accumulate from incidents
• There's a buffer between incident and rule: working notes, from which rules get promoted
• Every rule has a history; in a month the config grew by 7 rules, each tied to a failure

The problem

The first instinct when launching an autonomous agent is to design the rules in advance. The team sits down at a whiteboard, lists the situations, and writes an exhaustive guide. By the second week the agent has done three things nobody anticipated: it sends a duplicate message after a network timeout, it mentions a retired project in a report, and it mixes up UTC and local time when calculating a deadline. None of them were on the list. The whiteboard didn't fail out of laziness: the space of incidents is larger than design can cover.

Incidents come from three layers the designer sees only partially: model defaults (new failure modes surface as the context grows), environmental instability (a network connection that worked yesterday drops every third request today), and chat dynamics — that is, people. The result of up-front design looks like this: thirty lines of config that anticipate the obvious, are off in three subtle places, and say nothing about what actually happened.

flowchart TD
    M[Model<br/>defaults] --> I[Incidents]
    E[Environmental<br/>instability] --> I
    C[Chat dynamics:<br/>people] --> I
    D[Up-front<br/>design] -. sees partially .-> I

The move

Rules aren't designed; they accumulate. Every incident — a moment when the agent's behavior caused a problem — goes into working notes. The operator reviews the pattern and promotes a hard rule into the main config. Each case becomes a line of rules.

flowchart LR
    I[Incident] --> N[Working<br/>notes]
    N --> A[Operator reviews<br/>the pattern]
    A --> R[Hard rule<br/>in the config]

Start with a deliberately minimal config: a few rules so obvious you can bet on them. The rest will accumulate.

Between incident and rule there's a buffer, three files of notes:

• Behavioral corrections. The agent did X, it caused a problem, now it does Y.
• Technical failures. A tool or the environment broke; what happened, how it was diagnosed, how it was worked around.
• Missing capabilities. Noticed in operation, useful, but not now.

Not every entry becomes a rule. Promotion happens when a pattern shows up twice. Where it goes depends on the type: behavior (tone, what never to say) goes into the persona file, process (when to act, in what order) into the operating-rules file, a technical workaround into the tools file, scheduling into the scheduler file.

flowchart TD
    N[Entry<br/>in notes] --> Q{Seen<br/>twice?}
    Q -->|no| W[Stays<br/>in the buffer]
    Q -->|yes| T{Rule type}
    T --> P[Behavior:<br/>persona file]
    T --> O[Process:<br/>operating-rules file]
    T --> X[Technical workaround:<br/>tools file]
    T --> S[Scheduling:<br/>scheduler file]

A promoted rule is small — one or two lines — and carries its history as a comment:

After every send, verify that exactly one message went out.
If there's a duplicate, delete it immediately.
(after the triple send on 03/22 during a network timeout)

The history is what lets you audit the config a few months later and remove rules whose cause no longer applies. The config stays short — twenty to forty lines — because the rules are specific: each covers the situation that produced it, not a hypothetical broad class.

flowchart LR
    R[Rule +<br/>incident history] --> A[Audit a few<br/>months later]
    A --> Q{Cause still<br/>applies?}
    Q -->|yes| K[Rule<br/>stays]
    Q -->|no| D[Rule<br/>removed]

Update, September 2026. A short config holds only with regular audits. By June, the main rule files of two agents had grown so large that the platform started truncating them at startup. They were cut by more than half: rules and access boundaries moved into separate files injected when the agent starts, and the main file kept only the role and pointers.

A month of running one agent produced these promotions:

The chat-reading rule grew into its own principle — context before action; the client-status rule became part of tiered autonomy.

Rules also need to be removed. "Monitor weekdays only" was removed the same day "daily, weekends included" was promoted. A config with history lets you do that without fear of breaking something invisible.

A rule becomes a check. Three months in, the loop spread to the infrastructure under the agents. Failures there went unnoticed for days because nobody was watching, and now each such incident yields not just a line of config but an automated check: provider authorization once an hour, duplicate services, stuck jobs. Checks are calibrated by the same loop as rules: after false positives, the "job is stuck" threshold was raised threefold, and the check now fixes a typical connectivity failure on its own, without a human.

flowchart LR
    I[Incident] --> R[Rule<br/>in the config]
    R --> W[Check<br/>in the watchdog]
    W --> F[Self-repair<br/>or alert]
    F -. false positive .-> W
    classDef key stroke:#FF3600,stroke-width:2px
    class W key

Where it breaks

• Promotion without history. A rule landed in the config without a record of the incident. Months later the operator can't tell whether it's still relevant and is afraid to touch it.
• Notes without promotion. Incidents pile up in the buffer and never reach the config; the agent repeats its mistakes. Promotion is operator work on a known cadence — weekly, in our case.
• No operator. In a fully unattended system there's nobody to review and promote. That calls for a different mechanism, or up-front design with an honest acceptance that it under-covers.

Summary

• Minimal start, growth by precedent, every rule tied to a failure.
• Three notes files as a buffer; what repeats makes it into the config.
• A history comment on every rule makes the config auditable and prunable.
• One agent in a month: seven promotions, and the config is still under forty lines.
• An infrastructure incident yields not just a line of config but a watchdog check; checks have their own calibration loop driven by false positives.

© Alex Nikulin. Quote with attribution and a link · LLM version