Feature Request: Persistent Agent Knowledge Bases Turn Subagents into Long-Lived Engineering Teammates
I think Cursor is moving toward a very interesting phase where we can redefine multiple agents that can orchestrated for different parts of the development process.
One layer that feels missing is persistent agent expertise.
Today, we can give an agent a prompt, skills, context, tools, and a plan for a specific task. But a great software engineer is not just the sum of their current context and instructions.
A great engineer develops experience over time:
- They remember decisions made in previous projects.
- They learn the conventions of a codebase.
- They understand why certain approaches failed.
- They develop preferences and heuristics.
- They accumulate domain knowledge.
- They know how other engineers on the team work.
- They get better because every task adds to their experience.
I think Cursor could make this a first-class primitive.
From “Agent” → “Persistent Engineering Teammate”
Imagine being able to create dedicated agents such as:
Tom — Frontend Engineer
- React / Next.js / TypeScript expertise
- Company’s frontend architecture
- Design system knowledge
- Previous UI decisions
- Common frontend bugs and their solutions
- Performance patterns discovered in the codebase
- Product/design context
- Previous implementation decisions
- Code review history
- Lessons learned from previous tasks
- Knowledge inherited from other agents
Then instead of creating a new agent from scratch every time, Tom continuously builds on his knowledge.
The agent isn’t simply:
Model + Prompt + Skills + Current Context
It becomes:
Model + Skills + Context + Experience + Persistent Knowledge
A Knowledge Base for Every Agent
Each dedicated agent could have its own evolving knowledge base.
For example:
Tom — Frontend
Core expertise
- React
- Next.js
- TypeScript
- Accessibility
- Performance
- Design systems
Project knowledge
- Current architecture
- Component hierarchy
- State management
- API conventions
- Design system
- Known technical debt
Experience
- Previous implementation decisions
- Bugs encountered
- Failed approaches
- Successful patterns
- Performance optimizations
- Review feedback
Team knowledge
- Backend agent conventions
- Product decisions
- Design principles
- API contracts
- Shared architectural decisions
Preferences / heuristics
- How components should be structured
- When to abstract vs. keep things local
- Preferred patterns for state management
- Testing philosophy
- Accessibility standards
This knowledge should be retrievable, editable, inspectable, and continuously updated.
Agents Should Learn From the Development Lifecycle
The interesting part is that knowledge shouldn’t only come from manually writing an agent prompt.
It could be generated from the work agents already perform.
For example:
1. Planning
Tom receives:
Build a new dashboard for machine telemetry.
The agent researches the repository, understands existing patterns, and creates a plan.
2. Implementation
Tom implements the dashboard.
During implementation, he discovers:
The project uses a custom server-state abstraction rather than React Query because of an earlier architectural decision.
That becomes useful knowledge.
3. Review
Another agent reviews the implementation and identifies:
Dashboard components should never directly access Firestore.
Tom learns this convention.
4. Debugging
Two weeks later, Tom encounters a similar issue.
Instead of rediscovering the architecture from scratch, he can recall:
“We previously had this issue. The root cause was direct Firestore access from the UI layer. The established pattern is to use the telemetry service.”
That’s experience, not just context.
Cross-Agent Knowledge Sharing
The knowledge shouldn’t necessarily remain isolated.
Imagine a team of agents:
Tom — Frontend
Sarah — Backend
Alex — QA
Mike — DevOps
Emma — Product / Architecture
Each agent has their own expertise, but they can contribute to a shared organizational knowledge layer.
For example:
Sarah discovers:
The telemetry API has a 5-second eventual consistency window.
Tom’s frontend agent should eventually know this because it affects UI state handling.
Similarly:
Tom discovers:
The frontend expects timestamps in UTC and performs local conversion.
Sarah’s backend agent should know this when modifying the API.
This creates something closer to an AI engineering team memory.
Knowledge Should Have Provenance
One important design consideration would be making the knowledge explainable.
Instead of an agent simply “remembering” something, the knowledge base could show:
Knowledge: Telemetry API responses should always use UTC timestamps.
Source: PR #184
Discovered by: Tom
Confirmed by: Sarah
Last validated: 3 days ago
Or:
Decision: Do not access Firestore directly from frontend components.
Source: Architecture Decision Record #12
Confidence: High
This prevents persistent memory from becoming an opaque collection of potentially outdated assumptions.
Knowledge Should Decay / Evolve
Persistent knowledge also needs lifecycle management.
Some knowledge becomes obsolete.
For example:
“Use Redux for global state.”
Six months later, the team migrates to Zustand.
The agent should be able to detect contradictions and update its knowledge rather than permanently accumulating outdated information.
Potential states:
- Active
- Deprecated
- Contradicted
- Needs validation
- Project-specific
- Global
- High confidence
- Learned from observation
- Explicitly instructed
This could make persistent agent knowledge significantly more reliable.
Agent Profiles
I imagine a UI where creating an agent feels less like writing a system prompt and more like creating a teammate.
Create Agent
Name: Tom
Role: Senior Frontend Engineer
Primary domain: Frontend
Model: Auto / Claude / GPT / etc.
Expertise
React
Next.js
TypeScript
Design Systems
Performance
Knowledge Sources
Current repository
Documentation
Previous agent conversations
PRs
Code reviews
Architecture decisions
Other agents
☐ External documentation
Learning
Learn from completed tasks
Learn from code reviews
Learn from corrections
Share selected knowledge with team agents
The Most Interesting Part: Agents Improve Through Feedback
I think this could become much more powerful if agents learn from corrections.
For example:
Tom proposes:
“Let’s create a new abstraction for this component.”
Developer says:
“Don’t abstract this. We’ve tried this pattern before and it created unnecessary coupling.”
That shouldn’t disappear when the conversation ends.
Tom could record:
Lesson: Avoid introducing shared abstractions for one-off dashboard components unless there are at least 2–3 concrete consumers.
The next time Tom encounters a similar situation, he applies that experience.
This is much closer to how human engineers actually develop expertise.
From Multi-Agent Orchestration → Multi-Agent Teams
This also complements the multi-model orchestration idea.
Instead of:
Task → Model → Response
or even:
Task → Agent → Response
Cursor could eventually have:
Task → Planner → Specialized Agents → Shared Knowledge → Review → Learning
For example:
User
│
▼
Planner
│
├── Tom / Frontend
│ └── Frontend Knowledge Base
│
├── Sarah / Backend
│ └── Backend Knowledge Base
│
├── Alex / QA
│ └── QA Knowledge Base
│
└── Mike / DevOps
└── Infrastructure Knowledge Base
│
▼
Shared Engineering Knowledge
│
▼
Review / Verification
│
▼
Knowledge Updates
The final step is important.
The system shouldn’t just complete the task. It should learn from completing the task.
Why I Think This Is Different From Just “Memory”
I wouldn’t position this as simply adding memory to subagents.
Memory answers:
“What happened before?”
Knowledge answers:
“What do I know?”
Experience answers:
“What have I learned from doing this repeatedly?”
Expertise answers:
“Given what I’ve learned, what should I do now?”
That progression could turn Cursor agents from disposable task executors into persistent engineering teammates.
Possible Product Primitive
A simple mental model could be:
Agent = Identity + Role + Skills + Model + Context + Knowledge + Experience
Where:
-
Identity → Who is this agent?
-
Role → What responsibility does it own?
-
Skills → What can it do?
-
Model → What intelligence powers it?
-
Context → What does it need for this task?
-
Knowledge → What does it know?
-
Experience → What has it learned?
And importantly, context is temporary while knowledge and experience persist.
That distinction could become a powerful foundation for Cursor’s multi-agent future.
The long-term vision
I could imagine opening a project six months later and seeing:
Your Engineering Team
Tom — Frontend
Sarah — Backend
Alex — QA
Mike — Infrastructure
Emma — Architecture
These aren’t just different prompts.
They are agents that have worked on the codebase, accumulated knowledge, learned from mistakes, understand the team’s decisions, and developed expertise over time.
It’s building an engineering organization that compounds its knowledge.