Practice guide: where to put your rules — decisions and examples
the same sentence behaves differently in persona, operating rules, memory, knowledge base, or a skill. Self-check with the questions below, then compare examples.
Source help/en/guides/where-to-put-your-rules.md
In user language: the same sentence behaves differently in persona, operating rules, memory, knowledge base, or a skill. Self-check with the questions below, then compare examples.
Three-step decision
1. Is it “how to say” or “how to do”?
→ How to say → persona (SOUL)
→ How to do → continue 2
2. Is it team/role-shared, and a stable business metric?
→ Yes → workspace or agent **knowledge base**
→ No → continue 3
3. Must it run every conversation (including tools, skills, date math)?
→ Yes → **operating rules (AGENTS)**; also write API detail in the **skill**
→ No → is it only about you, and still true across conversations?
→ Yes → **long-term memory** or **user profile (USER)**
→ Only useful for the last few days → **daily notes**
→ To-do list → **tasks (TASKS)**
Example table
| What you want to say | Recommended landing | Not recommended | Why |
|---|---|---|---|
| Only use APIs in skills; do not invent paths | Operating rules + skill body | Persona, long-term memory | This is an execution constraint; it must apply every round at high priority; the skill is the single source of truth |
| “Later answer in bullets, not long paragraphs” | Long-term memory (preferences and corrections) | Persona | Personal preference, extracted from chat; you may put it in persona if you want every user of this assistant to get the same |
| “When querying, treat current time in the runtime environment as today” | Operating rules | Memory | The platform already injects time; how to use that time is operating rules |
| “I am backend; keep frontend questions short” | User profile or long-term memory · About me | Operating rules | Stable identity, not steps |
| “Q2 launch deadline June 30” | Long-term memory · project progress | Daily notes | Clear milestone, valid across conversations |
| “Finish the login-page redesign today first” | Daily notes | Long-term memory | Temporary task |
| “Expense policy follows wiki chapter 3” | Workspace knowledge base | Personal memory | Team-shared metric |
| “This assistant calls customers ‘partners’ externally” | Agent knowledge base or persona | Personal memory | Role setup, not the user’s personal preference |
| “To-do: submit the test report before Friday” | Tasks | Long-term memory | List-style follow-up |
Deep example: “do not invent APIs; only use those in skills”
Why not persona (SOUL)?
Persona owns how to speak. If you only put a technical constraint in SOUL, the model may still improvise a URL when “helping look up data” — persona is high priority but does not give executable alternative steps (read the skill first, then http_request).
Why not long-term memory?
Memory fits your personal corrections (“last time you invented it; remember not to”). By default it is not full-text injected every round. Operating constraints should be stable, complete, visible every round, in operating rules; personal memory can supplement but cannot replace AGENTS.
Recommended writing (operating rules + skill split)
Operating rules (AGENTS.md) — paste then rename for the workspace:
## Network and APIs
- **Do not** invent URLs, paths, request-body field names, or treat example historical dates as a query range.
- When you need a business API: **first** find skill notes related to this workspace, and only use what they declare:
- Base URL / path
- Method, required parameters
- Auth (e.g. `{{member-credential-name}}`)
- Call with `http_request`; state results to the user **only from** JSON the tool returned.
- No matching skill, or the call failed: explain why, **do not** pretend you found data.
Skill body — write the concrete APIs (see How to write workspace skills).
Optional: if this is your personal repeated correction for this one assistant, Remember a preferences and corrections long-term memory with Why: and How to apply: — still not a substitute for operating rules.
Who wins on conflict?
- Clear steps in operating rules and skills (execution layer)
- Business metrics in the workspace / agent knowledge base
- Personal preferences in long-term memory (must not contradict 1 and 2; if they do, knowledge base and skills win, and you should update or delete stale memory)