Add semantic/episodic/procedural memory layering to managed-memory skill#244
Open
jennsun wants to merge 4 commits into
Open
Add semantic/episodic/procedural memory layering to managed-memory skill#244jennsun wants to merge 4 commits into
jennsun wants to merge 4 commits into
Conversation
Adds an optional layered-memory convention on top of the flat memory store: distill each memory into semantic / episodic / procedural and store under a matching /memories/<layer>/ path prefix. - SKILL.md: new "Step 6 — Layered memory" section with the layer table, path conventions, and the Conversations API flow for episodic state (binds a conversation to the store + scope via DatabricksOpenAI, scoped to the Supervisor API path); pointers from Step 5 and Notes; new trigger keywords in frontmatter. - memory-layers.md: companion guide with layer definitions, a "decide the layer before you save" procedure, path-prefix examples, and a drop-in layered MEMORY_INSTRUCTIONS. - Synced to all conversational templates via sync-skills.py. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
jennsun
force-pushed
the
managed-memory-layers
branch
from
June 30, 2026 23:23
c21cc9c to
17a8407
Compare
READ/WRITE_MEMORY_STORE alone is insufficient for a deployed app: UC requires USE_CATALOG on the catalog and USE_SCHEMA on the schema to traverse to the memory-store securable, or every entries call fails with "User does not have USE CATALOG on Catalog '<catalog>'". The store owner already holds these (so local testing as the owner doesn't hit it), but the deployed app service principal almost always needs them. - Step 2: add the two parent-grant PATCH calls for the SP. - Troubleshooting: add a row for the USE CATALOG error. - Synced to all conversational templates. Found while end-to-end testing the layered-memory skill on a deployed Databricks app. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
jennsun
commented
Jun 30, 2026
| -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \ | ||
| -d "{\"changes\":[{\"principal\":\"$APP_SP\",\"add\":[\"USE_SCHEMA\"]}]}" | ||
| ``` | ||
|
|
Contributor
Author
There was a problem hiding this comment.
adding this from test run
Tested the Conversations API episodic flow on a staging workspace
(databricks-openai 0.17.0, use_ai_gateway=True):
- conversations.create({memory_store, scope}) works; the conversation is
created and retrievable.
- conversations.items.create / .list work; turn state persists and reads
back.
- BUT responses.create(conversation=<id>) is rejected server-side with
400 "conversation: Extra inputs are not permitted" (both top-level and
in extra_body), while a plain responses.create works. So the documented
end-to-end flow is not live on every workspace's AI Gateway yet.
- Conversation state is separate from memory-store entries (the .../entries
list API does not surface it).
Add a Beta / availability-varies callout with the exact error and a
fallback, so users verify on their workspace instead of assuming it works.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The previous instructions were wrong: responses.create(conversation=<id>)
is rejected by some gateways with 400 "conversation: Extra inputs are not
permitted". The correct integration for the OpenAI Agents SDK templates is
to back the short-term session with the memory store:
- create a conversation bound to {memory_store, scope}
- wrap it in the Agents SDK OpenAIConversationsSession
- pass it as session= to Runner.run (replaces the Lakebase
AsyncDatabricksSession block in agent-openai-advanced)
The session reads/writes turns via conversations.items.list/create (the
supported surface), using one AsyncDatabricksOpenAI(use_ai_gateway=True)
client and set_default_openai_api("responses"). Verified end-to-end on
staging (databricks-openai 0.17.0, openai-agents 0.17.7): recall works
across separate requests and a fresh session with the same conversation id.
Still marked Beta (Conversations APIs are beta). Synced to all templates.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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
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.
Summary
Adds an optional layered-memory convention on top of the flat managed-memory store, so an agent can organize what it remembers into semantic / episodic / procedural layers.
The base skill stores entries at flat
/memories/...paths with no notion of memory type. This PR adds a convention (prompt + path prefixes — no new tools, grants, or code) that has the agent distill each memory into one of three kinds and store it under a matching/memories/<layer>/prefix.What changed
SKILL.md— new "Step 6 (optional) — Layered memory" section:/memories/semantic/..., procedural →/memories/procedural/..., episodic → Conversations API +/memories/episodic/...(every path still starts/memories/per the API).DatabricksOpenAI→conversations.create(...)→responses.create(conversation=...), reusing the sameresolve_scope()scope as the five tools. Honestly scoped to the Supervisor API path (not the in-process Agents SDK / LangGraph loop), with guidance for the loop case.memory-layers.md— new companion file: layer definitions, a "decide the layer before you save" procedure, path-prefix examples, and a drop-in layeredMEMORY_INSTRUCTIONS.USE_CATALOG/USE_SCHEMA): grant the deployed app SPUSE_CATALOGon the catalog andUSE_SCHEMAon the schema, plus a troubleshooting row.READ/WRITE_MEMORY_STOREalone is insufficient — UC needs the parent traversal privileges or every entries call fails withUser does not have USE CATALOG. Found during end-to-end testing below.sync-skills.py.End-to-end testing
Validated the layering against a live Databricks app (LangGraph base template + the five memory tools + the layered
MEMORY_INSTRUCTIONSfrommemory-layers.md, modeldatabricks-claude-sonnet-4), on a staging workspace.Setup: created a new UC memory store
jenny.default.layered_memory_testand deployed a new appagent-memory-layers.I gave the agent facts of each kind and confirmed via direct REST reads that they landed under the right path prefixes:
/memories/semantic/coding-preferences.md·/memories/semantic/commit-message-style.md/memories/procedural/pr-review-process.md·/memories/procedural/deploy-checklist.md/memories/episodic/pnpm-standardization-decision.md·/memories/episodic/staging-database-migration.mdResults:
list_memories→get_memoryand answered correctly from each layer.start-app --no-ui(scope faked withX-Forwarded-User) and the deployed app (scope resolved from the OBO token to the real user id).The deployed app initially failed with
User does not have USE CATALOG on Catalog 'jenny'; granting the SPUSE_CATALOG+USE_SCHEMAfixed it immediately — which is the Step 2 change included here.🤖 Generated with Claude Code
Episodic memory via a store-backed conversation (Beta) — verified working
The first draft of this section was wrong (
responses.create(conversation=<id>)is rejected by the staging gateway with400 "conversation: Extra inputs are not permitted"). Corrected to the integration that actually works, verified end-to-end on staging (databricks-openai0.17.0,openai-agents0.17.7):{memory_store, scope}, wrap it inOpenAIConversationsSession, pass it assession=toRunner.run.conversations.items.list/create(supported), using oneAsyncDatabricksOpenAI(use_ai_gateway=True)client +set_default_openai_api("responses").AsyncDatabricksSession(Lakebase) block inagent-openai-advanced/agent_server/agent.py.Test: stated a codeword in turn 1; recalled correctly in turn 2, and again from a fresh session object with the same conversation id (proves cross-request persistence in the store). Still flagged Beta since the Conversations APIs are beta.