Kicker directives and memory
Kicker, AlertKick’s SRE agent, triages alerts, opens and summarises incidents, drafts after-action reports, and verifies changes. Two things make it behave like a colleague who has been on the team a while rather than a model seeing your fleet for the first time: directives you give it, and memory it keeps. Both are under Admin, then Agent Memory, and both need the SRE agent, which is included on Business and the trial.
Directives
Section titled “Directives”A directive is an instruction in your words plus the deterministic effect it compiles to. The text is shown to the model as context on every matching decision; the compiled effect is enforced by AlertKick whether or not the model agrees. That split is deliberate: “always page the payments channel for anything on pay-1” is too important to leave to a prompt.
| Part | Example |
|---|---|
| Text | ”pay-1 and pay-2 are the card processors; treat anything on them as urgent and tell #payments-oncall” |
| Scope | The whole workspace, one host, a host group (hosts sharing a security profile), or one rule |
| Compiled effect | Notify immediately; a severity floor of high; a channel override of slack:#payments-oncall |
Compiled effects available: notify immediately, severity floor, channel override (a Slack channel or another channel), audience (a specific user), and suppress. A directive can carry an expiry - none, 24 hours, or 7 days - so “ignore disk alerts on build-3 while we rebuild it” switches itself off.
Directives come from three places: the Agent Memory page (active as soon as you save), a chat with Kicker in the dashboard, or a Slack thread. Directives Kicker proposes from a conversation arrive as pending confirmation and do nothing until you confirm them on the page; the model never grants itself standing instructions. Each directive shows how many times it has matched and when.
Memory
Section titled “Memory”Kicker writes to its memory as it works:
| Kind | Written when |
|---|---|
| Episode | A triage concluded, an incident was summarised, a change was verified - what happened and what was decided |
| Digest | A periodic roll-up of episodes for a host or the workspace |
| Host note | A fact about one host, from Kicker or from you |
| Correction | You told Kicker a conclusion was wrong |
The memory browser lists entries by kind and scope with what they refer to (the alert, incident, or change), and a memory card per host and for the workspace summarises what Kicker currently believes. Delete any entry; a deleted memory is superseded rather than silently forgotten, so the audit trail stays intact.
You can add to it. A host note (“this box runs a legacy cron that spikes CPU at 02:00; expected”) or a correction (“the login from 203.0.113.7 you called suspicious is our bastion”) is read on the next relevant decision. Corrections are the fastest way to stop a repeated false positive without writing an ignore rule.
Baselines
Section titled “Baselines”Alongside memory, Kicker keeps a rolling 30-day baseline per rule and per host: how often each detection normally fires, at what hours, from which processes. Triage compares a new event against the baseline, which is why the same event can be benign on a build server and suspicious on a database host. Baselines are visible on the Agent Memory page and rebuild themselves; there is nothing to configure.
Skills
Section titled “Skills”The Skills section lists the procedures Kicker can run during triage - gathering evidence, checking a service’s topology, reading a runbook - and lets you reset any to its default. Custom skills are edited here for workspaces that want to add their own.
What Kicker records about itself
Section titled “What Kicker records about itself”Every action is counted hourly by kind and host - triages that escalated, deep analyses, diagnostics run, incidents opened, resolved, and summarised, reports drafted, changes verified - with sampled examples, so the AI usage on the billing page and the activity view on the Agent Memory page reconcile with what it actually did.
Next steps
Section titled “Next steps”- AI triage and Kicker for the triage loop and quotas
- Incidents and after-action reports
- Services and topology for the blast-radius context Kicker reads