Does CopilotKit Remember Between Sessions?

Yes, with the right layer turned on. CopilotKit's open-source SDK syncs shared state between your UI and your agent while a session runs, but durable memory across sessions comes from its Intelligence platform, where a Thread persists messages, generative UI, approvals, shared state, voice, and files. That memory lives inside your CopilotKit app. An agent outside that app, in another tool or on a schedule, still starts blank unless it reads a memory layer of its own.

What does the open-source SDK remember on its own?

The SDK is a frontend stack for agents. It connects your React app to an agent over the AG-UI protocol, renders the agent's UI inside your product, and keeps both sides in sync while they work.

Shared state is the core mechanism. With the useCoAgent hook in v1, or useAgent in v2, your app and the agent read and write the same state object. The agent adds a research result, the panel renders it. The user edits a field, the agent sees the edit on its next run. Human-in-the-loop approvals work the same way: the agent pauses, the user decides in the UI, and the decision flows back into the run.

All of that is live sync inside a working session. It answers "can the UI and the agent see the same thing right now," not "will the agent know this next week." When the session ends, shared state ends with it, unless a persistence layer underneath saves it. CopilotKit's own launch coverage for its persistence platform states the gap plainly: the platform adds the infrastructure layer the SDK lacks.

What does a CopilotKit Thread actually persist?

The Enterprise Intelligence Platform, announced in May 2026, makes the Thread a first-class persistent object. A Thread survives across sessions, devices, and agent runs, and it captures more than chat text.

1. Messages: the conversation itself, restored as it was.
2. Generative UI: the components the agent rendered at runtime, stored, not just the prompts that triggered them.
3. Human-in-the-loop steps: approvals, edits, and guided decisions taken during a run.
4. Shared state: the synchronized state between your backend agent and the frontend, recorded so both sides resume from the same context.
5. Voice: spoken input and output across sessions.
6. Files: uploads and generated artifacts, kept inside the Thread instead of vanishing when the session closes.

The platform can be self-hosted on Kubernetes, with a managed cloud option in development. A newer User Memories feature adds durable facts and preferences carried across conversations and recalled semantically. For a user returning to the same app, this is real continuity: a morning process resumes where it left off, on another device.

Where does Thread memory stop?

A Thread belongs to one CopilotKit application. Its memory is the record of what happened inside that app, for that product's users, through that interface.

Three kinds of work sit outside it.

First, your other interfaces. The decision a user reached inside your CopilotKit app is not visible to the same user working in Claude, Codex, or Cursor, and it is not visible to you when you plan the next feature in a different tool. Each surface keeps its own record.

Second, your scheduled and headless agents. A nightly agent that reviews tickets, a cron job that summarizes the day, an n8n workflow that drafts follow-ups: none of them render UI in your app, so none of them read or write its Threads. They start each run from their own inputs.

Third, work state above the conversation. Projects, tasks, and standing rules are not Thread contents. A Thread can show that a user approved a plan. It does not hand the next agent, in the next tool, the project board and the rules that plan was made under.

Builders already feel this boundary in practice. CopilotKit cookbook examples wire long-term memory in from outside, for example a recall tool backed by an external database, with the pattern stated plainly: the external store does the remembering, CopilotKit does the conversing, and the agent code is the seam between them.

How do you give a CopilotKit agent memory every tool can share?

Keep CopilotKit for what it does best, the in-app experience, and put the cross-tool memory in a layer every client can reach.

1. Connect each tool and agent you use to the same memory account.
2. Load relevant context at the start of a session or run, before the agent acts.
3. Save the exchange, the decision, and any correction at the end of the run.
4. Correct memory in one place when something changes, so the newest version is what every client retrieves next.

That is the shape Vilix AI is built for. It is a cloud-hosted memory layer, so there is zero infrastructure to run: no database to operate, no Kubernetes cluster to maintain. Every connected client reaches the same memory over MCP. An agent you build connects with its own API key as a Bearer header to the MCP endpoint and gets the same memory as the tools you use yourself, so the copilot inside your app, your scheduled agents, and your daily AI tools all read and write one record.

What gets stored is full conversation history, not just extracted facts, plus projects, tasks, and reusable rules and skills built on top of it. Retrieval combines semantic search, so recall finds what you meant, with keyword search, so exact strings like order IDs and policy names match literally. When two saves conflict, the most recent save wins and recency-aware retrieval surfaces the newest version, so one correction fixes every client at once.

Getting started carries no commitment. The free plan is free forever, and the 7-day Pro trial needs no credit card. Your data stays yours the whole time: export everything in a portable format whenever you want, or delete individual memories or the whole account instantly.

Frequently asked questions

Does CopilotKit remember between sessions by default?

In the open-source SDK, shared state syncs your UI and agent during a session. Durable cross-session memory comes from the Intelligence platform's persistent Threads, which store messages, UI, state, approvals, voice, and files so a conversation can resume across sessions and devices.

What is the difference between shared state and memory in CopilotKit?

Shared state is live, bidirectional sync between your frontend and your agent while they work together. Memory is what survives after the session ends. Shared state becomes memory only when a persistence layer, a Thread store or an external memory service, saves it.

Can an agent outside my CopilotKit app use its Thread memory?

A Thread is scoped to the CopilotKit application that created it. Agents in other tools, scheduled jobs, and headless runners do not read it. To share context with them, save it to a memory layer those agents can also connect to, over MCP.

How does a built agent connect to Vilix AI?

With an API key sent as a Bearer header to https://api.vilix.ai/mcp. The agent loads relevant context with get_context and saves each exchange with save_turn, the same memory your other connected tools use.