# OpenAI Dots have memory. Your agent still needs a knowledge base.

An agent can know how you work and still need the document that explains why you chose PostgreSQL, what you promised a customer, or which launch claims you have actually tested.

[OpenAI Dots](https://openai.com/index/introducing-dots/) make that distinction worth thinking about. They are always-on agents with their own cloud computers. They can continue towards a goal between conversations, use connected apps and learn from feedback, without you directing every step.

The pattern moves from *prompt → answer → conversation ends* towards *goal → ongoing work → learning → more work*.

Dots can remember context. The useful question is where durable project knowledge should live.

## OpenAI Dots already have memory

OpenAI says Dots learn your preferences and standards as you work together. They can work across connected services and carry context between channels such as ChatGPT and Slack. OpenAI's [getting-started guide](https://help.openai.com/articles/20001530) also says a Dot receives memories from ChatGPT and can form its own, including from connected apps.

That is useful. An assistant that learns how you like a review presented saves you repeated corrections. One that remembers your goals can make better suggestions about what to do next.

You still set the boundaries of its work. OpenAI describes permissions and approval rules, rather than an agent with unrestricted authority.

As of 30 September 2026, OpenAI's [published availability information](https://help.openai.com/articles/20001530) says Pro access excludes the European Economic Area, Switzerland and the UK. The rollout is gradual, and availability differs by plan.

## Memory and knowledge are different jobs

Think about a small software project.

Agent memory may capture that you prefer short answers, usually want a working example, and are trying to ship a customer portal this quarter. That context helps the agent work with you.

Your knowledge base holds the things someone needs to get the project right:

- **Architecture:** why you chose PostgreSQL and which alternatives you rejected.
- **Pricing:** the agreed price, the reasoning and when to review it.
- **Launch learnings:** which message customers understood and which confused them.
- **Customer context:** what a customer asked for, with a link to the original conversation.
- **Publishing rules:** which claims have evidence and which are still hypotheses.
- **Project constraints:** deadlines, dependencies and decisions that need approval.

There is overlap. A preference can be a written instruction, and an agent can remember a project decision. The distinction is how you maintain the record. A knowledge base gives you explicit documents to inspect, correct, organise and reuse.

When people ask about long-term memory for AI agents, both jobs matter: learning useful context and keeping a reliable record of what was decided.

## Your project should not belong to one agent

A Dot may understand your project well. Tomorrow you may want Claude to review the architecture, Cursor to help implement a change, or ChatGPT to work through the launch plan.

Those tools do not all share one native memory system. Moving between them should not mean reconstructing the project from chat history.

Keep the durable material in a separate store, and compatible clients can read the same notes. Each connection still needs to be supported and configured. The shared object is the document, not the assistant's internal memory.

That is the practical point of [keeping context when you switch assistants](/blog/the-best-model-keeps-changing). You can try another tool while retaining the reasoning behind your work.

## A simple way to think about it

**Agent memory is what the AI learns about working with you.**

**Your knowledge base is what you decided is worth keeping.**

The agent can help write that knowledge down. You remain able to read it, challenge it and change it. Neither layer needs to replace the other.

## Where Hjarni fits

Hjarni is a hosted Markdown knowledge base with a built-in MCP server, so ChatGPT, Claude and other MCP clients can read, write and search your notes directly.

The [MCP knowledge base](/mcp-knowledge-base) is the explicit knowledge layer. A connected assistant can find the architecture decision before proposing a migration, then write the agreed outcome back after the work. You can open the same note and correct anything it misunderstood.

The setup guides cover [ChatGPT](/docs/connect-chatgpt-mcp) and [Claude](/docs/connect-claude-mcp). The notes remain independent of either assistant, and you can [export them as Markdown](/docs/export-and-ownership).

We have not tested Hjarni with OpenAI Dots. This article describes why an external knowledge base is useful; it does not establish a Dots integration or confirm that Dots supports a custom MCP connection.

## The read → work → write-back loop

For a compatible agent with access to your knowledge base, the useful loop is small:

1. **Read existing knowledge.** Find the current project state, relevant decisions and instructions.
2. **Do the work.** Investigate the problem, test an approach or prepare a proposal.
3. **Identify what lasts.** Separate a confirmed finding or agreed decision from a guess and from temporary working notes.
4. **Write the durable result back.** Update the relevant note with the outcome, date, reasoning and sources.
5. **Let the next agent start there.** A future run reads the updated record instead of repeating the investigation.

Suppose an agent investigates a slow import. It finds that a vendor's rate limit is the bottleneck. You agree to queue requests rather than change databases.

The useful result is a short decision note: the measured limit, the evidence, the chosen queue behaviour and what would justify revisiting it. Saving every tool call would make the next investigation harder. Saving only "imports are slow" would lose the reasoning.

This is where persistent AI agents become more useful. Work can leave behind something the next task builds on, even when a different assistant does it. The broader [AI agent knowledge base pattern](/blog/knowledge-base-for-ai-agents) covers how to organise that shared store.

Write-back needs rules. Tell the agent to update an existing note when one covers the topic, preserve sources and label unresolved ideas. In Hjarni, [folder instructions](/docs/ai-instructions) carry those conventions with the notes. They guide the assistant; they do not guarantee compliance. Use [note history](/docs/note-history) to review changes and undo mistakes.

An always-on agent should not turn every observation into permanent knowledge. Save what could change a future decision. Keep the record small enough to check.

## When built-in memory is enough

If you use one assistant for light personal work, and do not need exact project knowledge shared across tools, built-in memory may be enough. Remembering your preferences without maintaining a collection of notes is useful in its own right.

A separate knowledge base earns its place when the work lasts longer or involves more people: a business with customer commitments, research with sources to preserve, a team with shared decisions, or a project spread across several assistants.

Start with one decision you keep explaining. Record what you chose and why. Ask your connected assistant to read it before the next related task and save the agreed result afterwards.

OpenAI Dots make agents more persistent. The knowledge they work from should be persistent too, and reusable outside any one agent.

Hjarni provides that knowledge layer for compatible assistants you connect to it. The principle is simple: **your AI should read and write your knowledge base directly instead of you re-explaining context in every chat.**