Stop copy-pasting your agent's guardrails into every project

You got tired of your coding agent skipping tests, shipping before CI was green, and self-approving its own changes, so you built the guardrails that stop it: a state machine where deploy isn't a move until tests pass, an approval gate the agent literally can't submit on its own, the model choices that actually behaved. It worked. Then you started the next project and copied it all in.

By the third project you had three slightly different versions of those guardrails, and somewhere in the drift between them a bug fix you applied to one never made it to the other two. You couldn't even be certain which version had it. The rules that were supposed to keep your agent honest had quietly become something you couldn't trust.

The copy-paste tax

Every Claude Code or Cursor user who has built real guardrails hits this. The only way to reuse a setup you trust is to fork it, and the moment you fork it you own a second copy that drifts from the first the instant either one changes.

The copy-paste tax compounds quietly. Each fork is a small deviation you don't notice until something breaks. Then you have to audit all three versions, work out which one is canonical, and apply the change everywhere — manually, again. You repeat this every time the guardrails evolve. It eats hours, and you accept it because "that's just how configuration works."

It doesn't have to. The reason copy-paste is the default isn't that reuse is hard — it's that reuse requires a place to put the shared thing. Give the guardrails a home and the whole problem dissolves. That's what a Git repo is for.

Your guardrails are content, not code

Your agent's guardrails — the skills it can use, the workflow it follows, the model choices it makes, the connections it's allowed to open (flowgate calls the whole bundle a cognitive architecture) — are data. They describe what an agent may do, in a format a human can read and review. They are not application logic embedded in a codebase. They do not belong compiled into a binary or tangled into a server's startup sequence where they can't be diffed or audited on their own.

Data can live in a repo. It can be versioned with a tag. A proposed change can go through a pull request and be reviewed by a security team before it ships. A release can be pinned, so projects don't silently pull a breaking change on the next restart. That's the entire unlock: the thing that decides what your agent is allowed to do becomes a dependency you manage, not a snowflake you re-handwrite from memory every time you start a project.

This isn't a novel insight about agents — it's the same reasoning that moved configuration into version control a decade ago. The reason it matters more here is that the stakes are higher. A misconfigured ESLint rule produces a noisy CI run. A misconfigured approval gate in an autonomous agent produces an action you didn't authorize in a system you can't easily roll back.

Load any number, compose freely

Operators wire repos in via a top-level repos: block in the operator config. Here's a representative example — not the prescribed structure, just one way a team might organize it:

version: "1.0.0"
repos:
  - path: ~/repos/cognitive-architectures   # proven baseline
  - path: ~/repos/acme-agent-policy          # company gates — an example
  - path: ~/repos/my-flows                   # personal — an example

Each repo loads with its namespaces intact, so a skill named acme:review_contract can't accidentally shadow the baseline's core:review_contract. Two repos colliding on the same namespace or skill ID fail loud at load time — load-time validation catches every form of ambiguity (a duplicate ID, two repos claiming the same name, a reference that resolves to nothing) before the server accepts a single request. No silent drift, no debugging a collision at 2 AM.

If you deliberately want one repo to override a skill or workflow from another — say, swapping out a vendored skill for an organization-specific version — the override must be declared explicitly in the config. It shows up in the audit log. There are no accidents in the dependency graph; every substitution is a conscious, visible choice.

The official/company/personal split in the example above is one reasonable pattern. It is not a hierarchy the runtime enforces. You might organize by domain, by risk tier, by team — whatever matches your deployment. The runtime doesn't care how you label the repos. What it cares about is that the composition is unambiguous and that every piece of the resulting architecture can be traced back to a source.

A dependency graph for agent behavior

Today the natural shape is: a public baseline of proven patterns, layered with a company policy repo enforcing whatever gates your legal and security teams require, optionally extended with personal or team-specific workflows for the work that's unique to your context. Each layer is pinned, reviewed, and pulled independently. Updating the company policy is a PR that gets reviewed; it doesn't require touching any of the projects that consume it.

The mental model is close to extending a base ESLint config or pulling a Docker base image — except what you're composing isn't a linter's rule set or a filesystem layer. It's the definition of what your agent is permitted to do. That makes versioning and supply-chain integrity more important, not less. A dependency graph for code has always been worth managing carefully. A dependency graph for agent behavior needs the same rigor.

The same model scales up to regulated orgs, too. Tomorrow, industry packs for specific compliance regimes — HIPAA data-handling constraints, SOC 2 audit trail requirements, fintech pre-trade controls — are a natural extension of the same model. An organization certifies a pack, pins a version, and every project that loads it inherits the controls without rewriting them. When the regulation changes, one PR to one repo propagates the update everywhere.

Try it in five steps

The fastest path is the golden path. It walks you through pulling the baseline cognitive-architectures repo, running enforced test-driven development against a commodity model to see the guardrails in action, and then layering your own repo on top once you have a feel for the shape. The whole sequence takes under ten minutes on a clean machine.

The key step is the third one: adding your own repo to the repos: block and watching the load-time validation catch any conflicts before the server starts serving requests. That moment — seeing the runtime refuse an ambiguous composition rather than silently picking one — is the most concrete demonstration of what a dependency graph for agent behavior actually buys you.

Once you've gone through the golden path, the logical next experiments are clear: pin the baseline to a release tag, watch what happens when you introduce an intentional namespace collision, and try pulling a company-policy overlay over the top. Each experiment takes a minute. Each one makes the composition model less abstract.

The full mechanics of how repos are loaded, namespaced, and validated are in Multi-repo loading. The broader picture of how skills, workflows, and model choices fit together into an architecture is in skills, workflows, and cognitive architectures.