In an AWS machine learning blog post, Claudio Mazzoni walks through prompt caching for agent loops on Amazon Bedrock. The setup is familiar: on every step an agent resends its tool definitions, developer instructions, the full history of tool calls and results, and the newest message, because the model holds no state between requests. Prefill builds the key and value vectors for all of that input before the first output token; caching stores that state so a later request with an identical prefix only processes what is new.
The post distinguishes implicit caching, where Bedrock chooses where the reusable prefix ends, from explicit caching, where code marks the boundary with prompt_cache_breakpoint. It recommends combining them: an explicit marker after the shared tools and instructions gives every session, and every helper agent, a reusable starting point, while implicit caching follows the conversation as it grows.
Operational details: the reusable prefix must reach 1,024 tokens to qualify; caching only hits when the text is byte-identical, so tools and instructions must serialise the same way each time, with MCP tool definitions kept in a stable order; anything volatile such as a date, a user name or a request ID belongs after the cached block; prompt_cache_key tells the service which requests are meant to share a cache. In one test the roughly 4,000-token tools-and-instructions prefix wrote 4,120 tokens on the first request and read those 4,120 tokens on later ones.
Our takeCaching is exact-prefix matching, which makes the failure mode quiet: serialise a timestamp into the developer block, or let an MCP server return tools in a different order, and every turn becomes a cache write with no error to show for it. The two-mode design is the useful part — explicit breakpoints give a shared prefix across sessions and subagents, implicit ones track the growing history — and the 4,120-token write-then-read example is the accounting to copy. Measure cache-read tokens per turn before assuming the savings land.