feat(agent): guide cloud agents to use the PostHog memory MCP tool#2599
Draft
andrewm4894 wants to merge 2 commits into
Draft
feat(agent): guide cloud agents to use the PostHog memory MCP tool#2599andrewm4894 wants to merge 2 commits into
andrewm4894 wants to merge 2 commits into
Conversation
Appends persistent-memory guidance to every cloud-run system prompt so cloud agents recall durable context across runs and persist new learnings via the PostHog `memory` MCP tool — the shared, semantically-searchable memory store used by Max/PostHog AI. The tool itself is added server-side in PostHog/posthog (the cloud agent already forwards every PostHog MCP tool, so no allowlist change is needed here). Generated-By: PostHog Code Task-Id: b2ae2f32-aa94-4532-b069-b03875e73a58
|
React Doctor found no issues in the changed files. 🎉 Reviewed by React Doctor for commit |
Contributor
Prompt To Fix All With AIFix the following 1 code review issue. Work through them one at a time, proposing concise fixes.
---
### Issue 1 of 1
packages/agent/src/server/agent-server.ts:1704-1714
**Memory instructions reach Codex cloud runners too**
`buildMemoryInstructions()` is appended unconditionally inside `buildSessionSystemPrompt`, and `buildCodexInstructions` (line 1651) re-uses that same output verbatim as the `instructions` field for Codex runs. The `memory` MCP tool is listed in `mcpServers` passed to `newSession` for both runtimes, but whether the Codex path actually negotiates and exposes MCP tools to the model is worth confirming — if it does not, Codex agents will reference a tool they cannot call. This is not a blocker given the architectural note in the PR description, but a quick check or comment clarifying that Codex also has `memory` available would make this assumption explicit.
Reviews (1): Last reviewed commit: "feat(agent): guide cloud agents to use t..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
Comment on lines
+1704
to
+1714
| private buildMemoryInstructions(): string { | ||
| return ` | ||
| # Persistent Memory | ||
| You have access to PostHog's persistent memory through the \`memory\` MCP tool — a shared, | ||
| semantically-searchable store of durable facts about this user, their company, product, and | ||
| preferences (the same memories used across PostHog AI). Memories persist across runs, so: | ||
| - Before non-trivial work, recall context with the \`memory\` tool using \`action: "query"\` (semantic search) to surface durable facts, decisions, and prior discussions. | ||
| - When you learn something durable — product setup, conventions, definitions, preferences, decisions — store it with \`action: "create"\`. Do this pre-emptively; you don't need to be asked. Query first to avoid duplicates. | ||
| - Use \`action: "update"\`/\`"delete"\` to keep memories accurate, and \`action: "list_metadata_keys"\` to keep metadata tags consistent. | ||
| - Memories are for durable facts, not transient task state. New memories become searchable once their embedding is processed.`; | ||
| } |
Contributor
There was a problem hiding this comment.
buildMemoryInstructions() is appended unconditionally inside buildSessionSystemPrompt, and buildCodexInstructions (line 1651) re-uses that same output verbatim as the instructions field for Codex runs. The memory MCP tool is listed in mcpServers passed to newSession for both runtimes, but whether the Codex path actually negotiates and exposes MCP tools to the model is worth confirming — if it does not, Codex agents will reference a tool they cannot call. This is not a blocker given the architectural note in the PR description, but a quick check or comment clarifying that Codex also has memory available would make this assumption explicit.
Prompt To Fix With AI
This is a comment left during a code review.
Path: packages/agent/src/server/agent-server.ts
Line: 1704-1714
Comment:
**Memory instructions reach Codex cloud runners too**
`buildMemoryInstructions()` is appended unconditionally inside `buildSessionSystemPrompt`, and `buildCodexInstructions` (line 1651) re-uses that same output verbatim as the `instructions` field for Codex runs. The `memory` MCP tool is listed in `mcpServers` passed to `newSession` for both runtimes, but whether the Codex path actually negotiates and exposes MCP tools to the model is worth confirming — if it does not, Codex agents will reference a tool they cannot call. This is not a blocker given the architectural note in the PR description, but a quick check or comment clarifying that Codex also has `memory` available would make this assumption explicit.
How can I resolve this? If you propose a fix, please make it concise.Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
Clarifies that the memory MCP tool guidance correctly applies to both Claude and Codex cloud runs: newSession passes the PostHog MCP server via mcpServers for both runtimes, and the Codex adapter forwards those servers to the Codex CLI, so buildCodexInstructions reusing this text is intentional. Addresses a P2 review note from greptile-apps. Generated-By: PostHog Code Task-Id: b2ae2f32-aa94-4532-b069-b03875e73a58
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Claude-style agent memories produced during PostHog Code cloud runs went nowhere — there was no persistent, shared memory store wired into cloud agents, so they couldn't recall durable context across runs or carry learnings forward.
Changes
Appends a short Persistent Memory section to every cloud-run system prompt (
buildSessionSystemPrompt→ applied across allbuildCloudSystemPromptbranches) telling cloud agents to use the PostHogmemoryMCP tool to recall durable facts before non-trivial work and to store new learnings pre-emptively.The
memoryMCP tool is added server-side in PostHog/posthog (PostHog/posthog#62875), backed by the sameAgentMemory/document_embeddingsstore Max/PostHog AI uses. No tool-allowlist change is needed here: cloud agents forward every PostHog MCP tool verbatim (newSession({ mcpServers })) under bypass-permissions, so the tool becomes available automatically — this PR only encourages its use.How did you test this?
I'm an agent, so I did not manually run the app. Automated checks I actually ran:
pnpm --filter @posthog/agent typecheck— clean (after building workspace deps).agent-server.test.tscloud-prompt assertions usetoContain, which this additive change preserves; that suite could not execute in my sandbox because its git-fixture setup callsgit commit, which is blocked in this environment (the failure reproduces on unmodifiedmain).Automatic notifications
Created with PostHog Code from a Slack thread