Most "AI automation" is really AI scripting: a long prompt that lists the steps an agent should take, in order, and hopes the world cooperates. It usually does, right up until it doesn't — an edge case appears, the script has no branch for it, and the agent improvises. That improvisation is exactly the part you can't audit.
We take the opposite stance. You model the outcome a process must reach, and who owns it. The execution layer figures out the steps. That is the difference between governing an agent and scripting one.
Start from the outcome
A context model is built backwards from the result. You name the outcome — the fact that must become true — and the command that requests it. Everything between them is derived, never hand-written.
Because the outcome is the anchor, the agent is never free to decide what success means. It can only choose how to get there, inside boundaries a human committed to a repository.
What this buys you
- Auditability. Every outcome is a versioned fact with a named owner. When you ask "why did the agent do that?", the answer is a commit, not a vibe.
- Resilience to edge cases. A script breaks at the first branch it didn't anticipate. An outcome model simply hasn't been reached yet — the agent keeps working the gap instead of inventing a new goal.
- Zero-knowledge by default. The model lives in your repository. There is no MMC database holding your business logic.
Human-in-the-loop is not a slogan. Every skill is reviewed, committed and versioned by a person. AI executes within those boundaries — it does not set them.
Where to go next
This is the first of what will be a running series on outcome-driven context modeling — event modeling, CQRS, and the practical mechanics of governing agents. If you want the architecture behind the idea, start with how it works.