How are people handling context across different AI coding tools?

[Pat2 (Pat)]

I’ve been switching between a few AI coding tools recently and the context/memory part is starting to annoy me.

Claude Code, Codex, Cursor, Windsurf, etc. all seem to have slightly different ways of handling project context, rules, memories, notes, and session history.

For people who use more than one of these seriously, what’s your current setup?

Do you just keep markdown files in the repo, use rules, use an MCP memory server, Obsidian/Notion, or something custom?

Mostly curious what actually works in daily use, because I feel like I keep re-explaining the same things between tools.

[deanrie]

Hey, good question. Everyone really builds their own Frankenstein setup here. I’ll share what usually works and what I see from users.

Portable base setup (minimum pain when switching tools)

• Keep an AGENTS.md at the repo root. Codex, Claude Code, Cursor, and some others respect it. It’s a good place for what the project is, how to build and test it, and coding conventions. Cursor reads it automatically.
• Keep commands and scripts in package.json or Makefile or justfile, not in prompts. Then have AGENTS.md link to them, so there’s less drift.

Cursor-specific, but compatible in spirit

• Use .cursor/rules/*.mdc for more structured rules with globs. They apply automatically based on file type. Docs: Rules | Cursor Docs
• Use Memories for facts that should survive across sessions: Overview | Cursor Docs
• Use MCP servers for external state: Model Context Protocol (MCP) | Cursor Docs. This can also include memory servers like Mnemosyne: A local, persistent memory MCP server for Cursor if you want shared persistent memory across agents and tools.

Practical observation
Most users who actually stop rewriting the same stuff keep a single source of truth in the repo, like AGENTS.md plus links to scripts and docs. Then they keep tool-specific files as a thin layer on top. Markdown in Obsidian or Notion is nice for personal notes, but as agent context it gets outdated fast. I’ve also seen this CLI for drift checks, which helps catch when instructions don’t match the real code: Built a small CLI to detect AGENTS.md drift (missing commands, dead paths, conflicting nested files)

Curious what others are doing. Is anyone actually running an MCP memory server in production across tools?

[Pat2 (Pat)]

Thanks Dean, this is really helpful.

The AGENTS.md + real scripts/docs as source of truth makes a lot of sense. I’ve noticed the same thing: once context lives only in prompts or memory, it gets stale fast and then agents confidently follow old instructions.

The drift-check idea is especially interesting. In your experience, what breaks first?

• AGENTS.md gets stale
• tool-specific rules diverge
• old memories become wrong
• commands/paths change
• agents don’t load the right context at all

Also curious: have you seen anyone actually run MCP memory across multiple tools in a reliable way, or is it still mostly experimental/local setups?

I’m mostly trying to improve my own workflow right now, so practical ugly details are more useful than polished theory.

[deanrie]

Great clarifying questions.

In practice, things usually break in this order:

1. Commands and paths change. This is the most common case. Someone renames a script in package.json, moves a config file, switches from pnpm to bun, but AGENTS.md still has the old instruction. Agents follow it with confidence, and you waste an extra cycle trying to figure out why the build command doesn’t work.
2. AGENTS.md gets outdated. This is second place. Users update code and forget the docs. The drift utility I mentioned earlier exists for exactly this reason, it’s the most boring and most common failure mode.
3. Old memories become wrong. It happens, but usually with a smaller blast radius. A memory like “we use Jest” survives a migration to Vitest and quietly poisons recommendations. It’s worth cleaning up memories every few weeks.
4. Rules tied to specific tools drift apart. This is a slow burning issue. You tweak a rule for Cursor and forget to mirror it in the equivalent for Claude Code or Codex, and different tools start behaving differently. This is less “it broke” and more “why does Cursor do X, but Codex does Y”.
5. Agents don’t load the right context. This is more of a constant background tax than a sudden break. Usually fixed with more explicit glob patterns in .cursor/rules/*.mdc or by passing files directly in the prompt.

If I had to pick one rule of thumb, anything that duplicates info already in code or config will go stale over time. Anything that just points to that info tends to stay correct.

About MCP memory shared between tools, honestly right now it’s mostly experimental or one off setups. I see users run local stuff like Mnemosyne: A local, persistent memory MCP server for Cursor or Cursor-memory — Persistent, Searchable Memory for Cursor AI and get real value within a single workflow. Cross tool, reliable, team memory is a totally different beast. MCP support quality varies across tools, and memory that one tool writes and another reads only works if both are disciplined about when to write and when to retrieve, and in practice that isn’t there yet. I haven’t seen a setup I’d call production grade across multiple tools. If anyone reading has one, I’d genuinely love to hear about it.

For your workflow, the boring answer will probably win: AGENTS.md plus scripts as the source of truth, a small drift check in CI, clean up memories from time to time, and treat MCP memory as a nice bonus, not the foundation of the system.

[neverinfamous (Chris LeRoux)]

GitHub - neverinfamous/memory-journal-mcp: Secure AI Memory with Dynamic Project Detection,...

https://hub.docker.com/repository/docker/writenotenow/memory-journal-mcp/general

[jflynt76 (Jeffrey Flynt)]

@deanrie

That constant background tax on .cursor/rules/*.mdc maintenance, especially in monorepos or when jumping between Cursor and chat clients like Open WebUI, is exactly why we built Tenure: GitHub - tenurehq/tenure: Persistent AI memory that follows you across every tool, session, and interface. Fully local. · GitHub

When you rely on MCP for cross-tool memory, you’re forcing the model to make a cognitive decision to call a tool and look for context that may or may not even be there. Because agent architectures are optimizing for low latency and trying to stream a response as fast as possible, that voluntary retrieval step inevitably gets dropped or skipped in practice.

We realized trying to force different agent architectures to coordinate memory retrieval at the model level is a losing battle right now. Instead, we dropped down to the network layer and built a local proxy at localhost:5757/v1. You point your tools (Cursor, Claude Code, Open WebUI) at the same proxy endpoint, and relevant context is injected directly into the payload before the LLM ever sees it. They all interface with a single, unified belief store without adding cognitive or latency overhead to the model itself.

Here’s how we handle the breaking points you listed, specifically around hierarchical scope:

Replacing the .cursorrules / AGENTS.md Maintenance Loop (Points 1 & 2): Tenure automatically extracts beliefs by watching your chat sessions and generated code. Switch from pnpm to bun while brainstorming in Open WebUI or Cursor chat and it captures that shift implicitly. It scopes it correctly: a package manager swap becomes a global preference while a specific build script or framework constraint stays tied strictly to that file.

Solving Cross-Tool Drift (Point 4): Tighten an auth pattern inside a Cursor chat session for packages/auth and Claude Code operating in that same directory inherits that constraint on its very next prompt, because it’s pulling from the exact same scoped proxy layer.

Since Cursor is built on VS Code, the extension installs directly via Open VSX. We just shipped a UI update that brings alot into the editor itself:

• A sidebar showing exactly which beliefs are active for your current workspace and per file
• Ability to create beliefs manually scoped to a specific file

The proxy engine, VS Code extension, and the new sidebar UI are all live today. The one piece still in progress is a native Cursor plugin that handles belief extraction on the client side without routing through the proxy.

Would love to hear your thoughts on the proxy-layer approach compared to the MCP setups you’ve evaluated.

[deanrie]

Interesting approach, thanks for laying it out.

If we talk about the pattern itself (a network-layer proxy that injects context into the payload, unlike MCP where the model has to decide to call a tool) it makes sense. I agree that relying on the model to trigger retrieval is brittle in practice. With streaming and latency-focused tuning, agents often skip voluntary tool calls, especially when the context doesn’t look critical for the current step. Taking that decision away from the model and moving it closer to the transport layer is a valid direction.

A few things that usually become bottlenecks with this approach:

1. Trust and audit. When context is injected before the model sees it, the user loses visibility into why the model answered the way it did. For personal workflows that’s fine, but for teams you usually need a log of what was added to the prompt and why.

2. Scope leakage. A belief pulled from one session (for example, “switched to bun”) can be wrong in another repo or branch. Hierarchical scoping helps, but the line between global vs file-level vs branch-level is subtle, and mistakes show up fast to the user.

3. Compatibility with providers and features. Cursor, Claude Code, and others use different endpoints, custom headers, and sometimes streaming with their own extensions. A proxy sitting in the middle has to forward all of that correctly, or you lose things like tool use, attachments, and image inputs.

4. Privacy and enterprise. Any local proxy between the client and the API runs into Privacy Mode policies, SSO, and network logging rules on the team side. For personal use it’s not an issue, but for team rollout it’s always a separate conversation.

Compared to MCP, I like that MCP makes the model explicitly aware of the tool and it can explain why it didn’t call it. Proxy injection wins on reliability but loses on transparency. I don’t think this is an either-or. A realistic setup a year from now is probably hybrid. Static context (preferences, conventions) gets injected at the transport layer, while dynamic context (searching logs, history) stays model-driven via MCP.

And one more request. Let’s keep this thread focused on discussing approaches in general, not a specific product. If you want to share more about Tenure, please start a separate topic in Discussions. That’s a better fit and it’ll reach the right audience.

[jflynt76 (Jeffrey Flynt)]

@deanrie

These are fair considerations and worth thinking through, but I’d frame them slightly differently:

Trust and audit: This is only a concern if logging isn’t built into the proxy layer. If it is, you actually get more visibility than MCP, not less. Every injection is explicit and recordable rather than dependent on whether the model chose to call a tool and whether it accurately reports why.

Scope leakage: With structurally guaranteed scoping and user control, this becomes an implementation quality question rather than a fundamental limitation of the pattern. The failure mode you’re describing is real but avoidable by design.

Compatibility: Agreed this is a real engineering challenge. Though I’d note “has to be handled correctly” applies equally to MCP. Neither approach gets a free pass on integration work.

Privacy and Enterprise: This depends entirely on the deployment model. If we’re talking about an IT-sanctioned rollout rather than a rogue developer installation, the proxy pattern is actually an enterprise advantage. Right now, managing SSO, network logging, and DLP across five disconnected AI tools is a compliance nightmare. An IT-deployed local proxy acts as a single governance gatekeeper on the machine. It handles corporate auth, injects enterprise keys securely, and logs traffic for auditing before anything ever leaves the box, all while being whitelisted by internal security policies.

On the hybrid direction, I’d actually push back. The assumption that MCP is needed for “dynamic retrieval” comes from a mental model where AI context is treated as just-in-time document search. If a system has to pull gigabytes of raw logs mid-stream, that’s a failure of context design, not a gap the model should be patching with tool calls.

A well-built proxy layer isn’t a blind payload stuffer. It’s a stateful belief store that continuously extracts meaning from chat history, code changes, and environment state in the background, condensing unbounded raw data into compact, high-density constraints. The goal is to make the transport layer intelligent enough that voluntary mid-flight retrieval becomes unnecessary. That’s a higher bar, but it’s the one worth aiming for.

[yourpropertyexpert (Mark Harrison)]

I have two files and a directory.

1: AGENTS.md

This is widely support, except by Claude. I’l come back to Claude, but for the AGENTS.md, it has about 200 lines of direct instructions, and then a section that points to other documentation.

I’ve included a snippet from that section below.

## Related Documentation

This document provides an overview of the project structure and development guidelines. For detailed guides on specific topics, refer to the following documentation files in the `devprompts/` directory:

* **`devprompts/react-component-architecture.md`** - Detailed guidelines for React component architecture, file organization, hooks, utilities, and refactoring patterns for the `src/front/react-maintainlibraries` application.

* **`devprompts/react-maintain-libraries-styling.md`** - Comprehensive styling guidelines for the React maintain libraries app, including tab navigation structure, color coding, badge states, implementation examples, and visual hierarchy.

* **`devprompts/api-creation-guide.md`** - Complete guide for creating REST API endpoints, including authentication classes, step-by-step creation instructions, parameter validation, error handling, response formats, server-side processing preference, and testing examples.

2: The devprompts directory.

This contains about 20 files, typically 4-500 lines long, that go into a lot more detail about that particular task.

They reference each other where needed.

Below is a snippet of the first few lines of the react-component-architecture one:

# React Component Architecture Guidelines

**When to use:** Creating or modifying React components in `src/front/react-maintainlibraries` (structure, hooks, columns, refactors).

**Summary (read first):**

- Component files (`.jsx`) should primarily contain JSX and composition; no API or complex logic in `.jsx`.

- Logic, state, and API calls go in `hooks/`; column definitions in `columns/`; shared UI in `components/`; constants in `utils/`.

- Components over 500 lines should be refactored; extract repeated patterns into hooks or utilities.

- Custom hooks must start with `use`; use the directory structure and patterns described below.

This document provides **code organization and architecture guidelines** for React components in the `src/front/react-maintainlibraries` application. These guidelines enforce separation of concerns, maintainability, and code reusability.

**Note:** This document focuses on code structure, file organization, hooks, and refactoring patterns. For visual design, styling, colors, and UI patterns specific to the maintain libraries app, see `devprompts/react-maintain-libraries-styling.md`.

[… etc …]

3: CLAUDE.md

The CLAUDE.md specification allows an “import” feature using @, so most of this is just importing the AGENTS.md

However, there are a few Claude-specifics in there, mainly around doing the git branch stuff / CI inspection stuff automatically, and updating our Trello.

As “things other than Claude” have got more agentic, I’ll probably move some of this to AGENTS.md

@AGENTS.md

## Workflow Instructions

When working on any task in this repository, you **must** follow the steps in:

- [devprompts/all-tasks.md](devprompts/all-tasks.md) — standard git workflow for every task (branching, committing, CI, PR)

- [devprompts/tasks-from-trello.md](devprompts/tasks-from-trello.md) — additional steps when the task originates from Trello (assigning, moving card, attaching PR, moving to Review)

[Robert_Howard (Tugg)]

I made a skill to convert other repoes to cursor. In the annexes folder is a lot of condensed info on how the different platforms rules work.

I don’t usually stop over here, caught a ping I don’t know the rules as far as posting repoes but here’s a discord link to the cursor discord showcase, where were allowed to post work.

Discord - Group Chat That’s All Fun & Games

[deanrie]

Hey @Robert_Howard, I checked out cursor-landing-v3 and it’s solid. The dual-host pattern via .cursorignore, so Cursor won’t pick up AGENTS.md or GEMINI.md that were left for other hosts, is exactly the scenario the OP started the thread with.

One request: please post the core idea directly in the forum. Right now the post only has a Discord link, and that doesn’t work well since users need to log in, scroll to find the message, and in six months it might be buried. A forum thread stays searchable for years. 3 to 5 sentences is enough: what the skill does, what scenario it’s for, and what’s special about the dual-host setup. Keeping the GitHub link next to it is fine, it reads as “here’s the implementation.” If you have annexes with the platform rules breakdown you mentioned, please add them too, that kind of comparison isn’t in the thread yet.

And overall, thanks everyone for the discussion. If anyone has a cross-tool setup that actually survived a couple months of active development without constant rewrites, please share more details. That’s the part with the least real-world experience so far.

[Robert_Howard (Tugg)]

What your repo already has: AI tool leftovers and what to do with them

If your repo has been touched by more than one AI coding tool - or you’re switching to Cursor from something else - there’s already a layer of agent files sitting in it. Cursor Landing runs a Phase 0 scan before writing anything new, so nothing gets overwritten without your say-so.

The table below covers what each tool leaves behind and how the skill handles it.

Tool	Persistent instructions	Run-state to trim	What the skill does
Cursor	.cursor/rules/*.mdc, .cursorrules [1], AGENTS.md	-	Write target - this is what the skill creates/updates
OpenAI Codex	AGENTS.md, AGENTS.override.md	PLANS.md (session plan)	AGENTS.md shared standard - default: leave if Codex still active
Claude Code	CLAUDE.md, .claude/settings.json	-	Add @AGENTS.md + @CONTEXT.md imports if missing; flag .mcp.json overlap
Gemini CLI (pre-Antigravity, .gemini/ layout)	GEMINI.md, .gemini/settings.json	-	AGENTS.md portable; GEMINI.md Gemini-only - see note below
Antigravity 2.0 (.agents/ layout, June 2026+)	AGENTS.md, GEMINI.md, .agents/rules/	.agents/threads/	Dual-host: leave both; writes .cursorignore to block bleed-over
Windsurf	.windsurf/rules/*.md, .windsurfrules [1]	-	Port to .cursor/rules/*.mdc with matching globs on merge
Amazon Kiro	.kiro/steering/*.md, .kiro/specs/**/requirements.md, design.md	.kiro/specs/**/tasks.md	AGENTS.md shared if present - default: leave
GitHub Copilot	.github/copilot-instructions.md, .github/instructions/*.instructions.md	-	Scoped rules → separate .cursor/rules/*.mdc per glob on merge
Cline	.clinerules, .clinerules/	memory-bank/activeContext.md, progress.md	projectbrief.md → glossary source for CONTEXT.md
Augment Intent	.augment/settings.json	.augment/settings.local.json (may contain secrets)	BYOA: also scan the underlying host (Codex, Claude, etc.)
Amp Neo CLI	.amp/plugins/	.amp/threads/ (conversation dumps)	Inventoried; nothing promoted to AGENTS.md or CONTEXT.md

[1] Legacy single-file format - inventoried and ported to scoped .mdc files on merge rather than left as a duplicate root rule.

Gemini / Antigravity note

Old repos running Gemini CLI use the .gemini/ layout. Repos already on Antigravity 2.0 use .agents/. Both layouts can coexist in the same repo during migration - Gemini CLI deprecation is June 18, 2026, so most repos you encounter through mid-2026 will still have .gemini/. The skill asks which product is in use before touching anything.

For Antigravity 2.0: AGENTS.md wins over GEMINI.md on conflicts (that is the 2.0 behavior - older blog posts say the opposite and are wrong). Cursor-facing rules go in .cursor/rules/; GEMINI.md keeps Google-only config.

Hooks and MCP (not edited by the skill)

1. Hooks and plugins - Codex hooks.json, Claude settings.json hooks, Kiro .hooks/, Amp .amp/plugins/ - are listed in the Scan Report but not edited. You decide what to do with them.

2. MCP configs are cross-tool and frequently duplicated. The same server can appear in .cursor/mcp.json, .mcp.json, .github/mcp.json, .kiro/settings/mcp.json, and .agents/mcp_config.json. The scan flags duplicates and secrets; it does not auto-merge them.

Run /cursor-landing in Cursor Agent at your repo root. Install: cursor-landing-v3

[Robert_Howard (Tugg)]

https://github.com/rphoward/cursor-landing-v3

[Robert_Howard (Tugg)]

I can’t seem to post a markdown that renders for the annex comparison. upload won’t accept markdown. Unfamiliar with this forum format.

[Robert_Howard (Tugg)]

I can’t get this forum to reliably do any markdown or html that composer or sonnet produces. If you are a mod and want to fix it, please do. Neither the help files nor the models are helping. I’m totally unfamiliar with Discourse.

[Robert_Howard (Tugg)]

Thanks for the help Dean! BTW I developed this to help with the referral program. A significant pain point of resistance is technical debt. With some recent feedback I added the the cursorindexingignore workups to solve the secondary pain point of running out of quota in 4 or 5 days because of unneeded cache bloat.

If the readme sounds like its fit for shillin, it IS!! Shillin for referrals.

If you want to help your referrals, offer them the skill as a gesture of goodwill.

[Sashaktn]

I ran into the same issue on larger projects — AI agents rereading too much context, losing architectural intent, and burning through requests/tokens very quickly.

I ended up building a VS Code/Cursor extension called Artifacto:
Artifacto on VS Code Marketplace

Artifacto creates local semantic artifacts for the project:

• module purpose
• dependencies
• known risks
• “dont_touch” areas
• project trajectory
• recent changes/history

The important part is that the artifacts do not affect the actual codebase or runtime logic. They work as a structured memory/navigation layer for AI coding agents.

The goal is reducing blind context exploration and helping agents understand the project before touching files.

Artifacts are just local files, so technically any tool/agent can read them — Cursor, Claude Code, OpenCode, etc.

Right now it’s in public beta and fully local-only (no code sent anywhere). Mainly testing whether this improves large-project workflows and reduces unnecessary context usage.

[neverinfamous (Chris LeRoux)]

I’ve been building an MCP called Memory Journal and it’s what I use for my own projects.

I originally started it because I was frustrated with AI constantly losing context between conversations. Most memory MCPs I tried felt more like searchable note databases, which is useful, but I wanted something that could help an agent understand the current state of a project, why decisions were made, what was tried before, and what still needed attention.

Over time it evolved into a larger project intelligence system with things like semantic search, session handoffs, project briefings, GitHub integration, knowledge graphs, team collaboration features Like Hush, and a secure Code Mode for token-efficient multi-step operations.

One thing I recently added is importance-based auto-pruning. Long-running memory systems have a tendency to accumulate a lot of low-value information over time, so Memory Journal can automatically identify and remove older, low-significance entries while preserving important architectural decisions, milestones, and other high-value context. The goal is to keep memory useful rather than simply making it larger.

The feature I personally rely on most is the customizable session summary/briefing system. When a new AI session starts, it can quickly load a concise summary of project state instead of me having to reconstruct context from previous chats.

It’s open source and still evolving, but it’s been a huge productivity boost for my own development workflow. I am working on v8.1.0 as we speak.

Sample session briefing confirmation report:

Briefing loaded — memory-journal-mcp

1 active flag(s) — review before proceeding. fyi → @chris: flag:fyi — @chris: This is a test flag to verify the Hush Protocol and briefing delivery system.

Context	Details
GitHub	neverinfamous/memory-journal-mcp main · Git: Clean CodeQL
Tracking	Issues: 0 open PRs: 1 merged MS: Hush (v7.0.0) (100% )
Journal	207 entries · Team: 34 Latest: #434 (personal_reflection): CodeMode search marker XYZ789 Summary: #82 (retrospective): ## Session Summary: Error Matrix & Zod Sweeps (Phase 29) ### Accomplished - Executed the comprehensive Phase 29 Error…
System	v8.0.1 · 0 resources · 19 prompts 79 tools (filter: codemode (1/79) (100KB cap) — use mj.* API) memory://metrics/summary Tests: 1782+391 E2E (91%) · Lint & Typecheck: GEMINI.md (6 KB) · 58 skills code-map (test-server/code-map.md) · tools (test-server/tool-reference.md) 2026-06-01 06:58 EDT
Config	mode: readonly · level: standard team: yes · github: yes IO: 2 roots · registry: adamic, adamic-blog, db-mcp +3
Insights	17 · 7 · 23794 · 143 (14d) Copilot: 2 reviewed · 0 approved -100% vs. last period (0 entries)
Graph	19 relationships Top: blocked_by: 2, resolved: 3, caused: 2 (view: memory://graph/recent)
Unreleased	(1d) 7 added · 3 fixed
Workspaces	adamic: C:\Users\chris\Desktop\adamic adamic-blog: C:\Users\chris\Desktop\adamic-blog db-mcp: C:\Users\chris\Desktop\db-mcp memory-journal-mcp: C:\Users\chris\Desktop\memory-journal-mcp (active) mysql-mcp: C:\Users\chris\Desktop\mysql-mcp postgres-mcp: C:\Users\chris\Desktop\postgres-mcp

---

GitHub - neverinfamous/memory-journal-mcp: Secure AI Memory with Dynamic Project Detection,...

https://hub.docker.com/repository/docker/writenotenow/memory-journal-mcp/general

[Sashaktn]

Artifacto v0.34.0 — completely free for cursor

I have prepared the final free release of Artifacto.

Artifacto improves project navigation and search by creating efficient project artifacts that provide AI agents with relevant context. This approach is often more effective than having agents start by reading large portions of the project.

The plugin also tracks file-reading statistics and includes agent control features that help prevent unplanned code changes, ensuring agents follow the intended workflow.

GitHub: GitHub - elakstron/Artefacto_labs: Save tokens. Improve context. Reduce AI mistakes · GitHub
Download: Release Artifacto v0.34.0 — Fully Free · elakstron/Artefacto_labs · GitHub

[Patdolitse (Pat)]

Honestly my “system” started as pure laziness. I got tired of re-explaining my whole project to every new tool like it just woke up from a coma.

So now before I jump tools (Claude Code → Cursor, or just spin up a fresh agent because the old one got loopy), I make the current agent write its own goodbye letter — a HANDOFF doc. Not a 500-message chat dump nobody will read. Just: here’s where the project is, here’s the plan, and here’s a little map of the important docs so you’re not digging blind. The next agent’s entire onboarding is “read this first, then carry on.” Works shockingly well for something this dumb.

Two reasons it beat every fancier thing I tried:

• Tools don’t share brains. Every tool’s built-in memory is its own little walled garden. A plain text file is the one language all of them speak, so the context actually survives the jump instead of dying with the tab.
• • No stale leftovers. The doc gets rewritten at every handoff, so it’s always “today,” not “what I was thinking on Tuesday.” Old one just gets steamrolled.
• Two things I learned by faceplanting first:
• Keep a tiny always-on brief separate from the big handoff — like 3 lines, who I am + what I’m working on. Otherwise the agent shows up completely blank and you’re back to square one before it even opens the doc.
• • Make the notes findable again. After a long convo gets compacted, the agent will absolutely lose track of which doc was which — it needs to be able to go “wait, where’d that go” and actually find it.