Project memory vs static rules vs nothing
We gave three AI agents the exact same task — build a notification system. One had Foremen's project memory, one had Cursor's .cursorrules, and one started completely cold.
Foremen in production
Every tool call Foremen serves is timed and sized. These are not from a staged run — they are what the live server did, recomputed from the log.
Loading…
Published elsewhere, for scale
Vendor self-reported and contested — Zep has publicly disputed Mem0's evaluation, and independent audits have flagged methodology problems in the LoCoMo benchmark itself. Shown for order of magnitude, not as a scoreboard.
Why does this matter?
Every developer tool promises to make AI coding faster. But there's a fundamental problem: AI agents forget everything between sessions. Cursor solves this with static rules files — you write down your conventions once and the AI reads them each time. That's better than nothing, but it only captures what you thought to document.
Foremen takes a different approach. It builds a living memory — architecture maps, debugging lessons, session notes, known issues, and task context that accumulates automatically as agents work on your project. The question is: does that extra context actually produce better results?
Full session brief via MCP — architecture map, 4 debugging lessons, 3 session notes, known bugs, and task context with acceptance criteria.
Living memory
A realistic .cursorrules file — stack overview, design system classes, key patterns, and file structure. What a competent dev would write after a few sessions.
Static documentation
Only the task description and the codebase path. Had to explore everything from scratch — reading files, discovering patterns, figuring out conventions on its own.
No context
Same task for all three
“Add an in-app notification system — database table, API routes, frontend components, integration points. Produce a detailed implementation plan.”
0%
Fewer tokens vs cold
0/6
Quality categories won
0/6
Won by Cursor or cold
Note: Cursor used the fewest tool calls (16) because .cursorrules gave it enough upfront structure to skip basic exploration. But fewer reads doesn't mean better understanding — as the quality comparison below shows, it missed critical context that only comes from project history.
Speed is one metric. Quality is the one that matters.
All three agents produced working plans. The difference is in the details — what each agent knew, what it assumed, and what it got wrong.
Design system knowledge
Foremen
Cited exact classes from session brief — glass-card rounded-3xl, font-serif font-light, font-mono tracking-widest — plus the full oklch color palette and all three font families
Cursor
Had class names from .cursorrules — enough to style correctly, but lacked deeper context like the oklch palette values or the status color conventions
Cold start
Had to discover everything by reading globals.css, layout.tsx, and multiple component files — burned 8+ tool calls just learning the design system
Known project issues
Foremen
Knew about 3 active bugs from session notes: invoice number auto-generation missing, use-token RLS problem, no signup flow. Planned around them.
Cursor
No awareness of existing bugs — .cursorrules is static documentation, not a living bug tracker. Would have built on top of broken foundations.
Cold start
No awareness of existing bugs. Would have discovered some during implementation, but only after wasting time.
Debugging lessons
Foremen
Had 4 lessons from previous sessions — knew about route group naming, no-hardcoded-URLs rule, fetch-not-forms pattern, and createAdminClient for public pages
Cursor
Had createAdminClient pattern from .cursorrules. Missed the other 3 lessons because .cursorrules only captures what someone thought to write down, not what was learned the hard way.
Cold start
Found createAdminClient by reading code. Missed all other lessons. Would likely repeat past mistakes.
Missing UI components
Foremen
Warned there is no Popover component in the project — recommended building a simple div with click-outside handler instead of pulling in a new dependency
Cursor
Described the panel using glass-card without flagging the missing component — correct approach but didn't explicitly warn about the gap
Cold start
Suggested installing @radix-ui/react-popover — a wrong recommendation that would have added an unnecessary dependency and potentially broken the build
Documentation vs reality
Foremen
Caught that getAdminUser() referenced in CLAUDE.md doesn't actually exist in the codebase — flagged it explicitly to prevent runtime errors
Cursor
Didn't reference CLAUDE.md at all — .cursorrules is the only context file Cursor reads. The discrepancy went unnoticed.
Cold start
Didn't notice the discrepancy between documentation and code. Could have led to implementing a function call that doesn't exist.
Complexity calibration
Foremen
Chose 30-second polling for v1 — pragmatic, fewer moving parts. Noted Supabase Realtime as the upgrade path for v2.
Cursor
Also chose polling — same pragmatic decision. Good judgment even without session context.
Cold start
Jumped to Supabase Realtime — requires ALTER PUBLICATION, channel management, reconnection logic. Over-engineered for a v1.
The gap between Cursor and Foremen
Cursor's .cursorrules gave the agent the conventions — what classes to use, what patterns to follow, where files go. That's valuable and it shows in the performance numbers.
But Foremen gave the agent the experience — what went wrong last time, what bugs exist right now, what components are actually available versus what the docs claim, and what the team learned the hard way over multiple sessions. That's the difference between documentation and institutional knowledge.
A .cursorrules file captures what someone thought to write down. Foremen captures what the project actually learned.
The cold agent suggested a wrong dependency
The cold-start agent recommended installing @radix-ui/react-popover for the notification dropdown. The Cursor agent avoided this mistake because .cursorrules listed the available components. Foremen went further — it explicitly warned that no Popover exists and recommended a specific alternative. Three levels of knowledge, three different outcomes.
No context
The agent reads your code and figures out patterns on its own. Slow, expensive, and prone to wrong assumptions. Every session starts from zero.
Static rules
Conventions and structure. Faster starts, correct styling. But it only knows what someone thought to write down — and it goes stale the moment the project evolves.
Living memory
Everything static rules give you, plus debugging history, known bugs, session context, and lessons that accumulate automatically. The agent doesn't just know your conventions — it knows your project's story.
How Foremen works
When an agent starts a new session, one MCP call returns a structured brief with everything it needs to be productive immediately:
Architecture map
Components, their status, how they connect
vs .cursorrules: static file structure only
Session notes
What happened last time — decisions, blockers, progress
vs .cursorrules: no session history
Lessons learned
Mistakes from past sessions so they're never repeated
vs .cursorrules: not captured
Known issues
Active bugs, missing features, technical debt
vs .cursorrules: not captured
One API call delivers it all
tools/call → get_session_brief(project_id)What happens when you add Foremen to Cursor?
We ran a fourth test — same task, same codebase, but with both .cursorrules and Foremen's session brief. The agent had structural conventions from Cursor and experiential knowledge from Foremen. Here's what changed.
Correct styling and patterns. No awareness of existing bugs, no debugging lessons, didn't flag the invoice numbering issue that would block notifications from working.
Everything Cursor provided, plus known bugs, debugging lessons, and session history. Made connections Cursor alone couldn't.
The insight only the combined agent found
The Cursor + Foremen agent was the only one across all four tests that connected two separate pieces of knowledge: it knew from Foremen's session notes that invoice numbers are never auto-generated (a known bug), and it realized this means the Square webhook's regex matching would fail — so invoice_paid notifications would silently never fire until that bug is fixed. No other agent — not even Foremen alone — made that connection between a pre-existing bug and the new feature.
Foremen doesn't replace your tools — it gives them memory. Use it with Cursor, Claude Code, Windsurf, or any AI coding tool.