How to Run a Capability-First AI Consulting Kickoff

An AI consulting kickoff is complete when the buyer can see what the team will own after the meeting. A list of ideas is not enough. Neither is a polished architecture diagram.

The sourceable atom in this article is a completed capability handoff record. It makes the workflow, owners, safe boundary, first test, and commercial decision visible in one place. Use it to accept a kickoff, revise it, or stop before a vague pilot gets funded.

What should a capability-first kickoff produce?

It should produce one completed handoff record for one recurring workflow, with a capability owner and a decision owner. The record is the acceptance object. The kickoff is not complete if the consultant owns the next test or if the team cannot repeat the work without help.

The worked record below uses a bounded support-triage fixture. It is deliberately narrow: an incoming support thread and the current escalation policy enter the workflow; a draft escalation note leaves it for a manager to review.

Field	Completed record
Workflow input	Incoming support thread plus the current escalation policy
Workflow output	Draft escalation note for a Customer Support Manager
Capability owner	Support Operations Lead
Decision owner	Customer Support Manager
Capability statement	The support team can map the case, run the read-only draft step, inspect the policy evidence, record corrections, and decide continue, revise, or stop without the consultant.
Safe first test	Draft only. No customer message, account change, refund, or priority change is sent automatically.
Human review	The Customer Support Manager checks the source thread, policy reference, proposed priority, and next action before any operational use.
Initial observation	The workflow crosses intake, support operations, and manager review. The handoff record keeps those roles visible instead of treating the model output as the business decision.
First milestone	Run representative cases in shadow mode, record corrections, and review the evidence on 2026-09-06.
Decision rule	Continue if the team can repeat the bounded step and review its corrections. Revise if the output is useful but the boundary or ownership is unclear. Stop if the result cannot be checked safely.
Rejected idea	Automatic customer sending is deferred because the approval boundary has not been demonstrated.

This is a worked decision artifact, not a claim about a client's result. Its value is that another buyer can inspect the acceptance fields and replace the fixture with a real workflow. The NIST AI Risk Management Framework also treats context, roles, oversight, measurement, and lifecycle decisions as part of responsible AI work, which is why those fields belong in the kickoff record rather than in a later appendix (NIST AI RMF).

If the meeting produces only a prioritized use-case list, call it discovery. Do not call it a selected pilot. The difference is the handoff: someone inside the buyer's team must own the capability and someone with authority must own the decision.

How do you run the kickoff on a real workflow?

Start with one input and one output from work that already happens. Then map the people, decisions, exceptions, and review boundary before discussing a model or vendor. OpenAI Academy's discovery material similarly starts with work and a smallest credible proof point, rather than beginning with an AI feature list (team use-case brainstorm playbook, AI use-case discovery and prioritizer).

Use this sequence:

1. Bring one real case. Capture the input, current action, handoffs, output, exception, and consequence. If the group cannot show the input and output, keep the session exploratory.
2. Name two owners. The capability owner will run and improve the workflow. The decision owner can continue, revise, or stop the next phase. They may be the same person, but the record must say so.
3. Write what the team can repeat. Describe the smallest useful action the internal owner can run, inspect, correct, and explain without the consultant.
4. Draw the safe boundary. Keep external actions, irreversible changes, and consequential decisions human-owned until the review step has evidence.
5. Set the first milestone and review date. Decide what the team will inspect, who will inspect it, and what evidence can produce continue, revise, or stop.
6. Record one rejected idea. A deferred action shows that the kickoff made a decision. It also keeps commercial pressure from silently expanding the first test.

The blank handoff template is intentionally plain. Copy it into the buyer's working document and fill every field with evidence from the workflow.

{
  "workflow": {
    "input": "",
    "current_action": "",
    "output": "",
    "handoffs": [],
    "exceptions": [],
    "consequence": ""
  },
  "owners": {
    "capability_owner": "",
    "decision_owner": ""
  },
  "capability_statement": "",
  "first_test": {
    "allowed": [],
    "forbidden": [],
    "human_review": ""
  },
  "baseline_observation": "",
  "first_milestone": "",
  "evidence_review": {
    "date": "",
    "continue_if": "",
    "revise_if": "",
    "stop_if": ""
  },
  "rejected_or_deferred_idea": ""
}

The template is an artifact, not a substitute for observation. Fill it from a real input and output. A consultant can facilitate the conversation, but the completed record must remain useful when the consultant leaves.

How do you test the handoff before expanding the engagement?

Run a field check before approving the next phase. The check asks whether the artifact is complete, not whether the AI output is impressive. Keep the first test read-only, require a human review, and store corrections as evidence for the next decision.

This small configuration represents the completed support-triage record:

workflow_input: incoming support thread plus escalation policy
workflow_output: draft escalation note
capability_owner: Support Operations Lead
decision_owner: Customer Support Manager
capability_statement: team can run, inspect, correct, and explain the bounded draft step
safe_first_test: read-only draft with no send, refund, account, or priority action
human_review: manager checks source, policy, priority, and next action
baseline_observation: three role boundaries are visible in the handoff
first_milestone: shadow-mode cases reviewed on 2026-09-06
evidence_review: continue, revise, or stop on 2026-09-06
deferred_idea: automatic customer sending

The recorded local check output was:

PASS workflow input and output are present
PASS capability and decision owners are present
PASS capability statement is repeatable without the consultant
PASS first test is read-only and has a human review
PASS baseline, milestone, evidence review, and deferred idea are present
DECISION: REVISE before expansion if any case needs an unowned exception

The output is useful because it exposes a decision boundary. It does not establish model accuracy, savings, or adoption. Those questions belong to the evidence review attached to the real workflow. A safe kickoff test can therefore produce a commercial decision without pretending that a draft-only fixture is production proof.

When should the buyer continue, revise, or stop?

Continue only when the internal owner can repeat the bounded step and the decision owner can inspect the evidence. Revise when the workflow is useful but ownership, exception handling, or review criteria remain unclear. Stop when the output cannot be checked safely or when the proposed action crosses an unowned authority boundary.

Decision	Evidence in the handoff	Buyer action
Continue	The input and output are real, the internal owner can repeat the step, the reviewer can see the supporting evidence, and the next test stays within the safe boundary.	Fund the next bounded test and keep the review date.
Revise	The draft is useful, but a role, exception, baseline, correction path, or acceptance rule is unclear.	Repair the record and repeat the smallest test.
Stop	The result cannot be checked, the owner cannot act, or the proposed action is consequential without a proven review boundary.	Do not expand the engagement. Preserve the evidence and reconsider the workflow.

The principal exception is a discovery-only kickoff. It can end with open questions and candidate workflows, but the buyer should not treat its output as a pilot commitment. Schedule the handoff that will name the owner, first test, and evidence review.

This acceptance logic fits Marius Manolachi's AI consulting and tutoring work because the commercial result is meant to make existing people capable of building on their own work. If you want help facilitating the record, learn about Marius's AI consulting and tutoring. Keep the artifact with the team.

For the wider commercial choice, start with the AI buying decisions parent page. When comparing proposals, use how to compare AI consulting proposals and ask each provider what your team will be able to repeat without them.

Continue with a related field note

• What Evidence Distinguishes AI Tutoring From Implementation?