raise: atomic AI agent config profile switching

The name is a homophone. Raise. Rice-aise. Either way, it’s the tool that solved a config-drift problem that was quietly making me slower every week for months before I admitted it was a problem.

Why it exists

I consult. That means different clients, different codebases, different context windows, and — critically — different agent configurations. The Claude Code system prompt for my infrastructure client needs to know about their Terraform layout, their naming conventions, their PR process. The same for a product startup looks completely different. Gemini CLI has a separate config format. Codex has another one. OpenCode has another one. Pi has another one.

At one point I counted: I was managing bespoke configuration files across seventeen AI coding tools for four active client engagements. Not profiles — flat files. I was hand-editing them before context-switching between clients, which meant I was routinely forgetting to update one tool, starting a session with the wrong system prompt, and producing outputs that were subtly wrong for the context I was actually in.

The discipline fix — “just be more careful” — doesn’t compound. I needed the tooling fix.

How it works

raise is a single Go binary. It reads a directory of named profiles, where each profile is a directory tree that mirrors the config locations for the tools you want to manage. When you run raise use <profile>, it performs atomic symlink swaps across every configured tool location simultaneously.

Atomic is the key word. The old approach to this problem — “write a shell script that copies files” — has a failure window. If the script errors halfway through, you’re in a hybrid state where some tools have the new config and some have the old one. That’s worse than either clean state. Raise uses symlinks instead of copies and swaps the symlink target in a single rename(2) syscall per location, which is as atomic as you can get on a POSIX filesystem.

Credential preservation is the part that took the most thought. API keys, auth tokens, and session credentials live in the same config directories as system prompts and tool settings. You don’t want those rotated out with the profile — they’re per-machine, not per-engagement. Raise has a credentials manifest per tool that identifies which config keys or file sections are credential-adjacent and excludes them from the swap. The profile stores a template with placeholders; the swap layer fills them from the local credential store before writing.

Supporting seventeen tools required auditing seventeen different config conventions. Some tools use ~/.config/<tool>/config.json. Some use ~/.toolrc. Some have a directory, some have a single file, some have both and each means something different. The tool registry in raise encodes this per-tool — where the config lives, what the format is, which fields are credentials. Adding a new tool is three additions to the registry and a test fixture.

What’s interesting

The part that surprised me: the hardest tool to support wasn’t the obscure one. It was Claude Code, which has a layered config hierarchy — global settings, project settings, local overrides — and meaningful semantics about which layer wins. A profile swap that clobbers the project layer breaks repos that have project-specific settings checked in. Raise has to be aware of the layer semantics and only touch the layers it’s supposed to touch.

The other surprise was how much resistance I felt to building this tool in the first place. There’s a strong pull in developer tooling toward “I should just be more disciplined.” That instinct is wrong. Discipline is for things that genuinely require judgment; config file management is not one of those things. If you’re doing something by hand more than twice a week and it’s not teaching you anything new, you should automate it. No exceptions.

The name came from a conversation about the prompt-engineering concept of “raising the floor” on agent outputs. A profile that’s wrong for the context actively lowers the floor. Raise keeps it where it belongs.

What I’d change

The credentials manifest is currently hand-maintained. I want a first-run wizard that inspects your existing config files, identifies credential-shaped values (API key patterns, token formats, bearer strings), and proposes a manifest automatically. The information is there; it just requires a read pass and some heuristics.

I also want a raise diff <profile-a> <profile-b> command. Right now you have to eyeball the profile directories yourself. A structured diff that highlights system-prompt changes separately from tool-setting changes would make profile auditing much faster, especially when you haven’t touched a client engagement in a few weeks and can’t remember exactly what you configured.

The profile format is currently directory-based, which is flexible but not portable. I’ve been thinking about a single-file profile format — something like a TOML bundle that can be shared via a git repo or a gist — so you can version-control your agent configurations alongside your actual projects. That’s the natural next step for making this genuinely multi-person.