hosted-agents

# Hosted Agent Infrastructure Hosted agents run in remote sandboxed environments rather than on local machines. When designed well, they provide unlimited concurrency, consistent execution environments, and multiplayer collaboration. The critical insight is that session speed should be limited only by model provider time-to-first-token, with all infrastructure setup completed before the user starts their session. ## When to Activate Activate this skill when: - Building background coding agents that run independently of user devices - Designing sandboxed execution environments for agent workloads - Implementing multiplayer agent sessions with shared state - Creating multi-client agent interfaces (Slack, Web, Chrome extensions) - Scaling agent infrastructure beyond local machine constraints - Building systems where agents spawn sub-agents for parallel work Do not activate this skill for adjacent work owned by other skills: - Designing the autonomous research loop, novelty gates, rollback policy, or merge boundaries: `harness-engineering`. - Choosing supervisor, swarm, or handoff topology without hosted infrastructure concerns: `multi-agent-patterns`. - Designing the tools used by a hosted agent, such as spawn/status tools or PR tools: `tool-design`. - Managing file-backed state inside a session rather than the hosted runtime itself: `filesystem-context`. ## Core Concepts Move agent execution to remote sandboxed environments to eliminate the fundamental limits of local execution: resource contention, environment inconsistency, and single-user constraints. Remote sandboxes unlock unlimited concurrency, reproducible environments, and collaborative workflows because each session gets its own isolated compute with a known-good environment image. Design the architecture in three layers because each layer scales independently. Build sandbox infrastructure for isolated execution, an API layer for state management and client coordination, and client interfaces for user interaction across platforms. Keep these layers cleanly separated so sandbox changes do not ripple into clients. ## Detailed Topics ### Sandbox Infrastructure **The Core Challenge** Eliminate sandbox spin-up latency because users perceive anything over a few seconds as broken. Development environments require cloning repositories, installing dependencies, and running build steps -- do all of this before the user ever submits a prompt. **Image Registry Pattern** Pre-build environment images on a regular cadence (every 30 minutes works well) because this makes synchronization with the latest code a fast delta rather than a full clone. Include in each image: - Cloned repository at a known commit - All runtime dependencies installed - Initial setup and build commands completed - Cached files from running app and test suite once When starting a session, spin up a sandbox from the most recent image. The repository is at most 30 minutes out of date, making the remaining git sync fast. *