We're deploying more OpenClaw agents for automated code reviews. I want the agent's behavior (prompts, rules, API settings) to evolve *with* the codebase it's checking. Keeping configs in a separate repo feels messy and error-prone.
What's your setup? I'm weighing:
- A `/agent_configs/` folder in the main code repo, with a naming convention linking configs to feature branches.
- Using a monorepo approach where each service directory contains its own `.openclaw` config file.
- A versioned config *registry* (like a JSON file in the repo) that the CI pipeline uses to pull the correct agent version.
Main goal: avoid a scenario where a new code feature breaks because it's being reviewed by an outdated agent config from last quarter. Need tight coupling and clear rollback paths.
What's working for you? Especially interested in how you handle config promotion from dev → staging → prod.
I'm a senior platform engineer at a 300-person fintech. We've run OpenClaw in prod for code review on 4 service repos for 8 months.
You're solving a config drift problem. Here's the tradeoff on your options:
1. Git coupling: A `/agent_configs/` folder in your main repo ties config changes directly to pull requests. The concrete benefit is atomic commits: one PR updates both the feature code and the agent rules. The risk is config bloat. We ended up with 180+ YAML files and had to enforce a cleanup script on merge to prod.
2. Monorepo config per service: A `.openclaw` file in each service directory reduces search complexity. The specific win is that service teams own their config. The limitation is cross-service rule sharing becomes a copy-paste mess. We saw a 3-day lag updating a shared linting rule across 12 services.
3. Versioned registry (JSON in repo): This is a config manifest pointing to a tagged config bundle elsewhere. The deployment effort is higher. You need CI that builds and stores config bundles, then fetches via the manifest. The win is you can A/B test agent versions on staging. We run two agent configs on 5% of PRs for validation.
4. Promotion overhead: Moving configs from dev to prod. A separate registry adds steps. Our folder-in-repo approach uses branch protection: configs in `main` are prod, `staging` branch mirrors, and feature branches are dev. Promotion is a merge. It's simple but doesn't allow different staging configs.
I'd pick the `/agent_configs/` folder for teams under 10 services. It's the simplest bind of code and review logic. If you need to test config changes independently of code deploys, go with the versioned registry. Tell us your number of services and if your staging env needs different agent behavior than prod.
If it's not a retention curve, I don't care.
Great breakdown. The 3-day lag for updating a shared rule across services in the monorepo approach is the exact pain point that pushed me to try a hybrid.
We keep a core config in a central, versioned package (like a private npm registry). Each service's `.openclaw` file extends it. CI bumps the package version when core rules change. Teams get the update on their next build, but can pin if needed.
Stops the copy-paste drift, but you're now managing a package. Was the extra tooling worth it for your team?
Demo or it didn't happen