DeerDawn ran on every session you started and you saw nothing. The brief loaded, your agent read it, and the only evidence was that the answers were better than they should have been. That is a strange thing to charge money for.

Starting today, every session opens with a card.

```
┌─ DEERDAWN ───────────────────────────────────────┐
│ Setup & API Testing               briefed 2m ago │
│                                                  │
│ Yesterday   merged PR #256 - two growth findings │
│ Open        Create the Google Ads conversion…    │
│ Remembering 37 decisions · 6 projects            │
└──────────────────────────────────────────────────┘
```

## Why it was invisible

DeerDawn installs a SessionStart hook. That hook has always had two output channels, and we were only using one of them.

One channel carries text into the model's context window. That is where your brief has always gone: current task, recent decisions, open questions, the paths that matter. Your agent reads it before it reads your message. It works, and it is completely invisible to you.

The other channel renders directly into your transcript. We had never written to it. So the fix was not to build a new surface, it was to start using the half of the pipe that was already installed.

## Why a card and not a summary

Your agent already tells you what it loaded, in prose, in its first reply. We could have leaned on that. We did not, for one reason: that path runs through the model, and anything that runs through the model is a suggestion. An agent that decides the brief is not worth mentioning simply will not mention it, and you will never know the difference.

The card renders before the model responds. It cannot be summarised away, reworded, skipped, or translated into something vaguer. It costs no output tokens. It is the same card every time, in the same place, whether your agent is chatty or terse.

On surfaces without hooks, like ChatGPT, Cursor, and Codex, the card comes through the agent instead, with instructions to print it verbatim. That path is less reliable, which is exactly why it is the fallback and not the mechanism.

## Three rows, and only three

The card is not a place to read your context. Your brief is already doing that, and if the card starts competing with it you will skim both.

So it reports what changed while you were gone, the one thread still open, and how much DeerDawn is holding for you. That third row is the only one that is not about today. It is the number that goes up.

## What the card is honest about

A memory product that you never audit has to be right, because a wrong brief is worse than no brief. It quietly poisons every session downstream and you have no way to trace the confusion back to its source.

So the card refuses to invent continuity. If nothing happened since your last session, it says nothing rather than dressing up an empty gap. If the totals query fails, the counter disappears instead of rendering a zero and implying you lost something. On your very first session it does not report a gap that never happened; it tells you what is about to start being captured.

## Nothing to do

There is no setting. Update the MCP server and the card appears at your next session start. The brief your agent reads has not changed.

DeerDawn has always briefed your AI at the start of every session. Now it shows you that it happened, in one card, before your agent says a word.

DeerDawn briefs your AI before every session. The new session-start card shows you it happened, rendered before your agent replies, with no setup.

DeerDawn Now Shows You the Brief at Every Session Start

DeerDawn Now Shows You the Brief

When an MCP client connects to a server, it asks for the tool list. The server replies with every tool it has, each one described in full, with a complete JSON schema for its arguments. All of that lands in the model's context window before you type anything.

We had never measured ours. When we did, the number was 36 tools and roughly 7,000 tokens.

That is a strange bill for DeerDawn to hand you, given that the entire product is about protecting your context window.

## The cost is charged every session

This is not a one-time setup cost. The tool list is sent on every connection, which means every session, forever. If you work across three tools, you pay it three times. It is the single largest fixed cost an MCP server imposes, and it is almost never measured because it never appears in a latency graph or an error log.

Token cost is only half of it. A model choosing between 36 tools makes worse choices than one choosing between 14, and DeerDawn had nine tools that all meant roughly "help me orient in this project." Near-synonyms are hard to pick between, and the model pays for the deliberation whether or not it picks correctly.

## The fix is not deleting tools

The obvious move is to delete the tools nobody uses. We could not, and the reason is worth explaining, because it applies to any MCP server that has shipped.

DeerDawn writes instruction blocks into files on your disk: CLAUDE.md, AGENTS.md, .cursorrules. Those files name tools as literal strings. So do the hook commands in your settings. Every one of those names is a published contract sitting on machines we do not control, and MCP has no alias or redirect mechanism. Rename a tool and you break every install that already has the old name written down.

So we separated two things that had always been the same thing: which tools we ADVERTISE, and which tools we can CALL. Every one of the 36 names still works. We just stopped listing them all.

## Advertise what the session might need

The list is now driven by state rather than by inventory.

Setup and authentication tools appear only while you are signed out. Once you are signed in they are dead weight, because setup is something that happens once, not something a session does. Bootstrap tools, the ones for creating and importing a project, appear only until this workspace has a project bound. Skills tools appear only if you actually have skills. The core loop, the twelve or so tools a working session genuinely uses, is always there.

The server declares its tool list as dynamic, so when authentication resolves mid-session it tells the client to re-read the list and the surface narrows on the spot.

Steady state went from 36 tools and about 7,000 tokens to 14 tools and about 3,553. Roughly half, given back to you on every session.

## Fail toward showing too much

There is a timing problem worth naming. The tool list is requested immediately after the connection opens, sometimes before we know whether you are signed in or which project you are in.

When we do not know, we send everything.

Hiding a tool the session needed produces a broken session with a confusing failure. Sending a list that is briefly too large produces the situation we were already in. Those are not symmetric, so the default is not the elegant one, it is the safe one.

## What we measured, and what we did not

The 49% cut is real and it is guarded by a test that fails the build if the payload grows past budget. But the count was the easy half. The remaining 3,553 tokens are mostly long descriptions and wide argument schemas on a small number of tools, and trimming those is the next piece of work.

If you run an MCP server, the useful exercise takes five minutes: connect to it, capture the tools/list response, and divide the byte count by four. Whatever that number is, your users pay it every session.

Every MCP server sends its full tool list at the start of every session. We measured ours, found 7,000 tokens of pure overhead, and cut it by half.

Every MCP server sends its full tool list each session, straight into the context window. How we measured DeerDawn at 7,000 tokens and cut it by half.

MCP Tool List Token Cost: We Cut Ours From 7,000 to 3,553

Your MCP Server Is Charging You 7,000 Tokens Before You Ask It Anything

AI coding agents are getting better at splitting work across subagents. The handoff is still the weak point. A worker either receives too little context and repeats discovery, or receives the entire conversation and burns tokens sorting through information it does not need.

## A brief for one job

The new build_subagent_brief tool turns DeerDawn’s main project brief into a smaller handoff for one concrete assignment. The orchestrator provides the task, role, deliverable, success criteria, focus paths, and token budget. DeerDawn adds the most relevant project decisions, constraints, debugging notes, commands, and known files.

## Built for isolated subagents

Each generated brief starts with a stable DeerDawn marker and ends with an explicit return contract. That lets an orchestrator launch the worker without forwarding the whole conversation. The worker knows what to change, what success means, where to work, what to avoid, how to verify the result, and what to report back.

## Token efficient by design

Subagent briefs are deterministic and token-budgeted. DeerDawn ranks project-scoped context, removes duplicate paths, redacts secrets, neutralizes prompt-injection-like text, and reports how much source material was omitted. The first release defaults to a roughly 250-token package and supports budgets from 120 to 600 tokens.

## Available through local and hosted MCP

The same build_subagent_brief tool is available through DeerDawn’s local MCP server and hosted remote MCP endpoint. Updated DeerDawn instructions also tell capable orchestrators to build one brief per concrete subtask and pass only that brief into an isolated worker.

## The result

The main agent keeps the broad project picture. Each subagent gets the smallest useful slice of it. That means less repeated prompt context, fewer irrelevant details, and a much clearer contract between the orchestrator and the worker.

DeerDawn now gives each AI coding subagent a small, task-specific brief instead of copying the orchestrator’s entire project context.

DeerDawn now builds token-efficient, task-scoped briefs for AI coding subagents with relevant files, decisions, constraints, verification, and provenance.

Subagent Briefs for AI Coding Agents Are Live in DeerDawn

Subagent Briefs Are Live in DeerDawn

A useful AI subagent brief is not a compressed transcript. It is a task contract. The worker needs enough project context to act correctly, but every unrelated detail makes the assignment harder to parse and more expensive to run.

## What an AI subagent needs

Start with the role and concrete deliverable. Then define success, name the likely files or folders, include only decisions and constraints that change the implementation, state known landmines, and give the worker a verification command or check. Finish with exactly what the worker should return to the orchestrator.

## What to leave out

Do not forward the entire chat, every historic decision, the complete repository map, or broad product background that does not affect the assignment. The orchestrator should retain that global context and package only the relevant slice for each worker.

## Why retrieval matters

Handwritten worker prompts often miss the one constraint that matters. A project context system can rank known paths, current decisions, recurring rules, blockers, debugging findings, and commands against the task. Provenance makes the package inspectable, while a fixed token budget forces relevance.

## A reliable subagent brief format

Use consistent sections: role, deliverable, success criteria, project facts to know, files to work in, landmines, verification, and return format. Consistency helps the worker find instructions quickly and helps the orchestrator compare results across parallel tasks.

## How DeerDawn automates it

DeerDawn’s build_subagent_brief MCP tool takes a task and optional role, deliverable, acceptance criteria, focus paths, verification steps, and token limit. It selects project-scoped context, sanitizes it, deduplicates paths, and returns a compact brief ready for an isolated worker.

## The orchestration pattern

Keep one rich project brief at the orchestrator level. Generate a separate small brief for every concrete subtask. Launch each worker with no conversation history beyond its brief, then merge the worker’s findings or changes back at the orchestrator.

A practical way to brief AI subagents with the files, constraints, decisions, and success checks they need without sending the full prompt.

Learn what to include in an AI subagent brief: role, deliverable, relevant files, project constraints, success checks, verification, and return format.

How to Give AI Subagents Project Context Without Wasting Tokens

How to Give AI Subagents the Right Project Context

The short answer is that ChatGPT does not reliably hold full project state across all the work sessions where serious development happens. If you want it to feel like it remembers context, you need an external system for project state, not just a better prompt.

## Why this keeps happening

ChatGPT can follow the current thread well, but project work is bigger than one thread. Your stack changes, your current task changes, and your decisions evolve. A single chat does not automatically become your source of truth.

## What people usually try

People pin a summary at the top of the conversation, keep a giant reusable prompt, or paste a project brief into every new chat. Those tactics help, but they are still manual and they drift fast.

## What works today

The practical approach is to keep project context outside the chat and make every tool read from that shared source. That means your current task, stack, recent decisions, and open questions stay consistent even when you switch sessions.

## DeerDawn workflow

With DeerDawn, you create one workspace, connect MCP in Claude Code, Codex, or Cursor, and let each tool pull the same project context on demand. You stop treating one chat thread like your memory system.

## Bottom line

If you need reliable project memory, stop optimizing the prompt alone. Keep one brief so the tool can start from the right state every time.

Why ChatGPT keeps losing project state, what actually helps, and how to stop repeating yourself between sessions.

A plain-language guide to keeping ChatGPT aligned with your project context across sessions and tools.

How to Make ChatGPT Remember Context for Real Project Work

How to Make ChatGPT Remember Context

Claude is strong inside an active conversation, but project continuity usually breaks when you open a fresh session or switch tools. That is why teams feel like Claude "forgets" even when the current thread was productive.

## Why Claude feels forgetful

Project memory is not just facts about the codebase. It includes your current task, recent decisions, constraints, and the tradeoffs already made. When that context lives only in one thread, a new chat starts cold.

## What helps a little

A clean AGENTS.md or CLAUDE.md file helps. A short project brief helps. Reusing a consistent setup prompt helps. None of that solves cross-tool continuity by itself.

## What helps a lot

Put your working context in a shared system that Claude can read at session start. That turns context from something you restate into something the tool loads.

## DeerDawn workflow

DeerDawn can import your local context files, store the current workspace state, and expose it to Claude Code through MCP. The result is that Claude starts with the same workspace summary that Codex or Cursor can also use.

## Bottom line

Claude memory between chats gets better when you stop treating chat history as the only memory layer.

What Claude remembers well, where it breaks down, and how to keep your project state intact between sessions.

A practical guide to keeping Claude aligned with your project state between chats and across coding tools.

Claude Memory Between Chats: Practical Ways to Keep Project Context

Claude Memory Between Chats

If you use more than one AI tool, the core problem is not just memory. It is handoff. Every tool needs the same project state, or you waste time rebuilding context in each one.

## What breaks in multi-tool setups

One tool knows the current task. Another has the best code edits. A third has your product reasoning. Without one brief every tool reads, each handoff throws information away.

## The simple model

Keep one workspace record with the project summary, task, recent decisions, stack, and open questions. Let each AI tool read that same record instead of inventing its own partial memory.

## Where MCP helps

For coding tools, MCP is the cleanest current path because it lets the tool pull structured context when needed instead of relying on prompt stuffing alone.

## DeerDawn workflow

DeerDawn gives Claude Code, Codex, and Cursor access to the same workspace through MCP today. That means the project handoff happens through one shared brief instead of manual copy-paste.

## Bottom line

If you want AI tools to feel connected, optimize the handoff layer, not just the prompt inside one tool.

A simple pattern for keeping Claude, ChatGPT, Codex, and Cursor in sync instead of re-explaining your project every time.

Learn how to keep Claude, ChatGPT, Codex, and Cursor briefed with one shared project brief.

How to Share Context Between AI Tools

The best AI workflow setup for coding is not about finding one perfect tool. It is about keeping your project state stable while you move between tools that are good at different parts of the job.

## What a good workflow needs

You need one place for project context, one fast setup path for the tools you use most, and one reliable way to keep your current task and decisions visible.

## A practical default stack

Use a shared workspace summary, connect one coding tool first, confirm first sync, then add other tools after the core flow works. Do not start by trying to automate every surface at once.

## The mistake to avoid

Most people over-invest in giant prompts and under-invest in persistent project context. The result is a fragile workflow that works only when the same chat stays open.

## DeerDawn workflow

Create one workspace, connect DeerDawn MCP to Claude Code, Codex, or Cursor, confirm that the tool can read your project state, and then expand from there. That gets you to first value faster than trying to perfect every tool at the same time.

## Bottom line

The best setup is the one that gives you continuity first and convenience second.

The practical setup that keeps your coding tools aligned without constant prompt resets and manual handoffs.

A practical AI coding workflow that keeps project context stable across Claude Code, Codex, and Cursor.

Best AI Workflow Setup for Coding Teams and Solo Builders

Best AI Workflow Setup for Coding

Persistent AI memory for real projects means the tool can start from your actual working state, not just from whatever survived in the last conversation window.

## The wrong mental model

People often think persistent memory means a chat remembers facts forever. That is not enough for project work. You need the right facts, updated at the right time, in the right tools.

## What persistent memory should include

At minimum: project summary, current task, stack, recent decisions, open questions, and linked project files. That is the layer that lets an AI continue real work instead of restarting discovery.

## What manual systems miss

Static notes go stale. One-off prompts get lost. A single thread cannot represent all the current state that matters across tools and sessions.

## DeerDawn workflow

DeerDawn keeps your workspace context as one brief and exposes it through MCP for coding tools. That turns persistent memory into a system you can use, not just an aspiration.

## Bottom line

For real projects, persistent memory is a context system problem, not a chat-thread problem.

What persistent AI memory actually means in day-to-day work, and why project state matters more than chat history.

Understand what persistent AI memory means for real project work and how to keep context across tools.

AI session memory writing