Thank you for the thoughtful reply! I thought it would be fun to give some additional context on why we chose to make the runner durable instead of just the session log.
Agency sandboxes contain not just an agent's chat state but also our full development environment -- each sandbox runs a fully isolated copy of Sierra, complete with sidecar containers that provide local equivalents for AWS services that we use. During a Pinecone session, the agent might create database records, update caches, change files on disk, or do any number of things that change mutable state. Additionally, each Pinecone session exposes its locally running Sierra so that we can share preview links internally. Though the agent isn’t doing anything, this development environment needs to survive and be reachable for O(days). This was key to incentivize our team to make the leap from local agents to cloud-based agents and not sacrifice anything in terms of ergonomics.
The other key requirement for us is portability across clouds and on-prem deployments, because Agency also powers our in-product agents and we serve large Enterprises. This made AgentCore less viable as an option. As the ecosystem matures, it's possible that separating the agent session from the development environment unlocks more interesting trades, but it's not quite there yet.
Part of what makes building in the agentic era fun is that we can hold past decisions, even infrastructure ones, more loosely; swapping out one boring service for another is much easier when Agents can manage the migration. :)
English
