Chat is good for the work that is happening right now. It is a bad place to keep the things your team needs to remember next week.
That gap shows up quickly once a workspace becomes useful. Someone writes down the support escalation steps in a thread. A product decision gets settled during a long conversation. An operations checklist lives in yesterday’s messages. The agent can answer well in the moment, but the context that made the answer good is scattered across old threads and easy to lose.
Memory pages are how Dawn handles that problem. They give your workspace a durable layer of context that survives individual conversations and stays available to the agents that should use it.
What Memory Pages Are For
A memory page is the right place for information that should stay true beyond one conversation.
That usually means things like team decisions, support policies, runbooks, product facts, naming conventions, internal FAQs, and recurring operating notes. If someone on the team would otherwise end up pasting the same explanation into multiple threads, there is a good chance it belongs in a memory page instead.
The useful distinction is simple. A thread is for the request you are handling now. A memory page is for the context you want Dawn to keep using later.
That matters because it changes how the agent starts a conversation. Instead of relying only on what the current user happened to type, the agent can answer from stable workspace context that has already been captured and reviewed. The conversation begins at a higher floor, and the team spends less time re-explaining things the workspace already knows.
What Belongs in Memory and What Does Not
The easiest way to get value from memory pages is to be selective about what goes into them.
Good memory pages tend to be durable and reusable. A runbook for responding to an integration outage is durable. A page that explains how your support team classifies billing issues is reusable. A page that lists the decisions from the last release review is useful because the same decisions will keep shaping future work.
Temporary requests usually do not belong there. A one-off question, a rough draft that nobody has agreed on yet, or a transient investigation note is usually better left in the conversation where it happened. If the conclusion becomes something the team should keep referring back to, that is the moment to turn it into a memory page — not before.
There is also a clean division between memory pages and skills. Skills tell an agent how to work — the formatting rules, tone, checklists, and procedures it should follow. Memory pages tell an agent what to know — the facts, decisions, policies, and reference material the team has agreed on. If the content is a checklist, a policy, a fact set, or a body of reference material, memory is usually the right fit. If it is a rule about how the agent should respond or format its output, a skill is the right fit. Most workspaces end up using both, and the combination is what makes the agent sound like it actually belongs to the team.
Choosing a Type So the Library Stays Coherent
Every memory page has a type, and choosing the right one is less about bureaucracy and more about keeping the library readable as it grows. Six types cover almost everything teams write down.
Notes are the catch-all. Use them for general observations, small bits of context, and things that do not fit cleanly into the other categories yet. If a note gets revisited often enough that it starts to need structure, it is usually ready to be rewritten as a more specific type.
Facts are short, atomic pieces of truth the agent should know — the name of a production cluster, the owner of a service, the email alias of a team, the identifier of a primary database. Facts are easy to spot because they are usually one or two sentences that answer a literal question.
Decisions record what the team has agreed on, especially when it would be easy to forget the reasoning later. “We are not adding SSO to the free tier because of support cost” is a decision. So is “All new endpoints return envelope responses.” Dating decisions is worth the habit: “as of March 2026” is the kind of phrase that saves arguments six months later.
Runbooks hold the step-by-step procedures the team runs repeatedly — incident response, onboarding, release checks, deploy verification. If someone on the team would otherwise walk through the same sequence of steps from memory every time, a runbook is the right shape for that memory.
References are the longer-form pages: architecture overviews, product taxonomies, glossaries, integration descriptions. These tend to be the pages a reader dips into rather than reading end to end, and they reward keeping a clear internal structure so the agent can pull the right section when it needs to.
Tutorials are how-to content, usually written for a human or as context for an agent that needs to teach someone else. A tutorial page is the right choice when the goal is to walk someone from not knowing the thing to being able to do it.
These types are not a rigid taxonomy — the point is that a reader browsing the workspace should be able to tell at a glance what kind of content a page holds, rather than opening every one to find out. Pick the type that matches the shape of the content, and move a page to a different type later if it evolves.
Keeping Memory Findable as the Library Grows
Memory only helps if people can find it and trust it, which means the organisation model has to hold up once the workspace has more than a handful of pages.
Types give the first level of structure. Tags give the second. Tags are where most of the day-to-day organising happens, because they cut across types — a billing tag can apply to the billing escalation runbook, the billing terminology reference, and the decision log about the billing tier restructure, regardless of each page’s type. The workspace ends up with a flexible grid rather than a rigid folder tree, and tags can be added or removed as the shape of the team’s work changes.
That tag model matters for more than browsing. It also controls which agents can use which memory. A support-facing agent does not need the same context as an engineering agent. A sales-assist agent probably should not be answering from the internal pricing discussion threads. By tagging the relevant pages and scoping each agent to the tags that fit its role, the agent stays grounded in the material it was meant to use and does not drag in unrelated context.
That is a better pattern than giving every agent every page by default. Broad access tends to degrade answers in subtle ways — the agent references a page that technically matches the question but was not written for this audience, and suddenly the response carries the wrong tone or the wrong policy. Scoped access keeps each agent’s answers tighter and more predictable.
In practice, most workspaces settle on a small number of primary tags — something like support, engineering, operations, product, billing — and a handful of secondary tags for cross-cutting concerns. That is usually enough to stay organised without making tagging feel like a bureaucratic step.
Editing Without Losing History
Memory pages are meant to evolve. A runbook changes. A decision gets revised. A reference page grows over time as the team learns more.
That only works if updating a page does not feel risky.
In Dawn Web, every save creates a revision. That means a memory page can improve over time without turning into an opaque blob that nobody wants to touch. If something is edited incorrectly, or a team realises the previous version was closer to the truth, the revision history is there to inspect and restore. It also means teams can audit how a page has drifted — which is useful when the page has been shaping the agent’s answers for a few months and somebody wants to know what changed between then and now.
That changes the behaviour around maintenance. People are more willing to keep memory current when doing so does not mean losing the earlier version forever. The natural rhythm is that a runbook gets tightened after each use, a decision page gets updated when the decision is revisited, and a reference page grows as the team learns something new worth writing down.
Archiving handles the other half of the problem. Some pages should stop shaping current answers without being deleted outright. An old process, a retired rollout plan, or an outdated but still informative reference page can move out of the active set while remaining available for later review. That keeps the working library cleaner without throwing away history — and when someone asks “what did we used to do here,” the archived page is still there to answer.
How Memory Works Alongside the Rest of Dawn
Memory pages are most useful when they are part of the broader workspace, not an isolated pile of documents.
Connected sources and memory pages sit next to each other, but they do different jobs. A connected source is something the agent reads fresh each time — a repository, a ticket system, a Confluence space, or a Notion page tree. Memory is what the team has distilled out of that external material, plus the things the external material does not capture: internal decisions, team preferences, the reasoning behind a rule, the context for why a policy exists. The agent ends up with two layers to answer from — the raw source material on one side, and the team’s curated context on the other — and the combination is far stronger than either in isolation.
Skills and memory also complement each other. A support skill might describe how the team wants every customer reply to be structured. A memory page holds the policies that determine what the reply actually says. Between the two, the agent produces a response that matches both the form the team wants and the substance the team has agreed on. If you find a skill growing long because it keeps encoding facts instead of process, that is usually a sign the facts want to be a memory page instead.
Scheduled tasks benefit from memory too. A recurring summary that runs every weekday morning can answer from the same memory pages a live conversation would, which means the summary is grounded in current policies and decisions rather than in generic model knowledge. If the relevant memory page changes, the next scheduled run reflects the new version — no separate configuration to update.
Even generated outputs shift when memory is in place. A dashboard prototype produced as an HTML artifact can reach for the palette, typography, and layout decisions the team has recorded in memory, so the first draft matches conventions instead of arriving in a generic shape. Memory becomes the shared substrate that makes every other feature more team-specific.
A Better Starting Point for Every Conversation
The real value of memory pages is not the page itself. It is what happens in the next conversation.
Take a support workspace where the team has already captured billing escalation rules, refund policy notes, and the current categories for subscription issues as memory pages. The next time someone asks the agent to draft a response to a billing problem, the agent is no longer starting from generic model knowledge and a short prompt. It starts from the team’s actual policy context — the kinds of issues that warrant refunds, the tiers at which decisions escalate, the tone the team wants customer messages to carry. The draft reply lands closer to what the team would have written by hand, and the reviewer spends time fixing the edges rather than rewriting from the middle.
The same pattern works for engineering and operations. A workspace with runbooks, incident follow-up notes, deployment constraints, and system facts gives the agent a much better chance of producing something grounded on the first pass. Instead of re-explaining the same background in every thread, the team spends its time on the part that is actually new — the specifics of this incident, this release, this customer.
That compounding effect is the point. Memory pages are less about storing documents and more about improving every future interaction that depends on stable context. A workspace with two memory pages feels incrementally better than a workspace with none. A workspace with thirty good memory pages feels dramatically different — the agent stops sounding generic and starts sounding like it understands how this particular team works.
Getting Started
The best first memory page is usually the thing your team repeats most often.
Open the Memory section in Dawn Web and create a page for a runbook, a decision log, a support policy, or an internal FAQ that keeps reappearing in chat. Give it a clear title, choose a sensible type, add tags that match how the workspace is organised, and keep the content clean enough that another teammate could trust it without additional explanation.
Once that page exists, look at which agents should be able to use it. Some agents should read all workspace memory. Others should only read pages that match specific tags. Making that choice deliberately is what turns memory from a document pile into a useful context system.
From there, the pattern is to let memory grow from real pressure points rather than ambitious planning. When a question comes up a second or third time, write a page. When a decision gets revisited, update it. When a runbook no longer reflects reality, revise it. The library builds itself around the work the team is actually doing, and a year of that rhythm leaves behind a workspace that is meaningfully smarter than when it started.
The goal is not to write everything down. The goal is to capture the context that your team should not have to keep retyping.