On This Page
Imagine a product catalog that changes on Monday. An assistant’s prompt still contains Friday’s list. The team updates the prompt. A second copy of the old list sits in examples used to train the model. The assistant now gives one current answer and one obsolete answer in the same session.
This is an illustrative failure, but its mechanism is common: the same fact has acquired more than one home.
A talk about prompts, retrieval and model weights draws a useful boundary. A prompt tells the assistant how to behave. Retrieval brings current, citable knowledge into a particular task. Model adaptation can teach a stable pattern. Treating those three as a ladder, with prompting first, retrieval next and fine-tuning whenever the answer is still wrong, misdiagnoses factual errors.
A prompt is a poor catalog
Prompts are attractive because they are easy to edit. Add a paragraph and the next request carries it. That convenience hides two costs. The fact is sent with every call, even when irrelevant. And a large prompt makes it harder to know which copy of a rule the model used.
A durable instruction such as “ask before sending a campaign” belongs close to the agent. A list of this store’s current custom fields does not. It may change after an account administrator adds an attribute. It may differ across tenants. It may be visible to one workspace and forbidden to another.
The Brevo connector guide shows why field definitions matter to a contact sync. If an attribute has not been declared in the destination account, a mapping that looked sensible from its name may not produce the intended field. The agent should inspect the account’s current contract, not recall a generic field list from training.
A useful retrieval result is small enough to challenge. It should say which account or tenant it applies to, when it was read, and which operation or field it describes. If two retrieved passages disagree, the system should expose the conflict instead of silently choosing the more fluent one. The right next step may be a fresh lookup or a review, not another attempt to phrase the prompt more forcefully.
Retrieve the fact with its scope
A useful knowledge record carries more than text. It needs a source, version or retrieval time, account scope and a clear way to remove or replace it. A field definition found in one merchant account should never become a universal rule for another.
A question about a contact attribute can then retrieve the smallest passage that answers it: the field name, type and account where it exists. The answer can point back to that source. If the mapping fails, the team can ask whether the fact was stale, whether the wrong account’s result was returned, or whether the model misunderstood a correct passage.
Those are different repairs. A prompt tweak cannot fix a retrieval filter that crosses tenant boundaries. A bigger model cannot supply an attribute definition that nobody fetched.
The MCP explainer covers how an agent can query tools. The tool should return the relevant contract, while the application enforces who may see it. A text instruction saying “do not reveal another tenant” is no substitute for a scoped query.
This division also makes repair faster. If a destination field is renamed, update the schema source and invalidate the affected mapping. If the agent repeatedly misunderstands a stable instruction, change the instruction or test a targeted training approach. If an answer is wrong because the retriever selected the wrong account, fixing model weights would miss the cause. Each class of error has a different owner and a different correction path.
- Durable instruction
How the assistant should behave
- Scoped retrieval account · version · time
What is true now
- Mapping decision
Use the current fact for this task
- Enforced write
Code checks permission and scope
Teach patterns only after they settle
The fair objection is: “If a fact is used constantly, why not train it into a smaller model?” Repetition alone is not enough. The fact must remain correct across the interval between model updates, and the model must have a way to distinguish contexts.
A stable style of classification may eventually be worth tuning. A vendor’s current list of fields is a poor candidate. Even if it changes rarely, the cost of one stale answer can be a wrong mapping applied to many records. Keep the fact where a person can inspect and update it.
The source talk also warns against using retrieval to solve every reasoning failure. If the model cannot compare two relevant documents correctly, adding fifty more documents will not teach it to reason. First ask whether the right passage arrived. Then ask whether the judgment over that passage was sound.
For an integration builder, this yields a repair sequence: identify the incorrect claim; inspect the retrieved field or API passage; verify its account and version; correct the source or retrieval if needed; test the decision again. Only then consider a model change.
The cost is maintaining a real knowledge layer: source updates, access checks and citations. The gain is a fact that can be corrected in one place.
A changing contract should never have to wait for a model to forget it.
Frequently Asked Questions
What belongs in an agent prompt?
Small, durable instructions about behavior and boundaries belong there. A changing catalog, tenant-specific field list or current vendor rule should be retrieved from an authorized source when needed.
Why not fine-tune a model on current documentation?
Fine-tuning can bake a changing fact into weights that are hard to inspect and update. First make sure the correct document is retrieved and cited at the time of the decision.
How should a wrong factual answer be repaired?
Inspect the source document, its version, the retrieval filter and the returned passage. Correct the fact or retrieval path before changing the model.