Notebook · Events & capabilities
The event-driven
operating model.
I start with the event: something has changed. Which roles should care, what context do they need, and what should happen next?
The distinction
From a task sequence to a responsive system.
One way to model a workflow
- Human starts task
- ↓
- Workflow executes
- ↓
- Output produced
- ↓
- Human decides what happens next
Each handoff is an explicit step.
An event-driven view
- Event occurs
- ↓
- Relevant context is refreshed
- ↓
- Capabilities react
- ↓
- New events are produced
- ↓
- Other capabilities consume them
- ↺
- Actions produce the next events
Routine steps advance; judgment gates remain.
Outputs become inputs
One event ripples through the system.
A customer call ends: customer.meeting.completed. In this example, a meeting summary becomes an input to several capabilities. Each interprets the event within its role’s context and may produce a proposal or another event.
CRM Intelligence
Stage confidence, next steps, stakeholder map, and close-date risk. The account’s working context can be updated from the meeting evidence.
opportunity.context.updatedCoaching Intelligence
“You identified technical pain but not executive priority. The next meeting should include the VP of Finance.”
seller.coaching.generatedAccount Intelligence
“A new initiative was discovered: reducing operational cost. Potential expansion into operations.”
account.strategy.updatedOrchestrator · routes relevant events
“Your highest-value action today is scheduling an executive alignment meeting. Here's why.”
This is a design example, not a claim that a model can reliably infer the right action on its own. The question I want the system to help answer is: “Given what changed, what deserves attention?”
One meeting, several interested capabilities
- Account contextUpdate commitments, stakeholders, and open questions.
- Seller coachingPrepare feedback for the next conversation.
- Account strategyEvaluate a possible expansion signal.
Snapshots vs. streaming
Context changes between scheduled reviews.
Email arrives. A meeting happens. A competitor is mentioned. A champion changes jobs. Pricing updates. I want those changes to trigger a review of the relevant context, rather than wait for the next scheduled update.
Under the hood
A governed event ontology, capability graph & reasoning layer.
The event doesn't contain the workflow. The capability decides how to interpret it, the LLM reasons, and the harness routes the action.
The harness, not the model, decides
IF confidence > .85 AND opportunity_value > $100k THEN create VP outreach approval task
In this illustrative rule, the model can recommend outreach, but the harness creates an approval task. The numbers are examples, not validated thresholds. Authority belongs in explicit system rules; a confidence score alone is not enough.
Reasoning proposes; the harness checks authority
- Event and contextA capability receives the relevant change and evidence.
- RecommendationThe model proposes an action with supporting context.
- Deterministic boundarySystem rules check scope, permission, and required approval.
- Authorized actionExecute only within authority; otherwise request a decision.
Record the outcome as a new event, with enough identity to tolerate replay.
The missing abstraction
The capability graph connects the pieces.
A company already runs a living system. I use the event-driven view to describe how the signals, responsibilities, and procedures within it relate.
I would judge this architecture by its behavior: whether relevant events arrive, decisions use the right evidence, actions stay within authority, and people can understand and correct failures.