landing an embed

Deployment

An FDE engagement against a role shaped like this one runs as an embed — roughly eight weeks, one process expanding to dozens once the first one is proven. The tooling here is built for that tempo directly: deployment two should be faster than deployment one, and every deployment should carry its own regression protection so expansion doesn't quietly erode what already works.

From the record. Customer-facing deployment is an existing rep, not a projection: field work at State Farm ran as customer-facing deployments — occasionally multi-day, on-site with the customer's team. The tooling on this page exists to make exactly that kind of engagement repeatable: deployment two faster than deployment one.

newdeploy — one pass, one kit

A per-customer deployment CLI that stamps a deployment kit under deployments/<slug>/ from an inert template tree, unifying three companion artifacts that would otherwise be assembled by hand every time:

MCP connector config

A connector-config env file and an .mcp.json wiring the four servers to the customer's actual SaaS dialects — SAP, NetSuite, or Dynamics for ERP; SPS Commerce, Coupa, or Ariba for the supplier network; and so on, validated against an allowlist.

Exception-spec board

Copied in full — self-contained, single-file — the one place the FDE authors this customer's rules. An --isolate-board flag rewrites its storage key so multiple open deployments never collide in one browser.

ROI baseline sheet

A baseline JSON plus the honest-ROI report template, ready to compute the customer's own before/after numbers once real operational data is loaded.

Two token layers stay separate on purpose: {{UPPER_SNAKE}} scaffolding tokens are substituted once at stamp time; <<UPPER_SNAKE>> authoring tokens are left intact for the FDE to fill inside the board itself. The CLI never reads the clock — same inputs, byte-identical output — and refuses to overwrite a non-empty target by default.

The exception-spec DSL as the approval-gate surface

Per customer, the exception-spec board is where the mapping layer's output becomes agent configuration: which decision rules apply, which exceptions get their own path (and exceptions-of-exceptions), what the fallback is when nothing matches, and — the governance surface itself — which actions the agent may take on its own versus which ones wait on a human, per action, per customer. The board exports a policy file that the eval pack and the MCP kit both consume unchanged; the export round-trips through the real policy loader, so what the customer's team configures is exactly what runs, not an approximation of it.

Corroboration — the same shape elsewhere. A thin declarative contract over a fixed engine isn't something I built for this; it's a habit. inkSpec, a single-file rendering engine I ship publicly, lets a whole design system plug in as a token-only pack while foreign vocabularies enter through adapters — a pack-swap test proves the engine renders any of them identically with no engine edit. Different domain — document rendering, not supply chain — but the same architecture as the board above: the per-newcomer surface stays small and declarative, the engine underneath stays fixed.

Expand with regression protection

Going from one process to dozens is where an ungoverned expansion quietly breaks something that used to work. Two mechanisms carry over from evaluation into deployment: replay makes each customer's case set reproducible with no live model call, and scorecard regression diffing checks a policy change against the last known- good run before it ships — the same re-run-to-verify discipline Duvo applies to its own process maps, applied here to what the agent is configured to do.