Most developers over-engineer their agent context. More files. More patterns. More overhead.
Building content agents at Windows scale, I evaluated memory-bank—a pattern for storing evolving context, decisions, and TODOs as files in a repository—and realized GitHub already had what I needed.
The key insight, in my opinion: git is great for memory, but GitHub’s primitives—Issues, PRs, Actions—often eliminate the need for additional context management patterns.
Some have used Anthropic’s memory MCP server—which provides a knowledge graph for storing entities, relations, and observations across sessions—for persistent context. But for my workflow, GitHub’s built-in features were enough.
The Context Architecture Decision
Here’s the background: I’m using GitHub Copilot with custom agents to help generate content. Each agent references copilot-instructions files that contain voice/style guidelines, platform-specific constraints, and other persistent knowledge. I use GitHub Issues and PRs for work tracking—content ideas, drafts in progress, publishing tasks.
When I came across memory-bank, it looked promising. The pattern stores evolving context, decisions, and TODOs as markdown files in the repo. It seemed like it might help agents maintain better context across sessions.
But I had to think through what problem it actually solves.
Breaking Down Context Types
Here’s what I realized when I mapped my actual context needs:
Stable, Persistent Knowledge
Things like voice guidelines, style constraints, and platform-specific formatting rules. These don’t change session-to-session. They’re the behavioral guardrails for agents.
My solution: Copilot instruction files (.github/instructions/ folder)
These files define how agents should behave. They’re rarely modified and apply consistently across all sessions. GitHub Copilot coding agent can access these directly, or you can use the official GitHub MCP server to make them available to other agents.
Work Tracking and State Management
Content ideas, drafts in progress, publishing tasks. These need visibility, assignment, status tracking, and collaboration features.
My solution: GitHub Issues and PRs
Issues give me structured work tracking with labels, milestones, comments, and status. PRs provide review workflow and merge tracking. Both integrate naturally with the git-based workflow.
Evolving Development Context
Decisions made during development, TODOs discovered mid-session, architectural choices that shift as you learn more. This is context that changes frequently and needs to persist across sessions.
My solution: I don’t need this for my workflow.
And that was the key insight.
The Realization
memory-bank shines when you have context that evolves across sessions—decisions made, TODOs discovered, architectural choices that shift over time. For my content workflow, GitHub Issues and PRs already handle the work tracking I need, and instruction files cover the stable behavioral guidelines.
That said, this is what worked for me. Your workflow might have different patterns. If you’re finding that important context gets lost between sessions—even for non-coding work—memory-bank might be exactly what you need.
My content workflow has a different shape. Each piece is independent but connected by common threads—voice, style, themes. Those threads are stable and live in instruction files. The individual pieces get tracked as Issues. The evolving context that memory-bank captures just isn’t part of my pattern.
Adding memory-bank would have given me:
- More files to maintain
- More complexity in my agent setup
- No actual benefit for my workflow type
Memory-Bank vs Memory MCP Server
Both memory-bank and the memory MCP server solve context persistence, but they take different approaches:
memory-bank uses structured markdown files in your repository. It’s file-based, queryable through git/GitHub, and integrates naturally with version control. Best for: development workflows where context should be tracked alongside code.
memory MCP server uses a knowledge graph with entities, relations, and observations. It’s database-backed, supports cross-tool sharing, and excels at storing structured facts about users and their context. Best for: conversational agents that need to remember information about users across sessions and tools.
For my content workflow, neither was necessary—GitHub’s primitives handled everything. But if you’re building conversational agents that need to remember user preferences and context, the memory MCP server provides capabilities GitHub doesn’t.
Tactical Guidance for Agent Systems
If you’re building agent systems, here’s how I’d think about context architecture:
Use Instruction Files When:
- Knowledge is stable and behavioral
- Guidelines apply consistently across sessions
- You’re defining how agents should behave
- Examples: voice/style guidelines, formatting rules, domain constraints
Use Issues/PRs When:
- Work needs tracking, state, and visibility
- Multiple items need prioritization and assignment
- You need collaboration features (comments, reviews)
- Examples: task lists, content ideas, work in progress
Use Memory-Bank (or Similar) When:
- Context evolves session-to-session
- You’re making decisions that inform future work
- Architectural choices need to persist
- Examples: coding projects, complex multi-session development, evolving system design
Use Memory MCP Server When:
- You need to remember facts about users across conversations
- You’re building a knowledge graph of entities and their relationships
- You want cross-agent memory sharing across different tools
- You’re building conversational agents that need persistent memory of user preferences
- Examples: personal assistant agents, chatbots that remember user context, multi-tool workflows with shared memory
Use Agent Memory/Context When:
- Information is session-specific and ephemeral
- Context only matters for the current conversation
- Examples: clarifications, temporary preferences, in-flight decisions
The Broader Lesson
The temptation when building agent systems is to add more patterns, more files, more structure. But more isn’t always better.
The right question isn’t “should I use this pattern?” It’s “what problem does this pattern solve, and do I have that problem?”
Match your context storage pattern to your workflow type. If your workflow is content creation with stable guidelines, you probably don’t need evolving development context. If you’re building complex software with shifting architecture, you probably do.
Sometimes simpler is actually better. I avoided adding file overhead that would have provided no real benefit for how I actually work.
What context patterns are you using for your agent workflows? Connect with me on LinkedIn to share your approach—I’m curious what patterns work for different workflow types.