Writing good conditions for Craig Agents
Already read "Common AI Mistakes to avoid when writing Craig Prompts"? Every rule there still applies — Agents use the same data tools and the same [[placeholder]] message format. This guide covers what's unique to Agents.
How an Agent Decides to Fire
1. A condition is a true/false question with a specific threshold
Each time an Agent runs, Craig fetches the relevant data and answers one question: is this condition met, yes or no? There's no "kind of," no "getting close." Craig is explicitly told not to guess at proximity or trends — if the data doesn't clearly meet the condition, the answer is "not met" and nothing fires.
Write your condition as a plain-language question that can be answered with a definitive yes or no against a specific value in the data.
| AVOID | "Let me know if the wind is getting more dangerous." (Dangerous has no threshold Craig can test.) |
| BETTER | "Sustained wind speed at [[station]] is at or above 40 knots." |
A useful test: read your condition aloud and ask — could I point at a number in the data and answer this with a clear yes or no? If not, add a specific threshold.
2. If Craig can't get the data, the condition is treated as not met
When the data needed to test a condition is missing or unavailable, Craig does not fire. It records the limitation and treats the condition as clear. This is a deliberate fail-safe — better a quiet miss than a false alarm on invented data — but it has a practical consequence:
Don't build a condition on a field that's frequently absent and expect it to alert reliably. If the value you're testing is often unavailable, the Agent will sit quiet. Choose data the tool reliably returns, or add a second condition on a value that's consistently present.
3. Two tiers: Warning and Alert
An agent has two condition slots:
- Alert condition (required) — the main thing you're watching for.
- Warning condition (optional) — an earlier, looser heads-up.
Craig evaluates the data against these conditions and notifies you when the state changes. That gives you up to four notification moments, each configurable separately:
| Warning Condition Met | The Agent moves from Clear to Warning for the first time. |
| Alert Condition Met | The Alert Condition becomes true for the first time. |
| Alert Condition Ongoing | The Alert Condition is still met on the next check. |
| Condition Cleared | Conditions ease and the Agent returns to Clear. |
Craig won't re-notify while nothing changes — a Warning that stays a Warning is silent. The Ongoing notification fires only when the Alert Condition is genuinely still met on a subsequent check.
4. Warning and Alert conditions can watch completely different data
This is the most useful and least obvious capability. Your Warning and Alert conditions don't have to monitor the same measurement, or even the same tool. When an Agent has both conditions, Craig gathers whatever data is needed to test each one — different tools, a wider radius, forecast data versus live observations, whatever each condition calls for.
This lets you pair an early forecast-based heads-up with a hard live-data alert:
Flood watch versus live river level
| Warning condition: | "A flood watch or flood warning is in effect for the [[region]] area." |
| Alert condition: | "The river level at [[station]] is at or above 4.5 metres." (live gauge reading) |
The Warning draws on the official watch or warning bulletin for early notice. The Alert ignores bulletins entirely and fires on the actual measured level. They're watching two different things on purpose.
Two hazards in the same area
| Warning condition: | "Lightning has been detected within 20 km of [[location]] ." |
| Alert condition: | "An active wildfire is reported within 20 km of [[location]] ." |
Same location, two different data sources. Lightning provides early warning; a confirmed fire is the alert. Keep the location name and radius consistent across both conditions so Craig scopes each tool to the same area.
5. Set check intervals to match how fast conditions change
You control how often Craig checks, and intervals can tighten as conditions escalate. There are three intervals to configure:
- While Clear — your baseline check frequency (for example, every hour).
- While in Warning — typically tighter (for example, every 15 minutes).
- While in Alert — tightest, to drive timely Ongoing notifications (for example, every 5 minutes).
Match the interval to how quickly the situation can develop. A river level that rises over hours doesn't need the same check frequency as a fast-moving storm front. More frequent checks use more credits — don't check faster than the underlying data actually updates.