Two things get sold under the same banner and behave nothing alike. One is a rule: when a deal reaches Proposal, create a task for the owner. The other is goal-directed software: here is a goal, here are some tools, work out the steps. Buying the second when you needed the first is the most expensive mistake in this category, and it is easy to make because the demo for both is a lead moving across a screen.
The distinction is not “is there a model involved”. It is whether the sequence of steps was decided in advance by a person, or at run time by software.
What a deterministic rule actually is
A deterministic rule is an automation whose output is fully determined by its input: a named trigger, a condition that is true or false, and a fixed action. Run it twice on the same record and you get the same result twice. Change the rule and you can predict what changes before you save it.
That predictability is not a small virtue. It means a rep who asks “why did this lead go to me” gets an answer, not a theory. It means you can reason about the rule in a meeting without running it. And it means the rule does not silently behave differently next quarter because a vendor shipped a new model version.
The cost profile matters too. A rule evaluating a condition against rows you already store costs a database query. There is no per-run meter on it. That is why, in Oneop, automation has no paid tier at all: workflows on record events, scheduled runs, branching, waits and approvals are on every plan, because no automation route in the product checks your plan. Only steps that call a model draw on metered credits.
What an AI agent actually is
An AI agent is software given a goal and a set of tools, which decides at run time which tools to use and in what order. It is not a bigger rule. It is a different control model: you constrain the space it may act in, rather than specifying the path it takes through that space.
That flexibility buys exactly one thing that rules cannot do, and it is worth naming precisely. An agent can read unstructured language and turn it into a decision. A free-text enquiry, a rambling email thread, a supplier’s PDF, a company description written by a marketing department: a rule has no way to parse any of it. A model does.
Everything else people want from agents is either a rule with better marketing, or a rule the buyer had not finished writing down yet. The separation between the two is covered in more depth in AI agents vs AI chatbots, which draws the same line one layer up the stack.
Mapping sales tasks to the right mechanism
The useful question is not “which is better”. It is “does this task have a complete written specification”. If it does, a rule is strictly better, because it is cheaper, reproducible and explainable. If the task starts with reading language, a model earns its place.
Task by task, and the mechanism each one needs
| Sales task | Right mechanism | Why |
|---|---|---|
| Route a new lead to an owner | Deterministic rule | Territory, round-robin and named-owner routing are complete specifications. Nothing is ambiguous. |
| Score a lead | Deterministic rule | A points model you can read. Oneop stores every score with the factor breakdown that produced it, so a score is arguable. |
| Enforce that a deal cannot reach a stage without a quote | Deterministic rule | A gate is a refusal, not a judgement. Oneop returns a 422 listing exactly what is missing. |
| Create the onboarding project when a deal is won | Deterministic rule | One trigger, one action, no interpretation. |
| Follow up on a set cadence until a reply arrives | Deterministic rule | A sequence with step delays and exit signals. Stopping on a reply is a state change, not an inference. |
Where an AI step earns its place
Everything above is a rule because the decision is already written down. The tasks below are not, and that is the only reason they warrant a model.
| Sales task | Right mechanism | Why |
|---|---|---|
| Classify a free-text inbound enquiry | AI step inside a rule | The model reads the text and returns variables. Your conditions branch on them. |
| Summarise a long thread before a call | AI, suggestion only | Output goes to a person, not to a record. |
| Draft a personalised opener from a messy company profile | AI, human-reviewed | Language in, language out, with a person on the send. |
| Chase overdue invoices end to end | AI agent, with approval | Multi-step, reads documents, touches money. Gate it. |
| Decide a discount | Neither | This is a judgement call about money. Keep it human, as argued in when not to automate. |
Read the right-hand column of that table and the pattern is plain. The rule rows outnumber the agent rows, and the agent rows all involve reading language or crossing several records. That ratio is roughly what a real sales operation looks like.
The failure case: an agent doing a rule’s job
Here is the specific way this goes wrong, and it is common enough to be predictable.
A team buys an AI sales agent to handle lead routing, because the pitch said it would learn the right owner. The agent reads each new lead, reasons about which rep should get it, and assigns. For three weeks it looks impressive.
Then a rep disputes an assignment. There is no rule to point at, only a reasoning trace for that one run. The trace explains what the agent thought on Tuesday; it does not tell you what the agent will do on Friday with a similar lead, because nothing guarantees the two runs agree. Two leads from the same company, submitted an hour apart, go to two different reps. Nobody can say that is a bug, because nobody wrote down what correct was.
The second failure arrives with the invoice. Every routing decision was a model call. Routing is the highest-volume decision in a sales operation, and it was the one task in the whole list with a complete written specification. The team paid per execution for an output a five-line rule produces free and identically every time.
The repair is not “use less AI”. It is to write the routing rule down, which takes an afternoon, and spend the model budget on the enquiry text nobody can parse.
How Oneop separates the two, deliberately
In Oneop the two mechanisms are two different parts of the product, and the boundary is enforced rather than stylistic.
Lead scoring, deal scoring, routing and stage gates in the CRM are points-based and deterministic, and the product says so in the interface. Change a rule and you can predict the result. A score is stored with its factor breakdown attached.
AI agents are constrained before they run rather than corrected afterwards. An agent draws its tools from a fixed catalog, and a tool the model names that is not in its subset is refused rather than improvised. Four ceilings bound every run: reasoning steps, tokens, wall-clock time, and write actions counted across the whole run. Hitting any ceiling ends the run as escalated with the trace kept, so a person picks up where it stopped rather than the agent inventing an ending. Nine distinct exit reasons are stored, so a billing stop and a provider outage are different answers.
One property is worth knowing before you plan around agents: in Oneop an agent run starts when a person starts it. There is no scheduler behind agents and no event that fires them. If you want something that genuinely begins on its own when a deal closes or a ticket goes quiet, that is the automation engine, which has real event triggers and a real scheduler. Two mechanisms, two jobs, and the product does not blur them.
Where a model does act on a record, the autonomy model decides whether it suggests, asks, or acts, and that choice is made before the run rather than discovered during it. Autonomy levels covers how that setting behaves in practice.
The test to apply before you build either one
Write the task down as a rule. Not a summary of the rule, the whole thing, including the edge cases.
If you finish, build the rule. You now have a specification, and handing a specification to a model is paying a per-run fee for an answer you already have.
If you cannot finish because a step begins with “read what they wrote and work out what they mean”, that step is the model’s job. Put a model there, keep the rest as rules, and let the model return variables your own conditions branch on. The thing you audit stays your flow. The model informs a decision; your rules make it.