How one always-on agent wrote 12k memories with Vilix AI

One power user was running an always-on autonomous agent through Vilix AI, which wrote roughly 12,000 memories without any manual curation. The agent called get_context, composed its reply, saved the exact exchange with save_turn, and then sent the saved reply. Vilix AI handled storage, search, deduplication, and cross-session retrieval. This post walks through the setup and how a read-and-save loop makes earlier exchanges available to a long-running agent.

The setup: one MCP connector, one always-on agent

The user connected their agent to Vilix AI by setting up a single custom MCP connector pointing to api.vilix.ai/mcp.

There is no browser extension to install or SDK to integrate, and no separate ingestion pipeline to build. The client needs compatible remote MCP support, authentication, and instructions that invoke the memory tools.

The agent in this case was a general-purpose task runner: it would wake up on a schedule, retrieve queued items from a task queue, perform the requested work (web search, code generation, data transformation), then sleep until the next tick. There was no in-memory state shared between ticks, and every run was stateless.

After connecting to Vilix AI, the system prompt for this agent defined the memory loop: call get_context with the latest message, compose a reply, then call save_turn with the exact exchange and return the saved version. The connected client needed authentication and a verified working tool loop, but no custom retrieval logic, chunking pipeline, or vector database to maintain.

What get_context actually loads

Before composing its reply, the agent calls get_context, which returns several kinds of context in one response:

• Recent messages available to the current conversation

• Saved memories: facts and decisions retained from previous exchanges or explicitly saved as memories

• User rules: short personal instructions the owner has saved for the agent

• Live project/task state and notes relevant to the current project

• Related past conversations, discovered through keyword and semantic search of the memory repository

This all comes before the agent starts composing a reply for the turn. The agent provides the current user message to get_context, and Vilix AI selects relevant available context for that message, with retrieval features depending on the plan.

What save_turn actually writes

Before returning the reply, the agent calls save_turn with the exchange: user_message, assistant_message, source, and chat_id. Vilix AI saves this server-side in the connected user’s account.

It is separate from the agent process: if the agent gets reloaded or replaced, the memories it saved with save_turn are still there and can be loaded by the next instance. These per-turn writes added up to roughly 12,000 total memories for this user, with no manual curation or management of the memory repository.

When the memory store contains relevant facts or decisions from earlier turns, those records are available to inform later work.

How per-turn saving compares with document ingestion

One pattern for adding memory to an agent is document ingestion: a pipeline that indexes relevant documents into a vector database, which the agent can query at inference time.

This works well for static knowledge repositories. Document ingestion can be continuous or batched, depending on the pipeline. Per-turn saving records a completed exchange directly, making it available for later retrieval without waiting for a separate document import.

A self-managed document ingestion pipeline may require you to manage storage, embeddings, chunking, and query logic. A hosted solution handles storage and retrieval, but still needs a working connection and a stable read-and-save loop.

Saving through save_turn preserves the assistant’s reply along with its source message, including explanations and decisions in the saved reply. It does not capture hidden internal reasoning. Other ingestion methods can also be configured to preserve conversational context.

What changed for the agent at scale

As the archive grew, prior task outputs could be retrieved in later turns. The saved outputs provided context about previously completed work.

Similarly, saved user corrections could be retrieved as relevant context for later turns, giving the agent access to preferences expressed in earlier conversations.

The useful distinction is that the agent’s completed conversations were consistently saved and could be reviewed in later turns. The reported 12,000 memories represented the size of this user’s archive, rather than an accuracy benchmark, a performance milestone, or a guarantee of better output.

How to replicate this setup

If you are building or running an autonomous agent and want to preserve long-term memory between interactions, connect it to Vilix AI at api.vilix.ai/mcp using the client’s supported remote MCP configuration. Authenticate and add the Vilix AI instructions: call get_context, compose the reply, call save_turn with the exact exchange, and then send the saved reply. Reuse chat_id within a conversation and test both calls.

For a step-by-step guide to this specific setup, see how to add memory to any agent with Vilix AI MCP. If you are using OpenClaw specifically, there is also an agent memory guide for OpenClaw.

Vilix AI connects to supported tools and agents with compatible remote MCP connections, including ChatGPT, Claude, Claude Code, Cursor, Codex, Manus, Windsurf, and Lovable. Memory is stored in your Vilix AI account and can be retrieved by other clients connected to that account.

You can start with the free plan and upgrade to Pro (7-day full trial, $19.99/month after) when you need Pro memory features and priority support. Try Vilix AI free and connect your first agent in a few minutes.

Frequently asked questions

How did the agent accumulate 12,000 memories without manual curation?

The agent called save_turn with each completed exchange before returning its reply. Across thousands of runs in this user’s account, those writes added up to roughly 12,000 memories. No manual curation was required or performed: the agent saved exchanges consistently.

What is the difference between get_context and a standard vector database query?

A vector database query returns similar text chunks based on embeddings. get_context returns recent messages, saved memories, user rules, project and task state, and related past conversations. The agent provides the current user message; Vilix AI handles the retrieval logic behind that context response.

Does the agent need a custom integration or SDK to use Vilix AI?

There is no SDK or browser extension to install. The client needs compatible remote MCP support and authentication, plus instructions or orchestration that call the tools. Point it to api.vilix.ai/mcp, configure the read-and-save loop, and verify both calls in a real conversation. No separate ingestion pipeline is needed to save exchanges with Vilix AI.

Will memory from one agent session carry over to a completely fresh process?

Yes, because memory is stored server-side in the user’s account. If the agent is restarted or replaced, another instance connected to the same account can query those saved exchanges. A fresh process can call get_context and retrieve relevant available memory from earlier sessions.

How does per-turn memory scale as the store grows large?

Vilix AI uses semantic and keyword search to find relevant memories for each context load, with retrieval features depending on the plan. The agent gets a subset of available history sorted by relevance, rather than the entire archive at once.