Step 1: no refund over £200 without a human. Step 22: the history is summarised to save tokens, and the rule is dropped. Step 38: the agent refunds £900 and says it followed policy.
Casius Lee (Oracle) calls this a context engineering problem. Four operations decide what the model sees, and each buys tokens back at a different price:
- Load eagerly: always present, but uses window space on every step.
- Fetch just in time: lean, but adds a round trip and misses sources the agent doesn't know about.
- Compact: fits long runs in a small window, but omission is irreversible unless the originals stay addressable.
- Hand to a sub-agent: a clean window, but evidence comes back as a claim.
One fix, and its limit
His example uses Oracle AI Agent Memory 26.8 with Oracle AI Database 26ai: pin the rule as a guideline, check it's still in the context card, and keep the raw messages in the database with their IDs. But seeing a rule isn't obeying it: the payment tool itself must refuse without a human.
My takeaway from building multi-agent systems
Get the Oracle + AI digest
One email when a new tested guide, template or APEX release note lands — English or Arabic. No spam; unsubscribe anytime.