I Wanted Reproducible AI Coding Environments, So I Built agentpack | Oleg Pustovit – Technical Leadership & MVP Development for Startups

Modern agents like Claude Code, Codex, Cursor and OpenCode need skills, hooks and MCPs, but they load them differently. I made a tool that creates an ephemeral staging configuration that loads into coding agents without polluting the global user or project configuration. GitHub Link

Loading terminal recording...

I&rsquo;ve been using AI agents for building commercial software—it’s incredibly useful for creating quick prototypes and iterating on products for early-stage startups. Data analysis, triaging production issues, even undoing decisions that previously would take tremendous effort—like changing the programming language your project is written in—became essentially cheap. Before, writing CLIs/scripts custom to your needs required days of work; now they can be built in minutes, and that allows you to focus on problems that are meaningful to you.<br>The harness is the new bottleneck<br>Of course, autonomous coding workflows are still a long way from being perfect. These systems cannot reliably produce high-quality code—even frontier models fail at making custom abstractions and generating maintainable code unless you prompt them correctly. What makes the situation worse is that there&rsquo;s no single tool that is excellent at every software engineering problem ; instead we have a number of competing agent harnesses that implement essentially the same agent loop: Claude Code, OpenCode, Codex, Copilot, Cursor, etc., where you often find yourself restricted to a set of specific models and lacking the features to configure the agent flexibly. On top of that, those CLI agents manage context differently, which often results in different coding performance for the same models . Configuration is only partially standardized: many harnesses adopted AGENTS.md — initially created by OpenAI and supported by Codex, OpenCode, Cursor and others. Skills have more or less landed on the SKILL.md convention, but it is far from being a standard. Hooks, custom rules and plugins haven&rsquo;t yet converged in the same way. Claude Code and Cursor also have plugin systems, but they are not fully interchangeable. MCPs became a widely adopted standard; however, the project-specific configuration file for MCPs still differs for every CLI tool. When working with teams on startups, I often see a repository fully optimized for Claude Code, while using it with Codex requires hacking with symlinks or committing my own harness-specific configs to the team’s repository .<br>Every agent needs its own configuration<br>To this day, I’m using Claude Code as my daily driver. I know the flaws of the Opus model—it often makes average code, misses important things, talks itself into questionable decisions, which makes it infeasible to run on autopilot. For speed, I use Cursor Agent with the Composer model through the agent CLI. It gets the job done for quick refactors, solving merge conflicts, and other light work. Codex with the latest GPT models (as of May 2026) handles challenging computer-use tasks for me, paired with Playwright MCP, for cases where other models usually fail. Gemini 3.5 Flash recently arrived with the Antigravity CLI; the harness is very rough and lacking, but the model seems very smart on a small set of non-trivial issues. So I end up with the problem of having 3-4 CLI agents working on the same codebase, and I would like to share a set of skills and slash commands across all of them .<br>Harnesses like Claude Code have their own plugin marketplace with toggleable plugins. This is useful for discovering packages containing skills, agents, MCP or LSP servers, which can be installed via the /plugin command, but those are specific to Claude and aren&rsquo;t a great fit for declarative or immutable environments like Nix Home-Manager, where mutating config under ~/.claude conflicts with a model of a reproducible, read-only home directory . In such cases having an ephemeral staging layer for configuring AI agents makes more sense.<br>agentpack: an ephemeral configuration layer for agents<br>Before agentpack, repositories I worked in ended up with something like this:<br>text<br>Copied to clipboard

.claude/commands<br>.claude/skills<br>.cursor/rules<br>.cursor/agents<br>.opencode/commands<br>.agents/skills<br># copied MCP config snippets<br># symlinks I forgot to remove later

.claude/commands<br>.claude/skills<br>.cursor/rules<br>.cursor/agents<br>.opencode/commands<br>.agents/skills<br># copied MCP config snippets<br># symlinks I forgot to remove later

That works for a personal project, but doesn&rsquo;t scale with a larger team where everyone may have their own preferences in AI tools . The repository accumulates skills and other artifacts that automatically end up loaded into the context. On one full-stack monorepo I worked on, we had a heavily guardrailed agentic harness that on every request triggered a very token-hungry validation pipeline, especially...