How to Pilot AI Workflows Without a Big Budget

A good pilot answers one question: does automating this specific process produce a measurable improvement in speed, quality, or cost? Everything else is secondary. A pilot that tries to answer too many questions at once, or that runs across too many processes simultaneously, produces ambiguous results that are hard to act on.

The ideal pilot has four properties:

• Single process. Pick one process and automate it completely before touching a second. A single well-executed workflow produces cleaner evidence than three half-built ones.
• Measurable baseline. Before you build anything, document how the process runs today: how often it runs, how long it takes, how many people touch it, and what the error rate looks like. Without a baseline, you cannot show improvement.
• Real volume. Run the automated workflow on real work, not synthetic test cases. The pilot period should cover enough instances to produce statistically meaningful results. For a process that runs daily, a 30-day trial gives you a month of real data. For a process that runs weekly, it gives you four cycles.
• Clear success criteria. Define before you start what a successful pilot looks like. Faster turnaround? Fewer errors? Less time spent on coordination? Name the metric and the threshold. A pilot without success criteria is an experiment without a hypothesis.

The 30-day free trial on DAVE covers up to five seats, which is enough for a meaningful pilot on most single-process workflows. A typical pilot team needs one person to build the workflow (the Curate role), one to build and configure the agents (the Create role), one to run instances and complete tasks (the Use role), and one to monitor results (the Reporting role). One person can hold multiple roles, so a two-person team can cover all four functions.

The process you choose for your pilot determines whether the pilot succeeds. A poorly chosen process produces weak results even with a well-built workflow. A well-chosen process produces strong results even with an imperfect build.

The best pilot processes share three characteristics:

High repetition, low variation. A process that runs the same way every time is easier to automate and easier to measure. Support ticket triage, contract review for a specific contract type, weekly reporting, and content drafting for a defined format are all good candidates. A process with high variation in inputs or outputs is harder to automate reliably and harder to evaluate fairly.

Clear human decision points. The best AI workflow processes are not fully autonomous: they have specific points where human judgment is required and specific points where it is not. A process where a human currently reviews every output before it goes anywhere is a good candidate, because the Human Review node in the workflow preserves that oversight while the Agent Interaction node handles the drafting. The human's job changes from doing the work to reviewing the AI's work, which is faster.

Measurable output. The process should produce something you can count: tickets resolved, contracts reviewed, reports delivered, responses sent. If you cannot count the output, you cannot measure the improvement.

Processes to avoid for a first pilot: anything that requires integrating with a large number of external systems before it can run, anything where the definition of a correct output is highly subjective, and anything where a single error has catastrophic consequences. Save those for later, once you have built confidence in the platform and the team's ability to design and test workflows.

Once you have chosen the process, document the current state in writing before you open the Workflow Editor. How many times does it run per week? How long does each run take? Who is involved? What does a successful output look like? This documentation is both the baseline for your measurement and the specification for your workflow build.

Getting a DAVE workspace ready for a pilot takes less time than most teams expect. The setup sequence follows a clear path: providers first, then agents, then the workflow.

Step 1: Configure a provider. Go to Admin, then API Management, then Providers and configure at least one AI provider. You need the provider type, the base URI, and your API key. DAVE connects to your own API keys across seven provider types: OpenAI, Anthropic, Azure OpenAI, Google, OpenAI-compatible, local Ollama models, and custom providers. For a pilot, one provider is enough. Choose the one your team already has access to. If your organisation has an existing OpenAI or Anthropic account, use that: the API cost for a pilot volume is typically small, and you pay your provider directly at their published rates. DAVE does not mark up or proxy your AI usage.

Step 2: Create an agent. Go to Agents in the sidebar and click Create Agent. Give it a descriptive name that reflects its function (for example, "Contract Clause Extractor" or "Support Ticket Classifier"). Add a version with the configuration: system prompt, model, and temperature. The system prompt is the most important part: it defines what the agent does with the input it receives. Write it to match the specific task in your pilot process, not a generic instruction.

Step 3: Build the workflow. Go to Workflows and click Create Workflow. Open the Workflow Editor and build the graph: drag nodes from the left palette onto the canvas, configure each node in the right properties panel, and connect them with edges. For a first pilot workflow, keep the graph simple. A Start node, a User Interaction node to collect the input, an Agent Interaction node to process it, a Human Review node to approve the output, and an End node is a complete, functional workflow. Add complexity only after the simple version is running reliably.

Step 4: Assign roles to your pilot team. Go to Admin, then Settings, then Users and Roles and create accounts for your pilot team members. Assign each person the role or roles they need. The Curate role is required to build and edit workflows. The Create role is required to build and edit agents. The Use role is required to launch instances and complete tasks. The Reporting role is required to view the Reports page. A single person can hold multiple roles: on a small pilot team, the workflow builder often holds both Curate and Create.

Step 5: Run the quick start walkthrough. Before running real work through the workflow, run the end-to-end cycle once with a test input. Launch an instance, complete the User Interaction task, let the agent run, complete the Human Review task, and confirm the instance reaches the completed status on the Instances page. This confirms the workflow is wired correctly before real work depends on it.

Once the workflow is built and tested, the pilot is straightforward: run real work through it for the duration of the trial period and measure what happens. The discipline is in the measurement, not the running.

Track the baseline alongside the pilot. For the first week or two of the pilot, run the automated workflow in parallel with the manual process rather than replacing it entirely. This gives you a direct comparison: the same inputs processed both ways, with the outputs compared side by side. It also gives your team confidence in the AI output before they rely on it exclusively. Once the parallel run produces consistently good results, switch to the automated workflow as the primary path.

Use the Dashboard for daily monitoring. The Dashboard is the default landing page after login and shows four summary cards: Agents, Workflows, Running Instances, and Pending Tasks. Check it at the start of each day during the pilot. A high Pending Tasks count means tasks are accumulating faster than reviewers are completing them, which is a signal to either add reviewer capacity or redesign the workflow to reduce the volume reaching Human Review. A high Running Instances count with few Pending Tasks means the workflow is processing smoothly.

Use the Reports page for weekly measurement. The Reports page (accessible to users with the Admin or Reporting role, via Reports in the sidebar) shows summary cards for Total Runs, Avg Latency, Failure Rate, and Pending Tasks. At the end of each week of the pilot, record these four numbers. Compare them to your baseline. Avg Latency is the most direct measure of speed improvement: if the automated workflow completes in less time than the manual process took, that is your headline result. Failure Rate tells you how reliably the workflow is completing: a high Failure Rate early in the pilot usually indicates a configuration issue in the workflow or the agent, not a fundamental problem with the approach.

Record qualitative observations too. Ask the people completing the Human Review tasks what they are noticing. Are the AI drafts consistently good? Are there categories of input where the output is weaker? Are there review decisions that are always straightforward and could be automated further? These observations are as valuable as the quantitative metrics for deciding what to build next.

A pilot that produces good results but is not presented well does not generate investment. The presentation is part of the work.

Structure the pilot results around the success criteria you defined at the start. If you said the pilot would succeed if average turnaround time fell by a certain amount, show the before and after numbers. If you said it would succeed if the error rate fell, show the Failure Rate card data from the Reports page alongside the pre-pilot error rate from your baseline. The comparison should be direct and specific: not "the workflow is faster" but "average completion time fell from X to Y over the four-week pilot period".

Include the cost. The platform cost during the trial was zero. The AI usage cost was whatever your provider charged for the API calls made during the pilot: pull this from your provider's billing dashboard and include it. The residual human time cost is the time your reviewers spent completing Human Review tasks: estimate this from the number of review tasks completed (visible in the Reports page) multiplied by the average time per review. Add these up and compare to the cost of the manual process over the same period. The difference is the pilot's demonstrated return.

Show the workflow diagram. A screenshot of the workflow graph from the Workflow Editor makes the human review steps visible to stakeholders who were not involved in the build. Budget holders who are skeptical of AI automation are often reassured when they can see that humans remain in the decision loop at specific, named points. The graph is evidence that the process has structure and governance, not just an AI running unsupervised.

Name the next step. A pilot presentation that ends with "it worked" is less effective than one that ends with "it worked, and here is what we want to build next and what it will cost". Come with a specific proposal: which process to automate next, how many seats the expanded deployment needs, and what the projected return is based on the pilot's demonstrated numbers. The pilot has given you the credibility to make that proposal with evidence behind it.

Not every pilot produces the results you projected. When a pilot underperforms, the question is whether the problem is in the process choice, the workflow design, the agent configuration, or the measurement. Each has a different fix.

If the Failure Rate is high: The workflow is not completing successfully at an acceptable rate. Check the Instances page for failed instances and look at the instance context to identify where in the graph the failure is occurring. A failure at an Agent Interaction node usually indicates a configuration issue with the agent or the provider. A failure at a Human Review node usually indicates a timeout: the task was not completed within the configured window. Both are fixable without changing the fundamental workflow design.

If the Avg Latency is not improving: The workflow is completing, but not faster than the manual process. The most common cause is that the Human Review step is the bottleneck: reviewers are taking as long to review the AI draft as they would have taken to do the work manually. This is a signal that either the AI draft quality is not high enough (the reviewer is spending time correcting rather than approving) or the reviewer is not yet trusting the output enough to approve quickly. Improve the agent's system prompt, run a calibration session with the reviewer, and measure again.

If the output quality is inconsistent: The agent is producing good output for some inputs and poor output for others. Review the Task payloads for the Human Review tasks where the reviewer requested changes or rejected the output. Look for patterns in the inputs that produced poor output. Refine the agent's system prompt to handle those cases, or add a routing step that sends edge-case inputs to a different path.

If the process was the wrong choice: Some processes are harder to automate than they appear. If the pilot has revealed that the chosen process has too much variation, too many external dependencies, or too subjective a definition of a correct output, that is useful information. Document what you learned, choose a better-scoped process, and run a second pilot. A failed pilot that produces a clear lesson about process selection is more valuable than a successful pilot that produces no insight.

The 30-day trial gives you enough time to iterate. If the first build underperforms in week one, you have three weeks to refine it. Use the Workflow Editor to adjust the graph, update the agent configuration, and re-run. Each iteration is a new version of the workflow: saves are immutable snapshots, so you can always return to a previous version if a change makes things worse.