Trigger
An event or schedule makes the automation eligible to run.
Research status. Scheduled maintenance and background jobs already support my knowledge systems. Ontology-backed operational automation is still a prototype and research direction.
Useful work should not depend on remembering to start it
A second brain decays quietly. Links break. Sources become stale. Drafts remain unfinished. A useful system should notice some of these conditions without waiting for me to ask the perfect question.
I already use scheduled maintenance and background work for parts of this problem. The deeper lesson is that automation needs more structure than a recurring prompt.
An automation should say what wakes it up, which conditions must hold, what effect it may attempt, and what happens when it fails.
The shape is simple
Condition
Current state determines whether work is actually needed.
Effect
A function runs, an action executes, or a bounded effect creates a review task or notification.
For this essay series, a weekly trigger could inspect published articles. The condition could find sources older than a defined freshness window. The effect could create a review task with the affected claims and citations.
A function performs reusable logic and returns a result. An action is the governed contract for changing state. An automation decides when either should run.
That is safer than telling an agent to “keep my website current”. The automation knows what to inspect and what output it is allowed to create. It does not silently rewrite an article.
Automation is policy expressed as running software
Every automation contains a policy, whether or not it is written down. A threshold says when something deserves attention. A retry rule says which failures are temporary. An escalation path says when a human should take over.
Making those choices explicit improves both operations and writing. I can explain why an automation ran, which object triggered it, which condition passed, which action it proposed, and where it stopped.
Palantir's public documentation describes Automate in similar terms: conditions are evaluated continuously or on a schedule, then effects may run actions, functions, AIP Logic functions, or notifications. The transferable idea is the separation between when and what.
Failure is part of the design
A background process will eventually meet stale state, missing permission, a network timeout, or an ambiguous object. “Try again” is only one possible response.
A bounded automation should have a retry limit, an idempotency rule, and an escalation path. It should avoid producing the same task twice. It should record partial failure. If the underlying object changed, it should re-evaluate instead of forcing through the old plan.
The safest effect is often a proposal or notification rather than a direct mutation. Automation can keep the work moving while a human keeps authority over the consequential step.
The agent still has to choose the right capability
Triggers and effects solve repetition. They do not solve discovery. When an unfamiliar request arrives, the agent still needs to decide whether it should search documents, inspect live objects, or find a reusable function.
Putting every question through one search box hides those differences. The next essay introduces the three searches I want the operational brain to expose.
Continue the series
- Previous: Give the Brain Verbs
- Next: Three Ways to Ask
- Related: Two Brains, One Operator