vxcontrol/pentagi
1
0
Fork 0
mirror of https://github.com/vxcontrol/pentagi.git synced 2026-07-21 08:15:23 -04:00
Code Issues 45 Packages Projects Releases 9 Wiki Activity

[PR #267] [MERGED] docs: clarify memory lifecycle across flows #282

New Issue
Closed
opened 2026-06-06 22:10:02 -04:00 by yindo · 0 comments
yindo commented 2026-06-06 22:10:02 -04:00
Owner
Copy Link
Copy Source

📋 Pull Request Information

Original PR: https://github.com/vxcontrol/pentagi/pull/267
Author: @mason5052
Created: 4/15/2026
Status: ✅ Merged
Merged: 4/22/2026
Merged by: @asdek

Base: feature/next-release ← Head: codex/issue-74-memory-lifecycle-docs

📝 Commits (2)

  • 4e2ece8 docs: clarify memory lifecycle across flows
  • a285a99 docs: tighten memory lifecycle guidance

📊 Changes

2 files changed (+19 additions, -0 deletions)

View changed files

📝 README.md (+13 -0)
📝 backend/docs/flow_execution.md (+6 -0)

📄 Description

Summary

  • document how PentAGI memory behaves across flows
  • clarify the difference between flow-scoped execution memory and reusable vector documents
  • add practical guidance for storing reusable target knowledge between engagements

Problem

Issue #74 asks whether PentAGI should keep memory after flows are removed and how users should preserve target knowledge between runs. The current repository already has the underlying concepts (memory, guide, answer, code, Graphiti, and flow_id filters), but the docs do not explain how they fit together operationally.

Solution

  • add a new "Memory Lifecycle Across Flows" section to the README near the embedding and etester documentation
  • explain when to inspect vector documents with flow_id and when to store durable knowledge explicitly as guide, answer, or code
  • extend backend/docs/flow_execution.md with lifecycle guidance that distinguishes flow-scoped execution history from reusable knowledge and references the current prompt-template behavior

User Impact

Users now have a clearer path for deciding what should stay attached to a single engagement and what should be stored intentionally for future flows. This makes it easier to preserve reusable target notes without assuming that raw execution history alone will provide the right cross-run context.

Test Plan

  • verify the new README guidance matches the current etester search options and embedding docs
  • verify the lifecycle notes match the documented vector store types and prompt-template memory model
  • run git diff --check

Refs #74

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/vxcontrol/pentagi/pull/267 **Author:** [@mason5052](https://github.com/mason5052) **Created:** 4/15/2026 **Status:** ✅ Merged **Merged:** 4/22/2026 **Merged by:** [@asdek](https://github.com/asdek) **Base:** `feature/next-release` ← **Head:** `codex/issue-74-memory-lifecycle-docs` --- ### 📝 Commits (2) - [`4e2ece8`](https://github.com/vxcontrol/pentagi/commit/4e2ece89450cd177d30631c4d14ad2d86d23ccce) docs: clarify memory lifecycle across flows - [`a285a99`](https://github.com/vxcontrol/pentagi/commit/a285a99e2834bb44147a44b835de4b359ff9a58a) docs: tighten memory lifecycle guidance ### 📊 Changes **2 files changed** (+19 additions, -0 deletions) <details> <summary>View changed files</summary> 📝 `README.md` (+13 -0) 📝 `backend/docs/flow_execution.md` (+6 -0) </details> ### 📄 Description ## Summary - document how PentAGI memory behaves across flows - clarify the difference between flow-scoped execution memory and reusable vector documents - add practical guidance for storing reusable target knowledge between engagements ## Problem Issue #74 asks whether PentAGI should keep memory after flows are removed and how users should preserve target knowledge between runs. The current repository already has the underlying concepts (`memory`, `guide`, `answer`, `code`, Graphiti, and `flow_id` filters), but the docs do not explain how they fit together operationally. ## Solution - add a new "Memory Lifecycle Across Flows" section to the README near the embedding and `etester` documentation - explain when to inspect vector documents with `flow_id` and when to store durable knowledge explicitly as `guide`, `answer`, or `code` - extend `backend/docs/flow_execution.md` with lifecycle guidance that distinguishes flow-scoped execution history from reusable knowledge and references the current prompt-template behavior ## User Impact Users now have a clearer path for deciding what should stay attached to a single engagement and what should be stored intentionally for future flows. This makes it easier to preserve reusable target notes without assuming that raw execution history alone will provide the right cross-run context. ## Test Plan - verify the new README guidance matches the current `etester` search options and embedding docs - verify the lifecycle notes match the documented vector store types and prompt-template memory model - run `git diff --check` Refs #74 --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
yindo added the pull-request label 2026-06-06 22:10:02 -04:00
yindo closed this issue 2026-06-06 22:10:02 -04:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
enhancement
help wanted
pull-request
Mirrored from GitHub Pull Request
 question
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: vxcontrol/pentagi#282
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?