The Shift to Multiplayer Agentic Workflows

Building with AI agents is often treated as a solo activity, with agents trapped on individual laptops. To scale effectively, engineering teams must transition to a "multiplayer" model where agents operate in shared, cloud-based environments. This shift allows non-technical team members (support, growth, product) to trigger real work, creates a single source of truth for agent sessions, and eliminates the "lid anxiety" of tethering development to a physical machine.

Core Principles for Agentic Collaboration

  • Model and Harness Agnostic: The best AI model changes weekly. By building an abstraction layer, teams can swap models (e.g., switching between Anthropic, Codex, or open-weight models like GLM 5.2) without disrupting workflows. This also protects teams from vendor lock-in and misaligned token-selling incentives.
  • Unified Interfaces: Don't trap agents in a single tool like Slack or a specific IDE. Ensure the same agent session is accessible across GitHub, mobile apps, and internal dashboards. This maintains context and allows team members to jump into an ongoing agent session to review, query, or guide the work.
  • Visible Artifacts: Make agent work transparent. Whether it is a screenshot, a video, or a code diff, the agent should output artifacts that are visible to the entire team, regardless of where the request originated.
  • External Signal Integration: Treat every external input—customer calls, bug reports, or Slack threads—as potential code tasks. Using tools like "meeting bots" to transcribe and analyze team discussions allows agents to automatically generate tickets and prototypes, which engineers can then review and ship.

Security and Benchmarking

  • Isolated Cloud Sandboxes: Running agents on local machines is a security risk. Moving development to isolated cloud environments allows for granular control over network access and secrets. It prevents agents from accidentally accessing production databases or sensitive local files while enabling non-technical staff to safely trigger code changes.
  • Codebase-Specific Benchmarking: Public benchmarks (like SWE-bench) are often irrelevant to your specific stack. Build a internal benchmarking suite that measures quality, cost, and time for your own pull requests. This data-driven approach allows teams to identify which models perform best for their specific language (e.g., Ruby on Rails) and helps in automatically routing tasks to the most efficient model for the job.

Practical Outcomes

By implementing these strategies, teams can move from manual ticket triage to an automated flow where ideas are prototyped and PRs are generated with minimal human intervention. The goal is to maintain a human-in-the-loop review process while offloading the execution to agents that operate within a secure, collaborative, and measurable infrastructure.