Product model
What is an operational run?
CaltAI is organized around operational runs. This is what separates it from generic assistants and fixed automations.
A run starts with a business trigger
A run begins when something meaningful happens. For post-sales onboarding, the trigger might be a deal marked closed-won, a payment received, or a handoff from sales to delivery.
For lead lifecycle, the trigger might be a new inbound lead, positive reply, or missed follow-up.
A run has a defined outcome
A task has a finish line. A run has an outcome.
For post-sales onboarding, the outcome is not simply creating a checklist. The outcome is getting the client to first value.
- Client intake completed
- Kickoff scheduled
- Required assets received
- Internal team has context
- Approvals routed
- Client reaches first value
A run has state
Operational work changes over time. CaltAI needs to know what stage the run is in, what is blocked, who owns the next action, and what should happen next.
This state is what makes the system operational rather than just conversational.
A run has policies
Not every action should be treated the same. Some messages can be low-risk. Some need approval. Some should be escalated. Some should never be automated.
CaltAI uses workflow-specific rules so the run stays inside the boundaries your team defines.