Rules and instructions
A rule is a check in code: it runs before the action, and nothing the model decides can talk it out of running. An instruction is language handed to the model — a standing instruction, a behaviour setting, a speaking guide — and it is followed the way a person follows a briefing. Write a hard requirement as an instruction and you have bought detection, not prevention.
Which is which in Connect#
| Control | Kind | What happens if the model disagrees |
|---|---|---|
| Autonomy mode and scope | Rule | The outbound is held or refused; the model's view is irrelevant |
| Suppression, unsubscribe, do-not-contact | Rule | The send does not happen. The Assistant cannot even clear the entry |
| Daily allowance | Rule | Work is held, not dropped, and the read cursor does not advance |
| Send evidence | Rule | sent requires a provider acknowledgement; uncertain is a real state, not a rounding |
| Follow-up duplicate protection | Rule | The same *when* for the same person is a duplicate and does not become a second commitment |
| Standing instruction | Instruction | Usually honoured; not guaranteed by construction |
| Behaviour on Connect Rules | Instruction | Shapes tone, length and approach |
| Speaking guide on a call | Instruction | Shapes delivery; it cannot stop a sentence being said |
Both are legitimate. The mistake is not using instructions — it is using one where the consequence of a miss is something you cannot accept.
The worked example: not inventing prices#
Connect does not invent commercial terms. On the turn-based path that is enforced: a price, SLA or warranty that Knowledge does not support is refused and escalated rather than improvised, and each sentence is checked before it goes.
On the realtime voice path the same rule can only live in the model's instructions, because the model is speaking directly to the caller and there is no point between the thought and the sound at which code can stand. So a breach is detected rather than prevented: price_spoken counts the lines the voice priced, through the same expression the carrier path checks each sentence with, so the two paths agree on what a price is.
Writing instructions that work#
Instructions are not free, and length is the first cost. On the voice path, instructions of about 7,500 characters produced a first token in 1.2–1.8 seconds; about 9,600 characters made it 2.3–3.4 seconds. Every paragraph you add is paid for on every call.
State the behaviour, not the reasoning behind it.
Result Shorter, and less to misread. A briefing that argues with itself gets followed inconsistently.
Put durable directions in a standing instruction or memory rather than repeating them in conversations.
Result The direction applies to work that happens when nobody is watching, which is where it matters.
Set it at the narrowest scope that is true — one contact, one mailbox, one channel.
Result Narrowest-first resolution honours it for that case without distorting everything else.
For anything you cannot accept being missed, find the rule instead.
Result Autonomy, suppression and the allowance are checks, not requests.
How this goes wrong#
- A compliance requirement written as guidance
- It will be followed most of the time. Most of the time is not a compliance posture.
- Contradictory instructions
- Two directions that cannot both be satisfied resolve unpredictably. Narrowest scope wins for memory; two instructions at the same scope simply conflict.
- A rule assumed where there is none
- "It would never do that" is a belief about a model unless you can name the check. If you cannot name it, it is an instruction.
- Growing the briefing to fix behaviour
- Each addition costs latency on every call and dilutes the lines that were working. Prefer removing a conflicting line to adding a clarifying one.
- Expecting an instruction to bind the Assistant's rights
- Its rights are code: no pricing, no clearing a do-not-contact entry. No wording loosens or tightens those.
Questions#
Can I add my own rules?
You can set the controls that are rules — autonomy per channel and scope, suppression and do-not-contact entries, and the plan's limits — and you can write standing instructions. What you cannot do is author new enforced checks; a rule is code, and adding one is a product change rather than a setting.
Is an instruction ever enough on its own?
Often, yes. Tone, length, when to offer a call-back, how to greet a returning customer — these have no catastrophic failure and are exactly what instructions are for. Reserve the demand for enforcement for outcomes you would have to explain to somebody.
How do I tell which one a given control is?
Ask what happens if the model concludes the opposite. If the action still does not happen, it is a rule. If the answer is "it probably would not, but", it is an instruction — and this page's table is the current list.