Multi-tenant agents: tenant differences are data, not control flow

We started where everyone starts: an agent framework with graphs and branches. It worked for one tenant. By tenant three, the graph was sprouting conditional edges per customer; by tenant five, every onboarding meant a code change, a review, and a deploy for what was fundamentally configuration. The insight that fixed it: tenant differences aren't control flow, they're data.

The replacement is a workflow engine driven by per-tenant YAML. The engine knows the invariant shape of the work, intake, verify, prepare, execute, review. The YAML declares each tenant's specifics: which steps are on, what rules gate them, which integrations they bind to, what the escalation thresholds are. New tenant means a new config file, not a new branch in a graph.

Frameworks earn their keep in the prototype phase and start charging rent in production. Ours went from accelerant to bottleneck the moment per-customer variation became the dominant source of change, which, in B2B, it always becomes. The framework's job was to be replaced; I just wish I'd scheduled the replacement instead of discovering it.

Results: onboarding a new site dropped from weeks to under one; one fully-customized deployment went live two weeks after kickoff. Config changes are reviewable by non-engineers, diffable in git, and testable against the same eval suite. The 'boring' architecture, an interpreter over declarative config, beat the exciting one, which is the oldest lesson in software wearing a new agent costume.