Writing good conditions for Craig Agents
Connect Rocket AI is in Beta and not yet publicly available.
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 adds what's unique to agents.
How an Agent Decides to Fire
1. A condition is a true/false test, not a question
Each time an agent runs, Craig fetches the data and then answers one thing: is this condition met by the data, 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 literally meet the condition, the answer is "not met" and nothing fires.
This means your condition should read like a statement that is plainly true or false against a number or fact in the data.
| BAD: | "Let me know if the wind is getting more dangerous." (Dangerous is a judgement call that Craig has no threshold to test. |
| GOOD: | "Sustained wind speed at [[station]] is at or above 40 knots." |
A good test: read your condition aloud and ask "could I point at a number in the data and say yes, that's true or no, that's false?" If not, add the threshold.
2. If Craig can't get the data, the answer is "not met"
When the data needed to test a condition is missing or null, Craig does not fire — it records a 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 consequence for you:
Don't build a condition on a field that's often unavailable and expect it to alert. If the forecast field you're testing is frequently absent, the agent will sit quiet. Pick data the tool reliably returns, or add a second condition on a value that's always 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 into one of three states — clear, warning, or triggered — and notifies you on the transition between them. That gives you four notification moments you can write separately.
Agent initiates notification or workflow when:
| Warning Condition Met | Clear → the warning condition becomes true |
| Alert Condition Met | The alert condition becomes true for the first time |
| Alert Condition Ongoing | The alert condition is still true on the next check |
| Condition Cleared | Conditions ease back off (alert or warning no longer met) |
Craig won't re-notify while nothing changes (a warning that stays a warning is silent). "Ongoing" only going message and the alert is genuinely still met.
4. The warning and alert conditions can use completely different data
This is the most useful and least obvious capability. Your warning and alert conditions do not have to watch 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 vs. live observation, whatever each condition calls. So you can pair an early forecast-based heads-up with a hard live-data alert:
Flood watch vs. warning vs. actual 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 leans on the official watch/warning bulletin to give you early notice; the alert ignores bulletins entirely and fires on the real 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 place, two different feeds. Lightning gives you the early warning; a confirmed fire is the alert. e place name and radius) consistent across both so they're genuinely about "the same area" — Craig scopes each tool to the location you name.
5. Set check intervals per state
You choose how often Craig checks, and it can speed up as things escalate. There are three intervals:
- While clear — your baseline (e.g. every hour).
- While in warning — usually tighter (e.g. every 15 minutes).
- While triggered — tightest (e.g. every 5 minutes), to drive "ongoing" updates.
Match the interval to how fast the situation moves. A river level that climbs over hours doesn't need ag storm front does. Frequent checks cost more credits, so don't go faster than the data actually updates.