AI Pilot Kickoff Meeting: Agenda, Attendees and Decisions

A useful AI project kickoff meeting agenda has eight parts, taken in order: purpose, the single role the agent will fill, the first users, data and tools, approval boundaries, success evidence, the working plan, and a written list of decisions. The room needs a sponsor, a process owner, the first users, someone who controls systems and access, and someone who answers for data and risk. You should leave with decisions that have owners, not a general feeling that the pilot is under way.

Key takeaways

• The kickoff turns a broad wish into one named role, with an owner, boundaries and a way to observe whether it works.
• Invite five kinds of people: a sponsor, a process owner, the first users, whoever controls systems and access, and whoever answers for data and risk.
• Keep the agenda in a fixed order so that scope is settled before tools, and tools are settled before the plan.
• Leave with written decisions, each with an owner, a review point and the conditions under which the pilot pauses.
• Do the preparation before the meeting, so the session is spent deciding rather than explaining.

Why does the first pilot meeting matter more than the first demo?

A demo shows what an agent can do. A kickoff decides what it is allowed to do, for whom, with which information, and how anyone will know it is working. Those choices are much harder to make later, once people have formed expectations and the agent has already touched real systems.

Most pilots that drift do so for ordinary reasons. The goal was phrased as an aspiration, nobody owned the process the agent joined, access was granted broadly because it was quicker, and no one wrote down what a good outcome looked like. None of these are technical failures. They are decisions that were never made, and the kickoff is the cheapest place to make them.

It helps to think of the meeting as a hiring conversation for a new role. You would not start a new colleague without a manager, a scope, a list of systems they may use and a sense of how their work will be reviewed. An agent deserves the same clarity, and arguably more, because it will act quickly and repeatedly on whatever you left vague. If you want to see how the stages differ before you begin, Proof of Concept, Pilot or Production: What Each AI Stage Must Prove sets out what a pilot is expected to demonstrate.

A pilot without a named owner is a demo with a calendar.

Who must attend the AI pilot kickoff meeting?

Keep the group small enough to decide, but complete enough that nobody can say later that they were not consulted. Five roles cover almost every pilot, and in a small company one person may hold two of them.

• Executive sponsor: confirms why the pilot matters, accepts the boundaries, and can approve or refuse changes to scope. Without this person, every open question escalates by email.
• Process owner: the person who runs the work the agent will join today. They know the exceptions, the unwritten rules and what a good result looks like in practice.
• First users: two or three people who will work with the agent daily. They tell you where the real friction is, and they are the first to notice when the agent is wrong. Choosing them well is its own task, covered in How to Choose the First Users for an AI Agent Pilot.
• Systems and access owner: usually IT or an operations lead. They decide which accounts, channels and tools the agent can reach, and how those permissions are granted and removed.
• Data and risk owner: legal, compliance, security or the founder wearing that hat. They decide what information the agent may read, what it may never touch, and what must be logged.

The delivery side should send a lead who can speak to design and operations, plus whoever will run the agent after launch. If the people who will operate the agent are absent from the kickoff, important context is lost in the handover.

Avoid inviting observers who have no decision to make. A crowded room produces polite agreement and few commitments. If someone needs to stay informed, send them the written decision list afterwards.

What belongs on the agenda, in what order?

The order matters. Each item produces an output that the next item depends on. If you move to tools before the role is settled, you end up justifying access you do not need.

• Purpose and boundary of the pilot: the sponsor states in a few sentences what problem this addresses and what is out of scope. Output: a one-paragraph purpose statement.
• The role: describe the agent as a role with a mission, tasks, handoffs and things it must not do. Output: a draft role description. The article Write a Job Description for Your First AI Agent Role gives a structure you can bring to the room.
• Users and channels: confirm who uses the agent first and where they will talk to it, such as chat, email or a shared inbox. Output: a named user list and the channels in scope.
• Memory, data and tools: list what the agent needs to know, which sources it may read, and which tools it may use. Mark each as read only or able to act. Output: a table-free inventory in plain list form, with an owner for each item.
• Approval boundaries: decide which actions the agent may take alone, which need a human to approve, and which are forbidden. Output: three short lists.
• Success evidence: agree on what you will observe, who will look at it and how often. Output: a draft success criterion and a review rhythm.
• Working plan: set the next steps, who does them, how feedback flows, and what the first check-in covers. Output: a plan with owners.
• Decisions and risks: read back every decision made, record open questions with owners, and confirm the pause conditions. Output: the written decision list.

A facilitator should hold the time. When a topic opens a deeper discussion, such as a specific integration, park it with an owner and move on. The kickoff is for decisions about direction and boundaries, not for solving every technical detail.

Which decisions should you leave the room with?

If the meeting ends without these, schedule a short follow-up before any build starts. Each decision should be written down, with a name beside it.

• The role: one agent role, described in plain language, with a clear statement of what it will not do.
• The owner: one person accountable for how the agent performs, separate from the people who build or operate it.
• The users: the named first users and the channels they will use.
• The access: which systems, accounts and data sources the agent may reach, with the least access that still lets it do the work. A later permission review will be much simpler if this list exists from day one.
• The approvals: actions the agent may take alone, actions that need a human, and actions that are never allowed.
• The success criterion: something you can observe, not a feeling. How to Define Success Criteria for an AI Agent Pilot explains how to phrase one that survives a hard look.
• The review rhythm: when the group meets again, what evidence it will bring, and who can approve changes.
• The pause conditions: the events that cause the pilot to stop or narrow, such as a data exposure, an action outside the approved list, or repeated errors the owner cannot accept. Deciding this early makes it far easier to stop a pilot without wasting the work when something goes wrong.

It is worth reading these back aloud at the end of the meeting. People often discover that they heard the same sentence differently. Correcting that in the room costs a minute; correcting it after launch costs trust.

What should you prepare before the meeting?

A kickoff works best when the thinking is largely done and the meeting confirms it. Use this checklist in the days before.

• Write a rough description of the work the agent will take on, based on how it is done today, including the exceptions.
• Collect two or three real examples of that work, with sensitive details removed, so the group discusses something concrete.
• List the systems involved and who administers each one.
• Note any rules about data that already exist: contracts, internal policies, regional requirements.
• Draft a first guess at the success criterion, even if the group will change it.
• Identify the candidate users and confirm they have time to take part.
• Decide who will write and circulate the decision list, and by when.

Send the draft role description and the example work to attendees ahead of time. Ask them to mark anything that looks wrong. The corrections that arrive in advance are usually the most valuable, because people think more carefully alone than they do in a group.

For risk and governance, a framework can give the data and risk owner a shared vocabulary. The [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) is a reasonable reference for the questions to ask, and the [OWASP authorization guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) is a practical reference for least-privilege thinking when you decide on access.

What does a good kickoff look like in practice?

This is an illustrative scenario, not a description of a real client.

A regional distribution company wants help with the inbound questions its customer service team receives about order status. The owner arrives at the kickoff expecting to discuss a customer-facing assistant that handles everything. The facilitator asks the group to start with a single role instead: an internal agent that drafts replies to order status questions for the service team to review.

The process owner describes the exceptions: split shipments, held orders and customers who write from a different address than the one on file. The systems owner says the agent can read order records but should not edit them. The data owner asks that customer payment details never enter the agent context. Two service team members, who will be the first users, say they want drafts inside the shared inbox they already use.

The group agrees on three lists. The agent may read order records and draft replies. A person must approve any reply before it is sent. The agent may never change an order, issue a refund or answer questions about contracts. The success evidence is that service staff accept most drafts with little editing, and that wrong drafts are flagged in a simple review each week. They also agree that the pilot pauses if the agent ever shows payment details or sends anything without approval.

The result is narrower than the owner first imagined, and it is also something the team can start using and judge. The wider assistant can be a later decision, taken with evidence in hand.

How does Be Human run the first pilot meeting?

Be Human treats the kickoff as the first step of designing one useful role: the role, the memory and tools it needs, the approval boundaries and an observable success criterion. We bring a draft agenda and a draft role description, facilitate the session remotely in English or Portuguese, and send the written decision list afterwards for confirmation. Because we also operate the agent after launch, the people who will monitor it, review permissions and handle incidents are involved from the start, and the decisions made in the room become the working baseline for evaluations and controlled changes. You can see how the following period typically unfolds in What the First Months With a Managed AI Agent Look Like.

Frequently asked questions

How long should an AI pilot kickoff meeting be? Long enough to cover every agenda item without rushing the decisions, which for a focused pilot is normally one working session. If open items remain, hold a short follow-up rather than extending the meeting until people are tired. Preparation in advance is what keeps the session short.

Do technical staff need to be in the room? Someone who controls systems and access must be there, because many decisions depend on what is possible and safe to connect. That person does not need to be a developer, but they must be able to say which accounts and tools can be reached and how access is removed. Detailed technical design can happen in later working sessions.

What if the sponsor cannot attend? Postpone the meeting if you can, because the sponsor confirms scope and approves boundaries that no one else can. If it must go ahead, name a delegate with authority and have the sponsor confirm the decision list in writing. Decisions without that confirmation tend to be reopened later.

Should we hold the kickoff before or after the contract is signed? Hold it after the scope is agreed in principle and before any build or access is granted. The kickoff often reveals details that belong in the written agreement, so it helps if the contract can still absorb them. The decision list can then be attached to, or referenced from, the final scope document.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.