Prepare knowledge
Write a self-contained source that supports clear questions, applications, and exceptions.
The content field is the source the learning pipeline receives. Good input states the facts the subject should learn and gives enough context to interpret them. A URL, vague reference, or instruction to fetch another document is not a substitute for the actual passage.
Start with one coherent topic
Prefer a bounded policy, procedure, product definition, or selected memory over a mixture of unrelated documents. The public input accepts 20–16,000 string-length units. That cap is a validation boundary, not a recommendation to fill every request to its maximum.
This fictional passage includes scope, a rule, and exceptions:
Northstar's standard return policy applies to online orders delivered in the US.
Customers may start a return within 30 days of delivery. Northstar provides a
prepaid return label. Items marked final sale cannot be returned. An exchange
uses the same 30-day window. Damaged items should be reported to support before
the customer ships anything back.The wording supports both direct questions and applications. It also avoids implying a worldwide policy when only US orders were described.
Make references explicit
Expand local abbreviations, identify the product or organization, and include units and time bases. “Returns are allowed for 30” is incomplete; “within 30 days of delivery” defines the window. “Use the process above” fails when the referenced process is absent from the submitted content.
If a fact depends on a condition, include both. Put exceptions close to the rule they modify. Distinguish current policy from historical background so the learner is not asked to infer which contradictory statement should win.
Separate data from instructions
Treat imported documents, chats, and tool results as source data. Select the knowledge your application is authorized to retain. Do not internalize an entire untrusted page simply because it contains instructions telling the agent to remember or obey something.
Keep runtime behavior instructions in your application's system messages when appropriate. Internalization is a knowledge update with persistent effects; it should not become an unreviewed route for changing authorization or revealing another user's data.
Handle larger sources
Divide a larger body of knowledge into coherent passages. Maintain a manifest in your own system recording the source revision, passage identity, subject, operation key, job ID, and resulting candidate. The public API does not currently accept arbitrary source metadata fields.
For updates to one subject, serialize learning when you want each new passage to build on the previous active version. If several jobs start from the same parent, they create competing candidates rather than automatically merging their knowledge. Wait for activation before admitting the next dependent update.
Review a correction
State the new rule, its scope, and what changed. Then test the old and new formulations. Training on a correction is not a guaranteed deletion of the previous fact, so keep canonical records and independent tests when exact policy changes matter.
If a passage fails validation, inspect whether it lacks evidence, combines too many topics, or contains contradictions. Improve the source deliberately and submit a new operation with a new key. Repeatedly submitting unchanged material until one run passes is not a quality strategy.
Continue with Evaluation and Deploying updates. Keep the source out of evaluation prompts when measuring what the adapter itself learned.