Agent workflows are messy. Every provider has a different way to store skills, rules, MCP configs, commands, subagents, and hooks. We think agents should be a tool choice, not a lock-in. Environments should work the same locally and in the cloud, whether you're using GitHub Copilot, Claude Code, or Gemini.

Agent Playground is our reference template for portable agent environments. It standardizes configuration, tool access, and setup so you can define once and run with parity everywhere.

https://github.com/LN-Zap/agent-playground

Design principles

We had a few non-negotiables:

• Portability over lock-in - engineers can use the tool that fits their job.
• Single source of truth - configs defined once and only once.
• Reproducibility - local, CI, and cloud share the same environment.

If a new agent harness shows up tomorrow, we should be able to add it without rewriting everything else.

How it works

1. Centralized config with rulesync

rulesync lets us store skills, rules, MCP configuration, commands, subagents, and hooks in a provider-agnostic format.

A single config declares the agent targets to support and the remote skills to pull in.

{
  "targets": [ "copilot", "claudecode", "opencode" ],
  "features": [ "mcp", "rules", "skills", "subagents" ],
  "sources": [ {
    "source": "https://github.com/anthropics/skills",
    "skills": [ "skill-creator" ]
  } ]
}

The outputs are regenerated deterministically from source.

.
├── rulesync.jsonc    # Config
├── rulesync.lock     # Lockfile
└── .rulesync/        # Canonical source
    ├── mcp.json      # Shared MCP
    ├── rules/        # Project rules
    └── skills/       # Pinned skills

2. Pinned skills via lockfiles

Pulling unpinned remote code is a security risk. We upstreamed lockfile support to rulesync (PR link) to pin installs to specific commit hashes.

A rulesync.lock file keeps the environment reproducible:

{
  "lockfileVersion": 1,
  "sources": {
    "anthropics/skills": {
      "requestedRef": "main",
      "resolvedRef": "1ed29a03dc85...",
      "resolvedAt": "2026-02-17T09:49:59.986Z",
      "skills": {
        "skill-creator": {
          "integrity": "sha256-e141..."
        }
      }
    }
  }
}

When we update a skill, the workflow is deliberate:

1. Run rulesync install --update to fetch code and update lockfile.
2. Review the diff in the "curated" source directory during the PR process.
3. Merge only after vetting the upstream code for security issues.

This makes the agent supply chain as auditable as the rest of our stack.

When we run in cloud environments, the workflow is deterministic:

1. Run rulesync install --frozen to pull reviewed, locked code.
2. The process aborts if the sources drift from the lockfile hashes.

This ensures zero drift between local vetting and cloud execution.

3. Unified MCP via rulesync

We maintain a central MCP server configuration within the rulesync source. rulesync then syncs this config to every target. Since tool access is defined once, agents keep the same capabilities even when you swap harnesses.

4. Reproducibility

We use devenv to ensure the toolchain is identical everywhere. npm install runs a frozen rulesync install and regenerates outputs. Setup is automatic via direnv - simply changing into the repo bootstraps the environment.

5. Prebuilt Cloud Agents

Complex environment setup steps can be slow and cumbersome for cloud agents to run every time. We use devenv as the single source of truth to easily prebuild runner images for the GitHub Copilot coding agent (see devenv-actions).

The action outputs a Docker container that the GitHub Copilot coding agent uses as its environment. By prebuilding the image, we get super fast start-up times for the cloud coding agent, and we guarantee it has the exact same consistent environment we use locally.

We also use devenv to generate Dev Container specs and use those to generate prebuilt images. That enables us to use the same fully set up coding environment with cloud-based IDEs such as GitHub Codespaces.

Agent Playground at Strike

We run a shared Agent Playground that extends the template with our own skills, MCP servers, and custom agents. Every engineer can pull an environment that knows our internal patterns and connects to our stack.

Engineers bring their own API keys and OAuth credentials. Secrets stay off shared machines and align with individual permissions. Product teams use the same pattern in their own repos, keeping their agent capabilities portable and reproducible.

It's worth noting that Agent Playground is a collection of patterns, not an all-or-nothing framework. While adopting the entire stack (rulesync, lockfiles, devenv) yields the best results, teams can adopt these practices incrementally. You can start by just centralizing your Agent Skills and MCP configs, and add reproducible environments later.

Standards or bust

Agent tooling shifts too fast for proprietary lock-in. Every new harness brings a unique config format and manual setup cost. That fragmentation slows down engineers.

We advocate for open, vendor-agnostic standards. A shared convention like AGENTS.md beats a pile of CLAUDE.md and GEMINI.md files. Your agent system should be bigger than your tool choice.

We aim to treat environments as first-class citizens: portable, reproducible, and tool-blind. Portability pays off. It helps us stay fast as the field evolves.

Join us

We build this kind of infrastructure every day at Strike, and we think it matters. If you want to go deep on agent systems, developer tooling, and the primitives that make AI actually production-ready, take a look at our open roles.

Apply here: https://job-boards.greenhouse.io/strike