Fix memory pollution-multi-tenancy
AgentMemory
We are building a multi-tenant WhatsApp commerce agent where each store has its own configuration, including:
-Agent name
-Personality
-etc
Current Problem
We currently prepend a configuration prefix to user messages before calling agent.generate():
const message =
await agent.generate(message, { memory: { ... } });
However, this approach has two issues:
The prefix is stored in memory with every user message, wasting tokens.
When the TokenLimiter truncates history, the LLM sees [CONFIG...] and interprets it as a context reset, causing confusion.
Options Considered
-System parameter in generate() – Use for supplementing agent instructions.
-Context parameter – Provides additional context messages.
-Dynamic instructions with runtimeContext – Instructions are functions that read the store config from runtimeContext.
We plan to use Option 3 (runtimeContext) because:
Instructions are resolved per request at runtime and they do not seem to persist in memory.
Question
Is Option 3 the recommended approach for injecting per-request configurations that should not persist in memory, or would using the system/context parameters be more appropriate?
-Agent name
-Personality
-etc
Current Problem
We currently prepend a configuration prefix to user messages before calling agent.generate():
const message =
${storePrefix}${userMessage}await agent.generate(message, { memory: { ... } });
However, this approach has two issues:
The prefix is stored in memory with every user message, wasting tokens.
When the TokenLimiter truncates history, the LLM sees [CONFIG...] and interprets it as a context reset, causing confusion.
Options Considered
-System parameter in generate() – Use for supplementing agent instructions.
-Context parameter – Provides additional context messages.
-Dynamic instructions with runtimeContext – Instructions are functions that read the store config from runtimeContext.
We plan to use Option 3 (runtimeContext) because:
Instructions are resolved per request at runtime and they do not seem to persist in memory.
Question
Is Option 3 the recommended approach for injecting per-request configurations that should not persist in memory, or would using the system/context parameters be more appropriate?
