In short: Autonomous operations are business processes designed so repeatable work runs on its own, under your rules, while your team decides what calls for judgment. An autonomous operation meets three conditions: work starts when data changes, systems talk to each other directly, and the system handles the clear cases and routes every exception to a named person.
Autonomous operations design is the discipline of designing a company's operations so that logic, decisions and execution run in systems, and people keep the judgment calls. It is how we work at Puente OS, the platform that builds the systems that run your business, with retail, eCommerce and logistics companies across Latin America, in Chile, Peru and Mexico.
Picture a different Monday. You walk in and the weekend's operations are already closed out: orders shipped with their labels, payments reconciled, and every customer has their tracking link. Three exceptions wait in your inbox, each with the context to decide.
That Monday is a design goal. The closest measured data point we have today: at one of our customers, 97.9% of orders ship with their label without human intervention.
What are autonomous operations?
Autonomous operations are business processes that start on their own, pull what they need from every system involved and run the clear cases on explicit rules, while exceptions reach a named person with full context. Autonomous operations design is the discipline that gets you there, one process at a time, on the systems you already run.
It applies to orders, shipments, payments, reconciliation, inventory and pricing. A well-designed process puts five things in writing: its trigger, the information it crosses, the rules for the clear cases, the owner of each exception and a record of what was done.
Autonomous operations in commerce, IT and industry
The term shows up in three fields. In IT, it describes infrastructure that monitors and fixes itself, often through AIOps tools. In manufacturing and energy, it means plants that run with minimal operator input. In retail, eCommerce and logistics, the field this article covers, it means orders, payments and shipments that move on their own while people handle the exceptions.
Where the term comes from
In Spanish we call the discipline Diseño Autónomo. The term and its three conditions come from Arco Venture Studio, which proposed autonomous design in April 2026 as a way to build new businesses from the ground up, around three principles: state-driven execution, agentic interoperability and a separation between the execution layer and the judgment layer. At Puente OS we apply it to operations that already exist.
Why do growing operations need to be designed to run themselves?
Growing operations need to be designed to run themselves because, in most companies, volume rests on people who connect systems by hand. Every new channel, courier or marketplace adds handoffs, checks and messages. The team becomes the glue holding the stack together, and every jump in volume demands more hours of coordination.
Look at an online store on an ordinary Tuesday. An order comes in through a marketplace and someone copies it into the ERP. Someone else creates the shipping label in the courier's portal. In the team chat, someone asks: "Did yesterday's payment come in?" And the master spreadsheet exists in three versions.
I'm Cris Ugarte, CEO and co-founder of Puente OS. My business partner, Octavio Flores, and I saw this scene up close when we worked together at Walmart Chile.
We call this operational fragmentation: operations spread across systems that don't talk to each other, with people acting as human middleware. What it costs your people is the coordination tax: the meetings, approvals and manual handoffs an operation needs to keep running.
Hiring absorbs volume for a while, and every new hire brings their own coordination load. Automating one task at a time relieves one step at a time. Autonomous operations design hands all the repeatable volume to the system.
Signs your operation needs it
- Someone checks an inbox or a spreadsheet several times a day to see if there's new work.
- Status questions like "Did it ship?" or "Did the payment land?" live in the team chat.
- The rules live in one person's head, and the process stalls when they go on vacation.
- Every new channel or courier means adding someone to the team.
What are the three conditions of an autonomous operation?
An operation runs on its own when it meets three conditions. First, work starts when data changes. Second, systems talk to each other directly and share what each step needs. Third, the system handles the clear cases with explicit rules and brings a person the cases that need a decision. Each condition becomes a design question.
These are Arco Venture Studio's three principles, turned into design questions.
1. Work starts when data changes (the process trigger)
In many operations, work starts when someone remembers and opens the spreadsheet. In an autonomous operation, work starts on an event or a schedule: an order is marked paid, the courier marks a package delivered, or it's time to close out the day.
The design question is: what triggers this process? If the answer is "someone looking," there is work to design. In Puente OS, event-driven and scheduled workflows meet this condition.
2. Your systems talk to each other directly
The ERP, the storefront and the courier each hold part of the picture. When they're disconnected, a person becomes the bridge and copies data from one to the other. In an autonomous operation, systems share what each step needs, and every action is written back where it belongs.
The design question is: what information does this process cross, and where does it live?
At a Chilean multichannel pet retailer, on-time delivery is measured shipment by shipment with data pulled straight from the courier's API: from mid-January to mid-August 2026, it stood at 85.0%. In Puente OS, integrations and databases meet this condition, and also keep the record where operations live in spreadsheets, while workflows write back into each system.
3. Exception management: the system handles the clear cases and brings you the ones that need judgment
The clear part of a process runs in the system, on explicit rules. The part that needs a person reaches the right one with three things in view: what happened, which rule stopped the case and what the options are.
The design question is: what are the exceptions, and what happens to each one? In Puente OS, this condition is met by workflows with auditable rules, agents that interpret an email or a complaint, and apps where the team decides and approves.
How is autonomous operations design different from RPA, AI agents and BI?
Task automation and RPA handle a single step. An AI agent interprets language and ambiguous cases. BI shows what happened. Autonomous operations design works on the whole process: it defines the trigger, the information it crosses, the rules it applies and what happens to each exception, and then picks the right building block for each step.
- Task automation and RPA (macros, RPA bots, point-to-point integrations): run one specific step, like copying data between screens. Someone still pushes the process forward.
- AI agents: read a message, a document or an ambiguous exception and propose or execute a response.
- Dashboards and BI: show what happened. The action stays with the team.
- Autonomous enterprise: the concept SAP unveiled in May 2026, where humans and AI work together and an autonomous suite runs core business operations. It names the destination.
- Autonomous operations design: the method for getting there, one process at a time, on the systems you already run.
Gartner frames it in similar terms: it recommends AI agents when decisions are needed, automation for routine workflows and assistants for simple retrieval. It also predicts that over 40% of agentic AI projects will be canceled by the end of 2027, due to escalating costs, unclear business value or inadequate risk controls. Most of what runs a company is predictable, and a workflow plus a business rule handles it.
What do autonomous operations look like in practice?
In practice, an autonomous operation is a process that moves on its own from one state to the next: data comes in, the system matches it with what it needs, applies the rules, acts and logs the result. People step in on the cases the design flagged as exceptions, with context to resolve them. Two live processes show how.
Example 1: autonomous order fulfillment at a Mexican multichannel seller
A Mexican multichannel electronics seller runs without an ERP. Every order used to be downloaded by hand and every label created one at a time, across two shipping cutoffs a day that took 5 to 7 hours each. Today the process runs like this:
- Trigger: an order comes in through one of its sales channels.
- Information: the workflow validates the address against Mexico's official postal code catalog.
- Rules: it picks the carrier by zone, cost and insurance.
- Action: it creates the label and writes the tracking number into the order, where customer service can find it. The "delivered" status updates on its own and closes the payment cycle.
- Exceptions: whatever the rules can't resolve goes to the team, and every incident is logged with its resolution time.
Creating the labels for a cutoff now takes 15 minutes, 97.9% of orders ship with their label without human intervention, and monthly order volume grew 40% with the same operations team.
Example 2: daily margin at a Chilean pet retailer
At the same pet retailer, margin used to be built by hand in a spreadsheet and reported once a week. Today the process runs like this:
- Trigger: every day at 8:00 a.m., the system calculates the previous day's margin.
- Information: the workflow pulls sales from the sales management system through its API, strips out returns and gift items, and matches each receipt against the online store to see which discount code was applied.
- Rules: it computes gross margin per product using the latest purchase cost, the same cost the supplier settles against.
- Exceptions: every line item with a negative margin is flagged with its channel and discount code.
- Action: prices are corrected from an editor that writes straight to the online store, with history and rollback.
The measured result: 247,626 line items with margin calculated daily across four channels, 3,830 negative-margin lines (1.5%) that had been invisible, and 8,362 price changes pushed to the online store from Puente.
How do you design autonomous operations, step by step?
You design autonomous operations one process at a time, in eight steps that run from mapping to measurement. The core steps answer the three design questions: what triggers the process, what information it crosses and who owns each exception. A well-scoped process goes live in 2 to 4 weeks.
- Pick a process that hurts. One with volume, repetition and team hours on top of it, and a return you can see in under 90 days.
- Map it as it runs today. Sit with the person who runs it: the real map lives in their head, their master spreadsheet and the team chat.
- Define the trigger. A paid order, a file arriving, a status change, a deadline.
- Map the information it crosses. What data each step needs and which system holds it.
- Write the rules for the clear cases. How your most experienced person decides today, as explicit, auditable rules.
- Give every exception an owner. The system resolves it or it reaches a named person.
- Build it and go live. With Puente OS you describe in plain language what the process needs and get running software: apps, workflows, databases and agents, which go to production with your team's approval.
- Measure and add the next one. Every recurring exception is a rule waiting to be written, and what you already built speeds up the next process.
How do you write an explicit rule?
An explicit rule has a condition, an action and an owner for the cases that fall outside it, and anyone on the team can read it. Three illustrative examples:
- Shipping: if the order is paid, in stock and has a complete address, assign the cheapest courier that meets the promised date. If data is missing, it goes to whoever runs shipping.
- Reconciliation: if the deposit matches an invoice within the tolerance finance set, it reconciles automatically. If it differs, it goes to review with the candidate invoices.
- Pricing: if a line item's margin drops below zero, it's flagged for the commercial team.
How do you measure whether an operation is autonomous?
You measure an autonomous operation process by process, with the human intervention rate: the share of cases that needed a person to do something. Round it out with the time from trigger to action, exceptions per hundred cases, their resolution time and the volume each team member handles.
- Intervention rate: cases a person touched, over total cases. It's the core metric, and the complement of the end-to-end resolution rate of a system of action.
- Time from trigger to action: minutes between the event and the action.
- Exceptions per hundred cases: how many, and of what type.
- Support incidents and resolution time: at the Mexican seller, from August 1 to 12, 2026, there were 12 support incidents across 2,051 orders (0.59%), with a median resolution time of 10 minutes.
- Volume per person: orders, payments or tickets per team member per month.
Arco Venture Studio sets one human intervention per hundred executions as its threshold. We use it as a design goal: the team touches one in every hundred orders. The intervention data point we have measured today is the label rate at the Mexican seller, and a full weekend of operations running on its own is the picture we design toward. Before you build, measure for a week: the method is in how to measure the coordination tax.
What happens to your team when operations run themselves?
When operations run themselves, your team keeps the judgment calls. The time that went into moving data between systems goes to deciding, negotiating, taking care of customers and improving the business. Operations can grow 2 to 5 times without multiplying headcount, because the system absorbs the repeatable volume.
This is human-in-the-loop design: the system runs the rules and people own the decisions. In research across 1,500 companies published in Harvard Business Review, H. James Wilson and Paul R. Daugherty found that the biggest performance gains come when humans and machines work together, and that companies automating mainly to cut their workforce see only short-term productivity gains. Their practical advice matches ours: to get the most out of AI, companies need to redesign their business processes.
Three roles that emerge
- Exception owner: resolves each type of case with the context in view.
- Rule owner: the person who knows the process best. Turns recurring exceptions into new rules.
- Change approver: IT or the department head. Approves every change before it reaches production.
How does Puente OS apply autonomous operations design to an existing business?
Puente OS applies autonomous operations design to the operation that already runs, on the systems the company already has. We deliver it through Growth Ops in three phases: Diagnosis maps and prioritizes the processes, the Sprint puts one live in production in 2 to 4 weeks, and the Partnership keeps adding processes over time.
Puente OS is the system of action for your operations: it reads from your systems, decides and writes every action back, logged and reversible.
We use AI to build the software itself, and it shows in how few people it takes. At the Mexican seller, a single person built 20 apps and 75 processes in ten months. At the Chilean pet retailer, the time from requesting a use case to seeing it in production went from 105 days for the first one to 7 days for one in July 2026.
Key takeaways
- Autonomous operations design sets up your operation so repeatable work runs on its own, with your rules, and your team makes the calls that need a person.
- Three conditions: work starts when data changes, systems talk directly, and every exception reaches a named person.
- Four building blocks: workflows for repeatable work, agents for interpretation, apps for decisions and databases for context.
- It's applied one process at a time, and each one goes live in 2 to 4 weeks.
- It's measured with the human intervention rate per process; one in a hundred is the design goal.
- Your team stays in charge of the decisions, and operations can grow 2 to 5 times without multiplying headcount.
Which process would you start with? We begin with a one-month pilot: that month covers the Diagnosis and the first Sprint, and your first process goes live in production. If you continue, what you invested in the pilot is credited toward implementation. Book a demo with Puente OS.
