How do you set rules an AI agent must follow?
You set rules in ordinary sentences, then those rules are checked before every action rather than hoped for in the model's memory. A useful rule can refuse or hold work. It must never silently wave something through. You should also be able to read back what a rule actually stopped.
Why should a rule be checked before every action, not remembered?
A language model can recall a preference and still ignore it when the next request is urgent, vague or long. Memory is a story of what you said. A gate is a test that runs on the proposed step itself. If posting, paying, following a wallet or moving a robot is about to happen, the test should fire on that step, not on a summary of last week's chat.
That is why phrases such as never post after eight, always ask before paying, or pause the follow with a sentence belong in a contract the system evaluates, not in a prompt you hope it will keep. GROX treats trading limits, wallet follows and robot contracts this way: size, stop, daily loss cap, allowed moves, speed cap, battery floor and time limit sit in one place and are applied for everyone who asks. A stop never waits for anything.
What should a rule be allowed to do when it fires?
A rule that only warns is a suggestion. A rule that can refuse or hold is a control. Holding is right when the action might be valid after you confirm it. Refusing is right when the action is outside the contract no matter who asked. Waving through is never right, because the point of the rule is that the model does not get a vote.
Practice modes and confirmations exist for the same reason. A strategy can run on past prices or with no money at risk before anything settles. Copying a public wallet still asks unless you have pre-approved that size. Social posts to networks reached through a scheduling service are staged for approval first. Hire payments are escrowed and refunded if the job fails. Unusual machine earnings are held for review. Each of those is a hold, not a wink.
| Outcome | When it is appropriate | What you should see |
|---|---|---|
| Refuse | The step is outside the written contract | The action does not start |
| Hold | The step might be valid after you confirm | A pause until you answer |
| Ask first | Spend, follow, or a move that needs consent | A question in the same chat |
| Wave through | Never | Nothing: the gate failed |
How do you write rules in plain sentences without hiding the real limits?
Write the behaviour you want in the words you would say to a colleague. Keep one idea per sentence. Name the action, the condition and the stop. If two rules could clash, say which one wins. Do not bury a spend limit inside a style note about tone.
Read the rule back as a machine would: if this proposed step matches the banned pattern, stop; if it matches a confirm pattern, hold; otherwise continue. If you cannot tell which of those three would fire, the sentence is not a rule yet. Simpler tools are better when you only need a calendar mute or a scheduled post queue: a native scheduler already refuses late sends without an agent in the loop.
- Refuse
- The proposed step is blocked and does not run.
- Hold
- The step waits until you confirm, change or cancel it.
- Read-back
- A plain account of which rule matched and what it stopped.
- Wave-through
- Letting the model proceed despite a matching rule; this must not happen.
How do you read back what a rule actually stopped?
If you cannot see the stop, you cannot trust the rule. After a hold or a refuse, the system should name the sentence that matched, the action that was about to happen, and whether it asked, paused or blocked. For trades, that means you can pause, change or stop with a sentence and see the limits you set in advance. For robots, every command carries a deadline, the owner contract is enforced in one place, and every job leaves a recording with the path kept next to the robot's claim.
Long runs should also list decisions made on your behalf, why, and how to change them. Skills written from repeated requests stay off until you switch them on. If a simpler checklist or a single-purpose bot already gives you that read-back, use it. An agent is worth the extra surface when the same identity must carry rules across chat, code, markets, machines and hires without losing the thread.
- Name the action and the condition in one sentence.
- Prefer hold or refuse over a warning that can be ignored.
- Require a read-back of what matched and what stopped.
- Use a native scheduler or broker when one channel is all you need.
Common questions
Should agent rules live in the prompt or in a gate?
Put them in a gate that runs on the proposed step. A prompt is easy to overwrite in a long chat. A gate can refuse or hold even when the wording of the latest request is urgent. You still write the rule in plain sentences; you just do not rely on the model to remember them at the moment of action.
Why must a rule never wave an action through?
Waving through gives the model a veto over your contract. The point of a rule is that matching steps stop or wait, whoever asked. Holds are for confirmation. Refusals are for steps that are simply out of bounds. If a warning can be skipped, you do not have a rule, you have a suggestion the next busy turn can ignore.
How do I know a rule actually fired?
You need a read-back: which sentence matched, what was about to happen, and whether the system asked, paused or blocked. Without that, you cannot tell memory from enforcement. Trading, wallet follows, staged social posts, escrowed hires and robot contracts are only trustworthy if the stop is visible in the same conversation.
When is a simpler tool better than an agent with rules?
When one channel is enough. A platform scheduler can refuse late posts. A broker can enforce a stop without chat. Use an agent when the same limits must follow work across mail, code, markets, machines and paid hires, and when you still want to pause or change those limits with a sentence rather than a new dashboard.
For how GROX applies plain-sentence limits on trades, follows, robots and hires, see Home and the Help Centre.