Memory · AWS Bedrock
March 2026 · 7 min read
AWS Bedrock gives enterprise teams access to Claude with the security and compliance guarantees that AWS infrastructure provides. Data stays in your VPC. You get IAM access control. Audit logging works out of the box. For teams with strict data requirements, Bedrock is often the only acceptable way to run Claude.
But Bedrock's Claude access is stateless by design. Each API call is independent. There is no built-in session memory, no automatic context persistence, and no skill injection layer. Every request to Bedrock starts from zero.
For short, one-off tasks, statelessness is fine. Generate a function, get the output, done. But enterprise teams using Claude on Bedrock for ongoing development face the same problem as any other AI coding workflow: the accumulation of context that needs to persist.
A team's architecture decisions accumulate over months. The agreed patterns, the security constraints, the compliance requirements, the third-party integrations — all of this is context that needs to be available every time a developer asks Claude for help. On Bedrock, none of it persists by default.
The typical workaround is to build a prompt template that includes key context, maintained manually by someone on the team. This is better than nothing, but it has serious limitations: it requires maintenance, it cannot capture decisions made during sessions, and it injects everything into every prompt regardless of relevance.
Several approaches that work with Claude.ai or Claude Code do not work on Bedrock:
Projects and Knowledge — Claude.ai's Projects feature provides persistent memory within the product. This is not available through the Bedrock API. Each API call is independent.
Claude Code's hook system — Claude Code's hook lifecycle (SessionStart, PreToolUse, PostToolUse) is specific to the Claude Code CLI and does not exist in raw Bedrock API calls.
Conversation history replay — you can pass previous conversation turns as input to Bedrock, but this has token limits, does not scale to long projects, and still requires you to manage what context to include.
SkillGod solves Bedrock's memory limitation by operating at the developer-tool layer rather than the API layer. Instead of trying to add memory to Bedrock itself, SkillGod adds memory to the tools your developers use to interact with Bedrock.
When a developer uses Claude Code, Cursor, or Antigravity configured to use Bedrock as the backend, SkillGod's hook system still runs. The memory capture happens at the development tool level. The skill injection happens before the request reaches Bedrock. Bedrock receives a well-formed, context-enriched prompt — it does not need to know anything about the memory layer.
This means:
Enterprise teams choosing Bedrock are almost always doing so for compliance reasons. SkillGod is designed with this constraint in mind:
Local storage only — memory stores in a SQLite database on the developer's machine. No cloud sync. No external API calls. No data leaves the developer's environment.
No prompt capture — SkillGod captures decision summaries and patterns, not raw prompts or code. The memory entries are short, structured records, not conversation logs.
Opt-in signals only — anonymous quality signals (skill ID + score only, no content) are opt-in and disabled by default. A developer has to explicitly run sg signals enable to participate.
For teams using Claude on Bedrock, the Team plan is the right choice. Each seat gets: