blog

June 8, 2026

Install your guardrails from a Git repo

Governed agent behavior shouldn't be hand-written per project. Publish a pack to a Git repo, compose any number of them, and update with a git pull.

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. It worked. Then you started the next project and copied it all in.

By the third project you had three slightly different versions, and somewhere in the drift 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

Anyone 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. Each fork is a small deviation you don’t notice until something breaks — then you audit all three versions, work out which is canonical, and apply the change everywhere by hand. Again.

It doesn’t have to be this way. 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 workflows it follows, the model choices it makes, the connections it’s allowed to open (Praxec calls the whole bundle a pack) — are data. They describe what an agent may do, in a format a human can read and review. They don’t belong compiled into a binary or tangled into a startup sequence where they can’t be diffed or audited on their own. Data can live in a repo, be versioned with a tag, and be updated with a pull.

Compose, don’t fork

Point your config at any number of pack repos, composed however fits your context:

version: "1.0.0"
repos:
  - path: ~/repos/praxec-baseline     # a proven baseline
  - path: ~/repos/acme-policy         # your company's gates
  - path: ~/repos/my-flows            # personal tweaks

Every layer loads under its own namespace and is collision-checked at load — if two repos define the same id, praxec check fails loud rather than letting one silently win, so a deliberate override of a baseline rule has to be explicit and is audited. Fix the base once, git pull, and every project inherits it. Like extending a base ESLint config or a Docker base image, but for what your agent is allowed to do.

The copy-paste tax was never the price of reuse. It was the price of not having a place to put the shared thing.

← All posts