An AI delivery-model worksheet: assign the work before you staff it.

AI staffing supplies people with relevant skills to a team that owns the backlog, architecture, review process, and release decisions. AI consulting can establish strategy, priorities, architecture, and governance. AI implementation carries an agreed workflow through integration, evaluation, deployment, and operation. Forward-deployed engineering brings senior engineering work into the client's operating context and connects those decisions to delivery.

These categories overlap in real engagements. A consultant may also implement. A staffed engineer may take substantial responsibility. The useful comparison is the work each agreement assigns, the authority the client retains, and the evidence required for acceptance. Read those terms before comparing job titles or daily rates.

Write down one business workflow and its current constraint. Perhaps the team has a clear integration design but lacks a backend engineer. Perhaps it has a prototype but nobody owns exception handling, access approval, evaluation, or the operating handoff. Those are different purchases. Adding capacity to the second situation leaves the ownership gap in place.

For staff augmentation, specify the engineering capability, repository and environment access, reviewing lead, backlog owner, and service expectations. The client team must have enough capacity to review the additional output. Measure the contribution against accepted work and maintainability, alongside the agreed staffing terms.

For an advisory engagement, identify the decisions the advice will enable. A useful deliverable can be a prioritized workflow portfolio, architecture options with tradeoffs, or an implementation plan with named owners. State who turns that advice into software and how the receiving team accepts the plan.

For an implementation or embedded FDE engagement, name the workflow outcome, system boundary, evaluation set, integration responsibilities, release authority, operating owner, and handoff exercise. Scope uncertainty explicitly: discovery may change the design, while a written change process controls the resulting work.

1. Capacity gap: a client engineering lead owns the implementation; recruit the specific missing skill.
2. Decision gap: the client needs evidence and options; commission a bounded assessment with a decision owner.
3. Delivery gap: the workflow crosses systems and teams; assign an implementation owner with acceptance obligations.
4. Operating gap: the system exists but reliability, support, or adoption is unresolved; define a service-improvement mandate and receiving team.

Consider a synthetic enterprise service-desk project. Staff spend time finding the relevant procedure, checking whether it applies, drafting a response, and updating a ticket. The intended AI workflow retrieves approved guidance and prepares a proposed update. A human reviews consequential changes. This is an illustrative decision exercise, not a customer outcome.

If an existing product team already owns access controls, the ticket interface, evaluation cases, and support, a specialist engineer may close the remaining retrieval or integration gap. If nobody can decide which procedures are authoritative or who may update which ticket, the project first needs discovery and operating ownership. A better model will not resolve those decisions.

The implementation brief should identify allowed sources, the proposed ticket fields, the approving role, duplicate-update protection, and the escalation path when sources conflict. It should also identify who measures operator rework and whether the receiving team can recover from a failed update. Those obligations turn a demonstration into a reviewable delivery scope.

A useful work sample starts with an incomplete requirement and a small, synthetic system. Ask the engineer to identify assumptions, define a test, inspect an error, and explain a release decision. Assess the reasoning and artifact together. A polished demo or a list of model names gives you less evidence of how someone will handle an enterprise exception.

Separate the skill dimensions: software engineering, AI evaluation, systems integration, domain discovery, security boundaries, and communication with the operating team. Choose weights for the actual role. A research-heavy evaluation role and an embedded implementation lead should not receive the same scorecard by default.

Use training to close specific gaps and reassess against new work. A course completion record establishes participation. A reviewed implementation exercise provides different evidence. Keep the task, rubric, assessor, date, environment, and limitations beside any capability rating so a staffing decision can be interpreted later.

Start with a small set of acceptance conditions tied to the workflow. Include useful behavior, unauthorized requests, ambiguous inputs, source freshness, integration failure, and recovery. Preserve the system version and the reviewed cases. Name the person who can accept residual risk and the person who receives operational ownership.

The worksheet below makes those responsibilities explicit across four delivery models. Fill it out with the business sponsor, engineering lead, security owner, and prospective delivery partner. An empty owner cell is a concrete issue to resolve before procurement concludes.

LockedIn Labs provides enterprise AI consulting and implementation through forward-deployed engineering. The starting conversation is the operating problem and the evidence an engagement should leave behind. Use the production acceptance framework to turn that conversation into a scoped review, then use the learning and assessment resources to develop the team that will operate it.