Most ops teams know what they want to automate. They have a mental list: the invoice matching that takes three hours every Monday, the vendor onboarding checklist that takes a week because four people have to touch it, the IT ticket triage that means the same person routing the same category of request sixty times a month.
Knowing what to automate and knowing how to get from that list to a running agent in production are two different things. This playbook covers the second part: the specific decisions and steps that the ops teams who have successfully deployed agents with us have worked through, in the order they worked through them.
Step 1: Choose the Right Starting Workflow
The first workflow you automate matters more than any other. Not because it will be your most important automation, but because it will define your team's experience of what automation feels like to build, deploy, and maintain. A bad first workflow choice makes the second workflow harder. A good first workflow choice generates confidence and institutional knowledge that carries forward.
The criteria for a good first workflow are: well-defined boundaries (you can list every step from trigger to completion), high repetition (it runs the same way dozens or hundreds of times per month), and low ambiguity in the normal case (80-90% of instances follow the same path with the same data structure).
Invoice processing typically meets all three criteria, which is why it is the most common first workflow we see. IT ticket routing also works well. Expense reconciliation is a strong candidate for teams that process a high volume of employee expense reports. The criteria matter more than the specific workflow: choose something your team does repetitively, not something novel or high-stakes that you rarely touch.
What to avoid for a first workflow: anything where the input format varies significantly between instances (like parsing unstructured legal contracts), anything where the trigger condition is ambiguous (like "respond to customer questions"), or anything where an error has irreversible consequences (like account deletion or large external payments). Save those for after you have built confidence on a straightforward workflow.
Step 2: Map the Steps in Detail
Before you open the workflow builder, document the workflow as a sequence of steps on paper or in a document. This sounds tedious but it is the most valuable hour you will spend on the project. You are not drawing a process diagram for a presentation; you are answering specific technical questions.
For each step, answer: What is the input? Where does it come from (which system, which field, in what format)? What action is taken (API call, data transformation, send message, post to ledger)? What are the success and failure conditions? What happens when the input is missing or malformed?
Two things usually become clear during this mapping exercise. First, you will find steps you had not remembered as steps: the human processor does something casually that the agent will need to do explicitly. Checking that a vendor is not already in the system before creating a new record. Sending a Slack message when an approval is needed. These are not complicated, but if you do not name them as steps they will not be in the workflow. Second, you will find the edge cases: the invoices that come in a different format, the vendors whose names have changed, the approval rules that have exceptions. These are the cases where you will configure approval gates.
Step 3: Connect Your Tools and Configure Credentials
With the step map in hand, identify every tool the workflow touches. For each one, you need a working credential with the appropriate permission scope. For the agent to read from an inbox, it needs read access to the inbox (IMAP credentials or OAuth scope). For it to post to the ERP, it needs a service account with write permissions on the relevant module. For it to create a Jira ticket, it needs an API token with project-level create permissions.
Start provisioning these credentials before you start building the workflow. In most organizations, getting a new service account or API token approved takes longer than the technical integration work. Starting this in parallel with the step mapping prevents it from being a blocker at the end.
Test each credential in isolation before using it in a workflow. Most APIs have a simple GET endpoint that returns information about the authenticated account. Confirm each connection works and returns data you expect before relying on it in an agent run.
Step 4: Build the Workflow and Set Guardrails
In the MicroAGI workflow builder, create a new workflow and connect the steps you mapped. For each step that involves a write to a production system, configure an approval gate condition. At this stage, set the threshold conservatively: flag everything that is outside the clearest definition of "obviously correct." You can relax the thresholds after you see how the workflow performs in review mode.
Keep the first version simple. Do not add complex branching conditions or edge case handling in the first version. The goal of the first production version is to handle the common case correctly and to route everything else to a human via a flag. You will add edge case handling in subsequent versions once you have seen what the real distribution of inputs looks like.
Name each step clearly in the workflow definition. The step names appear in the run trace that your ops manager and any auditor will review. "Step 3" tells a reviewer nothing. "Match invoice to purchase order (SAP)" tells them exactly what happened and which system was involved.
Step 5: Run in Review Mode First
Before going live with automated writes, run the workflow in review mode. In review mode, every step is flagged regardless of whether it meets the approval threshold. A human reviews each step before the agent proceeds. This is not the final operating mode; it is a learning mode.
Run in review mode for two weeks. During that period, the reviewer is asking: "Is what the agent is doing what I would have done?" For each step in each run, they check the agent's decision against their own judgment. Where the agent is wrong, they reject the step, and the case is handled manually. They also note the reason: was it a data quality issue? An edge case the workflow logic did not handle? A threshold that was set wrong?
After two weeks, look at the review log. Categorize the flags: what percentage were "the agent was right and this should have auto-approved," what percentage were genuine edge cases that needed judgment, and what percentage were errors? Adjust the workflow logic for the error cases, tune the approval thresholds for the edge cases, and graduate the clearly-correct cases to fully automated.
Step 6: Go Live With Calibrated Thresholds
After the review mode period, you should have a realistic picture of the workflow's edge case distribution. Set the approval gates to reflect that reality: automated for the cases that ran correctly in review mode, flagged for the cases where judgment was needed or where errors occurred.
At this point, go live: switch the workflow from review mode to production mode. The agent processes the common case autonomously, flags edge cases to the appropriate reviewer, and produces a full run trace for every execution. The ops manager has a visible record of every action the agent took, and the approval queue gives them control over the cases that require judgment.
Plan to spend the first two weeks of production mode monitoring the flag rate. If the flag rate is above 5-10%, the thresholds are set too conservatively or the edge case handling needs improvement. If the flag rate is under 1% but you are seeing errors on approved cases, the thresholds are too loose. The target flag rate depends on the workflow, but for invoice processing, a well-tuned workflow typically settles in the 2-5% range.
Step 7: Expand From the First Workflow
Once the first workflow is running stably in production, you have the foundation for expanding your automation. The credentials you provisioned are already connected. The ops manager is familiar with reading run traces and managing the approval queue. The team has a mental model of what automation in your environment looks like.
The second workflow will be faster to deploy than the first, because most of the organizational and credential setup work is already done. The third will be faster than the second. This compounding is where the real value of building automation infrastructure shows up: not in the first workflow, but in the cumulative efficiency of the second, third, and fourth.
