Anatomy of EVC.

§1Why it exists: I was the bottleneck

EVC was never a product idea. It was a survival response. I was running multiple client engagements concurrently — each with its own brand voice, its own banned phrases, its own channels — and I noticed the same loops repeating across all of them: scan for what's relevant this week, plan content against it, draft, check it against brand rules, ship, log what happened. Every loop was manual, every loop leaked quality when I was tired, and every loop scaled linearly with my hours. So I started encoding the loops. Each command earned its place by replacing a manual process I was actually running that week — no roadmap, no speculative features, just commits whenever the friction got annoying enough. By the time it was load-bearing across three live deployments, open-sourcing it was the obvious move. More on why later.

The thing that distinguishes an operator framework from a demo is that distinction right there: every piece exists because real work demanded it. Forty-two commands sounds like a feature list until you understand it's actually a fossil record of two years of marketing operations.

§2The anatomy, layer by layer

Commands are markdown files. Each one — /intel-scan, /content-plan, /blog-qa, /client-onboard — is a markdown document describing a procedure: what to load, what to produce, what done looks like. Drop a new file into .claude/commands/ and it exists; no registration, no compile step. This matters more than it sounds. Because commands are plain text, a client's marketing lead can read every single one and understand exactly what the agent will do before it does it. Try auditing a SaaS tool's behavior that way.

Chains are commands composed into pipelines. The eight production chains cover the recurring shapes of marketing work — content production, community ops, BD support, weekly reporting. A chain is just a sequence with defined handoffs: the output of one command is the input contract of the next. The flagship is the content engine, which runs the loop I used to do by hand:

/intel-scan → /content-plan → [HUMAN GATE: you review the plan] → /content-draft → /content-qa → ship
auto · auto · ⊳⊲ stop · auto · auto · out the door

The canon is the constitution. Brand rules live in brand/canon-rules.json: USPs, voice rules, banned phrases, tone parameters. Every agent loads it at runtime; the guardrail hook enforces it on every step. Edit the JSON and the entire system updates instantly — every command, every chain, every future draft. This is the load-bearing connection between EVC and the Brand OS methodology I've written about before: the canon isn't documentation that describes the system, it's configuration that is the system. When a client decides a phrase is dead, it dies everywhere, permanently, in one commit.

Human gates are non-negotiable. Every chain has at least one point where the machinery stops and waits for a person. In the content engine, that gate sits between planning and drafting — the human approves what gets made before anything gets made, which is exactly where editorial judgment is cheapest to apply and most expensive to skip. I want to be precise about this, because "human-in-the-loop" has become a checkbox phrase: the gates aren't there because the output is bad. The hooks handle bad output. The gates are there because taste, timing, and strategic judgment are the operator's actual job, and a framework that automates judgment isn't an operator framework — it's a liability with a cron schedule.

The hooks block slop. The gates protect judgment. Confuse the two and you've either built a babysitting job or a liability with a cron schedule.

And the plumbing. Three context modes — content, build, research — switch what tools and references the agent reaches for. An MCP gateway connects to whatever the client already runs: Notion, Slack, Linear, X, GitHub. Persistent memory carries project state and decisions across sessions, so Monday's agent remembers Friday's call. And the whole thing installs from a tracked _templates/ directory through one setup.sh — your local canon merges with new defaults on update, no clobbering. config.env plus token substitution means one setup command and no per-user runtimes. The boring infrastructure is the point: every dependency you don't have is a failure mode you don't debug at 2am before a launch.

§3Why give it away?

EVC is MIT licensed. Fork it, audit it, run it without me, forever. People assume this is either naivety or a funnel trick. It's neither — it's an honest reading of where the value actually sits. The framework is the easy part. Anyone with enough sessions in Claude Code could eventually converge on something similar; the architecture isn't secret, it's just earned. What can't be forked from a repo: the design of your canon — the interviews and judgment calls that turn a brand's instincts into enforceable rules. The custom commands engineered for your team's specific motion. The hook tuning that catches your particular failure modes. The handoff that leaves your team running the system without me. That's the engagement. The repo is the proof that the engagement is real.

Gating the code would slow adoption while protecting nothing that matters. Opening it did the opposite: the framework now lives in Anthropic's Claude Code community, where it gets public review and a feedback loop with a hundred and forty thousand builders. Closed tools get marketing claims; open tools get audits. I know which one I'd rather sell against.

§4What it means that it ships with every engagement

Here's the practical consequence, and the reason this essay belongs on a portfolio site rather than a changelog. When an engagement with me ends, the client keeps a running system: their canon in version control, their commands documented in plain text, their hooks enforcing their rules on every future piece of content — whether or not I'm in the room. The deliverable isn't a strategy document about how content should be made. It's the machine that makes it, with the strategy compiled in.