Capability 04

From pilot to production, without a rebuild each time you switch.

Engineering that stands up the tools you chose inside the systems you already run. Identity, data and monitoring go in first. Provider code sits behind an interface you own.

Best fit: pilot to production

Downloads

take it to the meeting

Service sheets follow one standard across all six capabilities. Engagement status on each sheet is taken from the live catalogue.

The problem

what goes wrong

Pilots stall at the integration boundary. The model works; the plumbing doesn't. Identity, data pipelines and monitoring turn out to be the real project, and they were scoped as an afterthought.

The second failure is lock-in by accident. Build against one provider's conventions and switching later means rewriting the integration layer. In practice, that means not switching.

The third is meaning. Two systems define "customer" differently, and an agent reading both gives two answers. Shared definitions are a data job, and we flag it as a gap below rather than pretend we cover it.

What we do

four pieces

Integration architecture

A boundary layer between your systems and the vendor. Changing provider becomes an integration change, not a rebuild.

Data and identity wiring

Pipelines and access paths scoped to least privilege from the first commit, not tightened after a review.

Observability from day one

Cost, usage, latency and failure on one view before go-live. Inference cost scales with use, so the bill arrives just as the thing starts working.

Handover that holds

Runbooks written for the team who will operate it. They run it unaided before we sign off.

Tools & resources

how this service uses them

Free tool AI Roadmap Builder Prepare items held back by data or feasibility are the integration backlog, already in order. The Readiness part of the score tracks it closing. Build your roadmap → Research The enterprise AI stack Where integration failures show up, layer by layer. Open → Assessment Shadow Scanner Maps what is already connected to what before we wire anything new. Open →

Downloads for this service are above. All free tools run in your browser and need no email.

In the news4 stories

15 Sep 2026Salesforce Ben
Salesforce launches AIforce at Dreamforce ’26 and opens its platform to builders through MCPs and APIs
Why it matters here. Integration is moving from screens to APIs and MCP. Your boundary layer decides how portable that is.
11 Feb 2026Business Wire (CrewAI survey)
Data readiness and integration top the barriers to scaling agentic AI, CrewAI survey finds
Why it matters here. A vendor’s own survey, so read it as a signal. It matches what we see: pilots stall on the data path.
9 Dec 2025SD Times
Linux Foundation forms the Agentic AI Foundation as the new home for MCP
Why it matters here. Neutral governance makes MCP a safer bet as an integration standard.
24 Sep 2025GeekWire
Microsoft adds Anthropic’s Claude models to Microsoft 365 Copilot alongside OpenAI
Why it matters here. Even Microsoft runs more than one model provider. Being able to switch is a design requirement.

Picked for this service and checked against the source. More each Monday in The Weekly Brief.

What good looks like

5 of 7 covered

What buyers are increasingly measured against here, taken from the frameworks doing the measuring. Each line names the engagement that covers it. Where nothing does yet, the row says so.

Capability	What done properly looks like	Covered by
A boundary layer between you and the vendorPortability practice	Provider-specific code sits behind an interface, so switching is an integration change rather than a rebuild.	4.1 Integration Architecture Review
Least privilege from the first commitZero-trust practice	Access is scoped at build time, not tightened after a review finds it wide open.	4.2 Pilot-to-Production Sprint
Cost and reliability observability on day oneFinOps practice	Spend, latency and failure rates are instrumented before go-live and watched together, not added after the first surprise invoice.	4.2 Pilot-to-Production Sprint
One workflow taken properly to productionDelivery practice	Scope is a single workflow with a defined done, rather than three pilots left at eighty percent.	4.2 Pilot-to-Production Sprint
Shared definitions for the terms agents useData management practice	Core business terms are defined once and used by every system an agent reads, so two agents cannot give two answers to one question.	Not yet offered
Operational handover that is testedITIL · Service transition	The receiving team runs it unaided in a working session before sign-off.	4.3 Runbook & Handover Pack
Rollback and removal defined before deploymentChange management practice	The path back — switch it off, undo its changes, take the data out — is written and rehearsed, not improvised during an incident.	Not yet offered

Sample report: 808 Boundary Map

808 demo dataset

Lakeshore Example Co. · Fictional demo company · sample data, not a client

Fictional demo company · sample data, not a client

Lakeshore Example Co.

A fictional 1,200-person distributor we use to show what our reports look like. Every number below is invented for the demo.

3 systems wired through one boundary layer: ERP, CRM, data
3 crossings, each with identity, data path and monitor
Model provider swapped in a test: config change, no rewrite
One workflow live: order-exception triage

Engagements & products

status shown

The deliverables behind this capability. We publish what is live and what is still being built rather than implying a bench we don't have.

4.1 Entry Planned

Integration Architecture Review

Fixed-fee engagement · 1–2 weeks

How your chosen tool will meet the estate you already run — identity, data pipelines, monitoring — and where lock-in would quietly build up. The output is a boundary-layer design, so providers can change without a rebuild.

Shadow Scanner The scan maps what the new tool has to coexist with, including the things nobody documented.
4.2 Anchor engagement Planned

Pilot-to-Production Sprint

Fixed-fee engagement · 4–8 weeks

We take one stalled pilot into production: integration layer, least-privilege access, and observability on cost, usage, latency and failure from day one. One workflow, done properly, rather than three left half-finished.

Shadow Scanner Findings are paired with migration destinations and sequenced by exposure rather than by whichever is cheapest.
4.3 Anchor engagement Planned

Runbook & Handover Pack

Deliverable artifact + working session

Documentation written for the team who will operate the thing, not the people who built it. Then a session where they prove they can run it without us. That is what makes "we don't create dependency" checkable.

Shadow Scanner A closing re-scan evidences what actually moved, so handover is a fact rather than an assertion.

Status is kept in one place and shown as it stands. See the full catalogue across all six capabilities.

How Shadow Scanner helps

platform intelligence & risk telemetry

A finding needs a destination. Shadow Scanner pairs each detected tool with the sanctioned platform it should move into. That turns an assessment into an ordered piece of work.

More about Shadow Scanner

What you walk away with

the outcome

A production deployment your own team can operate, extend and, if it comes to it, migrate off — without the original engineers in the room.

The trade-off. One workflow done properly ships later than three pilots left at eighty percent. It is also the only one of the four that reaches production.

The five stages

Tell us what you're running.

A person replies within one business day.

Talk to us