I was solving agent portability at the wrong boundary

A developer has detailed a new approach to agent portability that avoids centralizing methodology behind MCP, instead decomposing shared behavior into scopes such as always-on policy, shared tools, reusable procedures, and repo files. The approach was tested in a timed AI-native product-build interview, demonstrating that the methodology works across repos without copying product-specific assumptions.

Copying the last repo's agent setup into a new one worked at first. It also copied product-specific assumptions. Once I had several active projects, there was no longer a single canonical repo I could copy from. Every improvement now had several places it could drift. I was doing that across Codenames AI https://codenames-ai.com/?utm source=devto&utm medium=article&utm campaign=agent-portability-does-not-require-centralizing-methodology-behind-mcp&utm content=intro , a portfolio site, and a resume generator. Shared workflows for planning, editorial work, dependency upgrades, review, and repo bootstrap had accumulated around them. Some still lived inside product repos simply because that was where they had evolved. I wanted the next repo to start with the methodology already available, without cloning the implementation details of the last product. My first instinct was to solve that with an MCP-shaped architecture. Extract the shared behavior into a separate repository. Expose it through a remote tool boundary. Every repo could call the same capability when it needed merge-safe planning rules or editorial workflow guidance. That felt rigorous. One service. One contract. One place to version policy. The idea lived in notes and conversation: treat portable agent policy the way you would treat a remote tool. Building it would have bought a clean contract. It would also have attached the baggage that belongs to real tools: That overhead makes sense when the capability is genuinely external: query Notion, pull PostHog metrics, deploy through Vercel. It does not make sense when the capability is mostly operating methodology : how to slice plans, when to stop after opening a PR, how to keep merge-safe invariants explicit. Planning standards and merge-safe workflows are agent policy and procedure. They are not remote resources waiting behind a tool boundary. I never built that service. I did not need to. The decomposition was the work: what should follow me into every repo, what should stay behind a tool boundary, what should stay with me as procedure, and what must live in the repo itself. I happened to implement that split in Cursor user-level rules, MCP config, installable skills, repo files . The architecture is the scopes: | Scope | Role | What belongs here | |---|---|---| Always-on policy | Invariants in every repo | Short rules: execution authority, repository topology, stop-after-open, tool preferences, pointer to planning methodology. | Shared tools | External tool boundaries | Notion, PostHog, Vercel after you authenticate the service. | Reusable procedures | Workflow installation | Full portable skills such as staged planning and new-repo bootstrap. | Repo files | What must live in the repo | Stable mechanics local hooks, remote environment lifecycle, CI and product knowledge AGENTS.md , domain rules, product skills, review guides | Always-on policy kept a pointer to the planning methodology instead of a second copy of it. Copying one product repo's harness into another just to match would have recreated the drift. Shared tools stay behind that authenticated service boundary. Reusable procedures stay at user level. The new repo does not store those skills. I run bootstrap once to write stable mechanics into repo files. That step does not copy the skill into the repo, and it does not write product knowledge because it varies by product. The scopes also have different update semantics: policy changes flow across existing repos, while bootstrap changes become the baseline for new ones unless I explicitly migrate older repos. The first serious cold-start test was a timed AI-native product-build interview. I used the same scopes in a genuinely new repo under time pressure. The interview proved the methodology did not depend on my existing repos. It also showed that too much generic setup still had to be reconstructed in an empty one. The agent put instructions in the README instead of AGENTS.md . Hooks that should have wired the remote agent environment were not reliably set up. Setup that was obvious in my established repos was not obvious when an agent had to invent it under time pressure. Policy, procedures, and shared tools were already available. What failed was leaving stable repo mechanics to be rediscovered. An empty repo still has to run those hooks and that remote environment. The following week I converted more of that baseline into deterministic bootstrap: known-good scripts and templates for local hooks, remote environment lifecycle, CI, and other baseline infrastructure, not another round of agent redesign. The goal is not zero bootstrap. It is to stop spending agent reasoning on decisions I have already made. Takeaway: Splitting the problem by ownership and lifecycle showed I did not need an MCP-shaped architecture. Policy could stay always-on, procedures could stay at user level, stable mechanics could be materialized by running bootstrap, and the agent could spend its reasoning on the product.