When leadership decides it needs AI in the operation, the first question is usually which tool to buy or which demo to watch. Those are reasonable questions, but they are out of order. In a large enterprise, what decides whether AI gets to operate is not the tool. It is the sequence of the first decisions, and who makes them.
The short answer: choose a single process with volume, an explainable rule and data in a system; give it an owner in the operation; request access right at the start; measure how the process works today; decide the governance rules before building; and only then choose who builds and on which platform. One agent in production in that process is worth more than ten scattered pilots.
The sections below detail each decision, in the order it needs to be made. Why so many projects stall at the demo is covered in the text on why AI projects die in the PoC. The subject here is what to do before getting there.
1. Choose a process, not a technology
The first process does not need to be the most important one in the company. It needs to be the one that proves, with a number, that AI works in your operation, and that teaches the company how to do the second. One question helps find candidates: where does your operation have a queue? A queue is volume waiting for a decision, and that is usually where an agent pays for itself first.
In the real economy, candidates usually show up in pre-sales service and sales lead qualification, in the queue of requests that today depends on one person, and in back-office routines such as supplier registration and reconciliation. To choose among them, apply five tests:
- It happens a lot. The volume is enough for the gain to show up in the month's indicator, and not only in isolated cases.
- It has a rule someone can explain. Even with exceptions, the person who does it can say how they decide. If nobody can describe the process, the problem is the process, and the agent will not solve it.
- The data is in a system. The information the person uses to decide is in the ERP, the CRM, a database or a document, and not only in the memory of whoever does the work.
- Errors are recoverable. If the agent gets it wrong, someone notices and corrects it before the damage gets expensive. An irreversible, high-value decision is no place for the first agent.
- There is already a number leadership tracks. Or, at the very least, it can be measured before starting.
The processes that pass all five tests still need to be ranked. The criterion that works is to cross the value of the case with the feasibility of putting it into production:
| Value of the case | High feasibility | Low feasibility |
|---|---|---|
| High | Start here. | Second in line. Start solving data access now, so it is ready when its turn comes. |
| Low | Good for the team to learn, weak for convincing leadership. | Discard, for now. |
2. Name who answers for the result
Before talking to any vendor, name the people. An AI project with no owner in the operation becomes a technology project, and a technology project with no owner in the operation becomes a demo. There are four roles, and each one needs a first and last name:
- Executive sponsor. The director who answers for the indicator the project will move and who has the authority to change the process. They do not need to understand AI. They need to want the number.
- Process owner. The area manager who knows the exceptions and knows why the process is the way it is. This is who validates whether the agent is deciding correctly.
- Owner of access and systems. The IT person who can grant credentials, APIs and environments. Without them, the schedule depends on favors.
- Risk and privacy point of contact. Someone from security, legal or compliance who takes part in the rules from the start, and not only in the final approval.
The most common mistake here is one of address. When the project is born in a central technology or digital transformation area and the operation is merely consulted, it tends to end up technically correct and with nobody in the operation who wants it. The sponsor needs to sit where the indicator lives.
3. Solve data and access before building
The most concrete way to map what the agent will need is to shadow the person who runs the process today and note every system, spreadsheet and screen they open. That list is the agent's integration map. For each item on it, three questions: is there an API or a connector? Who grants access? Is there a channel that needs approval, like the official WhatsApp?
Request access on the day the process is chosen. Credentials, network clearance and channel approval follow the company's pace, not the project's, and that is where schedules blow up. A legacy system with no API deserves its own attention, because it tends to become a project within the project. The text on integration with the ERP, CRM and WhatsApp details the possible levels.
Start with reading. An agent that only looks things up and recommends already shows whether it understands the process, and the risk is low. Writing to the systems comes later, one operation at a time, when the accuracy of the reading justifies it.
4. Measure the process as it is today
Without a baseline, no result is demonstrable, and the conversation about continuing or stopping becomes a matter of opinion. Before touching the process, measure how it works. The four numbers of the business case (volume, time per occurrence, success rate and the cost of delay) are the starting point.
With them in hand, write the success criterion in one sentence with four parts: which indicator, starting from which value, to which value, measured by whom. And also write the stop criterion: what, if it happens, ends the project. If the sponsor does not sign those two sentences, the project does not have a goal yet.
- Prefer outcome indicators to activity indicators. Conversations handled is activity. Cases resolved without passing to a person is outcome.
- Use the number from the system, not the estimate. The estimate of whoever lives the process tends to be optimistic or pessimistic, and never exact.
- If the indicator does not exist today, measuring it is the first deliverable. Before any agent.
5. Decide the rules before the first line of code
Governance decided at the start becomes a design requirement. Decided at the end, it becomes a reason for delay, because the questions the risk team asks tend to require a change of architecture, not of configuration. There are five questions, and all of them have an answer before the agent exists:
- What the agent can read, and in which systems.
- What it can do on its own, and what it only recommends for a person to carry out.
- Where a person approves before the action, by type of operation or by value. The text on human-in-the-loop covers the criteria.
- Which data cannot reach the model without treatment, such as personal data and confidential information.
- What gets recorded, to reconstruct any of the agent's decisions later.
Take all five to the risk and privacy point of contact right at the start, and not on the eve of go-live. There is a useful side effect: the area that helped write the rules tends to approve the go-live with less friction, because it already knows what it will find. The text on AI governance and the LGPD (Brazil's data protection law) has the full checklist.
6. Decide who builds, and who stays afterwards
This decision comes last on purpose. With the process, owners, access, baseline and rules defined, you know exactly what to ask of whoever will build, and you can compare proposals by the same criterion. If you already know you will work with a partner, the partner can come in from the first decision; the point is that the partner is chosen for what the process requires, and not the process for what the partner offers.
| Model | When it makes sense | The risk that needs an answer |
|---|---|---|
| In-house team | There is a senior engineer with dedicated time, AI is their priority and the process is documented. | The time to production and the dependence on whoever built it. |
| A partner who delivers and leaves | Fixed scope, a stable process and an internal team able to sustain the agent afterwards. | The handoff: whoever inherits the agent took part in none of the decisions. |
| Hybrid: the partner builds with your team | A first project, a deadline that matters and the intention to have more agents later. | It requires clarity about ownership of what gets built and about how the knowledge moves in-house. |
On the first project, the decisive question is not who writes the code. It is who sustains the agent after go-live, and where the knowledge stays when the project ends. The full calculation between the models is in build on a framework or buy a platform, and the bar for choosing the platform, in how to evaluate an AI agent platform.
The first 90 days
Think of the first 90 days as a planning horizon, not a promised deadline. What matters is the order of the stages and what needs to be ready at the end of each one.
- Choose and measure. The process chosen by the five tests, the four owners named, access requested, the baseline measured and the success criterion signed by the sponsor. Governance rules written together with the risk team.
- Build and integrate. The agent connected to the real system, not to a spreadsheet. Tested with real data, including the exceptions. It starts by reading and recommending; the action stays with the person until accuracy justifies more autonomy.
- Go to production and decide the next step. A go-live monitored closely, with the people who work in the process trained to operate alongside the agent. The indicator is compared with the baseline, and the decision is explicit: expand, adjust or stop. If the decision is to expand, the second process comes from the same list of candidates.
At the end of the period, the question for leadership is not whether AI works. It is how much the indicator moved against the baseline, and which process comes next.
What to avoid at the start
- Starting with the flashiest demo. The case that impresses in the meeting is rarely the one with volume, an owner and accessible data. The demo gets the budget approved and then has nowhere to go.
- Buying the tool before choosing the process. With the license signed, the team starts looking for a problem that justifies the purchase, and the process is chosen for what the tool does well, not for what the operation needs.
- Spreading the effort across ten pilots. One pilot per division pleases everyone and delivers nothing: access, owners and the attention of the people who know how to build are split ten ways, and in the end there are ten demos and no operation. One agent in production teaches more than ten in pilot, because only production shows the real data, the exception and the cost.
- Waiting for the whole company's data to be ready. A project to organize all the data before starting with AI rarely ends. Organize the data for the chosen process; the rest gets organized process by process.
- Confusing access with operation. Rolling out an AI assistant to the whole company can be useful for people who write and research, but it does not change processes. The process stays the same, only with faster drafts.
How Runflow starts
At Runflow, the start follows this same order. The first step is a 45-minute conversation, at no cost, about your operation. For those who move forward, the assessment prioritizes the operation's cases by value and feasibility in about two weeks. In the Discovery phase, the Client Manager and the AI Deployment Strategist map the processes, interview the people involved and deliver a roadmap of agents prioritized by impact and complexity. Then the AI Solution Engineer builds the first agent, integrates it with your systems and puts it into production with your team, in weeks, not months.
The people who work with the agent are trained during go-live, not in a handoff at the end. The platform covers building, operating and measuring each agent, with human approval where the risk demands it, every execution recorded and reproducible, and business metrics built from events the agent itself emits, to compare against the baseline. The full method is on the AI Deployment team page. If the assessment concludes that your case does not call for an agent, we tell you.
