What does an embedded engineering engagement look like week by week?

Four phases: embedded discovery measured in days (the workflow mapped from inside, de-risked with a working prototype), a production pilot measured in weeks (the first real system shipped to real users), hardening where enterprise reality demands it (SSO, access control, audit, reliability), and the handover that ends the dependency.

How long does a forward-deployed engagement take?

Discovery runs seven to ten days. A production pilot runs two to four weeks. Hardening, when needed, runs three to six or more. Each phase is fixed-scope with its own exit, so the honest total for a first production system is measured in weeks, not quarters.

What does the client have to provide during an embedded engagement?

Three things decide the pace: a workflow owner who can make decisions, reachable data and systems, and honest access to the people who run the queue. Engagements stall on missing owners far more often than on missing technology.

Can an engagement end after discovery?

Yes, by design. Discovery sometimes concludes that the right fix is a process change or boring automation, or that the volume does not justify a build. That exit costs days instead of a failed project, and a provider who has never taken it is selling the label, not the discipline.

Anatomy of an embedded engagement, week by week

The short answer

An embedded engagement runs in four fixed-scope phases: discovery inside the workflow (days, ending in a working prototype or an honest "do not build"), a production pilot (weeks, ending with real users on a real system), hardening (when the system must survive enterprise reality), and the handover that transfers code, prompts, infrastructure, and evals. Every phase has an exit, which is what makes the model buyable.

"We embed with your team and ship in weeks" is the pitch of every studio in this category, including ours. Pitches deserve anatomies. Here is what the weeks actually contain, phase by phase, with the exits marked.

The shape

The engagement timeline · four phases, each fixed-scope, each with an exit

Phase 1 · Embedded discovery (7 to 10 days)

The engineer sits inside the workflow: watching the queue, mapping the process as it actually runs, counting volumes, and finding where the exceptions live. The deliverables are a workflow map, a build-ready scope, and a working prototype against real data, because a prototype settles arguments that documents start. The phase has two honest exits: a fixed scope for the pilot, or the finding that the right fix is process change or boring automation. The entry point that starts it is the Workflow Audit, which is discovery's thirty-minute ancestor.

Phase 2 · Production pilot (2 to 4 weeks)

The first real system, shipped to a first group of real users: the end-to-end workflow, the integrations that make it act in your systems, auth and access, deployment in your cloud, and evals gating the launch. Not a demo with a countdown clock: the six-step crossing compressed into one deliberate phase. The exit is measurable: named users doing real work through the system, with the baseline numbers to prove what changed.

Phase 3 · Hardening (3 to 6+ weeks, when reality demands it)

Some systems ship into gentle environments and stop at phase two. The ones facing enterprise reality get hardened: SSO and role-based access, audit logs, expanded evals and monitoring, reliability and security work. This phase exists as its own scope because bundling it into every build would tax the operations that do not need it, and skipping it where it is needed is how production systems quietly fail their first security review.

Phase 4 · Handover (the finish line)

The engagement ends when the dependency does: code in your repositories, prompts documented, infrastructure in your cloud, evals transferred with their baselines, credentials under your control, runbooks written, and a cold-start test where your side redeploys without us touching anything. The full specification is the ownership handover. Staying afterwards is an option we have to earn, never a default we engineered.

Every phase has an exit. That is what makes embedded engineering buyable instead of open-ended.

What the client provides

–A workflow owner who decides. One person who can say yes, reachable through the engagement. Engagements stall on missing owners, not missing technology.
–Reachable data and systems. Access arranged in week zero, because discovery against screenshots is a brief wearing a disguise.
–The people who run the queue. Hours of their honesty, early. The system that gets built is the one their exceptions describe.

That is the anatomy. The model scales down cleanly, which is why the tier the enterprise programs skip buys it as a service with the same phase structure, and why every phase's duration above is quoted from the real engagement scopes, not aspiration.