Appearance
Memory
What an agent remembers, and for how long. MyChatBot agents keep two independent layers of memory: short-term conversation state (this thread's message history plus the settings applied to each reply) and long-term memory (durable facts distilled after a conversation and kept per agent). Use this page to know which layer holds what, what survives a new conversation, and what the agent can — and can't — recall on its own.
Cheat sheet
| Layer | What it holds | Scope | Lifetime | Auto-recalled at reply time? | You control it via |
|---|---|---|---|---|---|
| Conversation history | Every turn's messages, tool calls, and outputs | One conversation | Until archived / trimmed | Yes — the thread's own history is the context the agent sees | Starting / archiving a conversation |
| Conversation list entry | Title, agent, timestamps | Per account | Until archived | n/a (a list label, not context) | Renaming / archiving in the chat list |
| Per-reply settings | The instructions, tools, connectors, and skills applied to this reply | One reply | Rebuilt for every reply | Yes — shapes the agent for that reply | The agent's Settings |
| Long-term memory | Durable facts ("customer prefers X") | Per account, per agent | Until MyChatBot evicts the oldest to make room | No — not yet | Saved automatically after a conversation |
The one thing to remember: long-term memory saves durable facts, but agents do not look them up mid-conversation yet. It's a background record today — don't design flows that assume an agent will "remember" a fact from an earlier conversation on its own.
Where conversation history lives, by channel
| Channel | Shows in the Conversations list? | Keeps full history? |
|---|---|---|
| Web chat | Yes | Yes |
| Telegram | Yes, read-only (marked as Telegram) | Yes |
Telegram conversations are read-only in the app
Messages exchanged with your Telegram bot keep their full history and appear in the agent's Conversations list flagged as Telegram. You can read them there, but you reply from Telegram itself — not from the web chat box.
Conversation state (short-term)
A conversation is one continuous thread with one agent. The agent's working memory for that thread is its history — every prior turn in the conversation is the context the next reply sees. Start a new conversation for a new topic and the agent starts fresh, with none of the earlier thread's context.
Where conversations live in the app
Open an agent at app.mychatbot.app/agents → pick an agent → Conversations, or see every thread across agents at app.mychatbot.app/agents/chats. Use + New chat to start a fresh thread and the archive control on a row to retire one.
Very long conversations lose their oldest turns
To keep a single thread from growing without bound, MyChatBot trims each conversation once it gets long. Very long threads silently drop their earliest messages from the agent's context. For distinct topics or customers, start a new conversation instead of letting one grow forever.
Per-reply settings
Before each reply, the agent is assembled from its current Settings — its instructions, the tools and connectors you've switched on, and its attached skills. This is recomputed for every message; it's not durable memory, it's just "how the agent is configured right now."
Settings changes apply on the next reply
Because the agent is rebuilt for each message, editing its tools, instructions, or connectors takes effect on the next message — you don't need to restart the conversation. Find these under app.mychatbot.app/agents → pick an agent → Settings.
Which model an agent uses
The model is a property of the agent, not of an individual conversation. Set it under Settings → Identity → Model, and every conversation and scheduled task for that agent uses it.
Set an agent's model in the app
app.mychatbot.app/agents → pick an agent → Settings → Identity → Model. Pick a model by its display name (GPT-5, Claude Opus, Gemini, Grok, and more). Leaving it empty falls back to the agent's built-in default.
Two model gotchas
- Reasoning behavior doesn't carry across a model switch. Each model comes with its own built-in reasoning depth. Switching from a deep-reasoning model to a lighter one can quietly turn that extra reasoning off. Pick the model whose reasoning matches the task.
- Built-in agents ship with a default model, not a fixed one. The general-purpose built-in agents come pre-set to a sensible model, and the app may not show a model picker for them. Whatever model an agent uses, you can't move an existing conversation to a different agent mid-thread — that would hand the conversation to a different assistant. Start a new conversation with the agent you want instead.
Long-term memory
After a conversation, MyChatBot quietly reviews it and decides whether anything durable came up — a preference, a standing fact, a decision worth keeping. It picks one of three outcomes:
| Outcome | Meaning |
|---|---|
| Skip | Nothing durable, or already captured |
| Save new | A new durable fact — added to long-term memory |
| Update existing | Refines a fact already remembered — replaces it in place |
Durable facts are kept per account and per agent. This review runs in the background — you never wait on it, and if it fails, your conversation is unaffected.
No auto-recall yet
Long-term memory saves facts but agents do not look them up during a conversation yet. It's a background record today. If an agent must act on a prior fact, put it in the agent's Instructions (always in context) or keep the work in one ongoing conversation — don't rely on it recalling from long-term memory.
Long-term memory is deliberately not written for:
- The built-in general assistant (its capabilities are fixed by design).
- Scheduled / automated runs — there's no real user turn to reflect on.
- Replies with no user message (autonomous runs rarely surface anything worth keeping).
Memory is capped
Long-term memory holds a bounded number of entries per account (a limit tuned by MyChatBot); once it's full, saving a new fact evicts the oldest one first. This keeps it from growing without bound.
Best practices
Do
- Start a new conversation per topic or customer thread — it keeps history relevant and avoids the trim eating older context.
- Set the model on the agent (Settings → Identity → Model) when a task needs a specific model or reasoning depth.
- Put facts an agent must act on into its Instructions (durable, always in context), not long-term memory.
Don't
- Don't assume an agent will "remember" something a user said in an earlier conversation — there's no auto-recall.
- Don't let one conversation run indefinitely and expect the earliest turns to survive.
- Don't try to switch an agent mid-thread to change who's answering — start a new conversation with the agent you want.
Test it
- History persistence: send two turns in a web conversation, then reopen it — both turns should reload.
- Per-reply settings: toggle a tool on the agent's Settings, send a message, and confirm the new tool is available without starting a new conversation.
- Model switch: change the model under Settings → Identity → Model, send a message, and confirm the reply uses the new model (and re-check its reasoning behavior, which doesn't carry over).
- Long-term memory: hold a conversation that states a clear durable fact (e.g. a preference); it's saved in the background after the thread. A bare greeting should save nothing.
- Telegram: message the bot, then confirm the exchange shows up in the agent's Conversations list as a read-only Telegram thread.
See also
- Models & reasoning — picking a model and reasoning depth for an agent
- Tools & toggles — what the per-reply settings pull from
- Tasks, crons & schedules — why scheduled runs don't write long-term memory
- Connect Telegram — how Telegram conversations appear in the app
- Build an agent — agents, settings, and starting conversations
- Troubleshooting — trimmed history, stale replies, and model-switch surprises