In short: A system of action is the layer of your stack that reads from your systems of record (ERP, eCommerce, CRM), connects the data, decides with your business rules and executes the action inside those same systems. For example, it creates each order's shipping label, matches payments to invoices and notifies the customer, with a trace of every action.
A system of action is software that executes the operational work that lives between your systems: it pulls data from your systems of record, connects it, applies your business rules and writes every action back, with a full audit trail and your approval where it's needed.
I'm Cris Ugarte, CEO and co-founder of Puente OS, the platform that builds the systems that run your business. We work with retail, eCommerce and logistics companies across Latin America, in Chile, Peru and Mexico, and in most of them we see the same gap in the stack.
What is a system of action?
A system of action is the third floor of your stack. Above the system of record, which stores every transaction, and BI, which shows it to you, sits the layer that executes the next step inside those same systems: it reads, connects, decides and acts. Every action is logged and explainable.
Think of your stack as a three-story building.
Ground floor: the system of record
Your ERP, storefront, CRM and marketplaces record every transaction: the sale, the shipment, the invoice, the payment. They are your system of record, the source of truth, and their job is to keep an accurate record of what happened.
Second floor: BI
Your BI takes what the ground floor recorded and turns it into dashboards: how much you sold, what ran late, where the margin went. It shows you what happened.
Third floor: the one that acts
The third floor notices an order missing its shipping label and creates one. It spots a commission that is off and corrects it. It sees a customer asking about their order and replies with the tracking link. In most companies, that floor is your team: people with five tabs open, a master spreadsheet and a WhatsApp group where someone asks, "Hey, did yesterday's order ship?"
That third floor has a name: the system of action. The framework From Systems of Record to Systems of Action defines it as software that reads from systems of record, reasons across the data and takes governed action. At Puente we add the BI floor and apply the idea to commerce and logistics operations.
System of record vs system of action: what is the difference, and where does BI fit?
A system of record, BI and a system of action work together. The system of record stores every transaction and holds the source of truth. BI organizes that data so you can understand the business. The system of action takes signals from both, decides with your rules and executes the next step inside your systems.
Compared across four dimensions:
- The question it answers. System of record: what happened? BI: how are we doing, and why? System of action: what needs to happen now, and who does it?
- What it produces. System of record: transactions and master data. BI: reports and alerts. System of action: executed actions (labels, status updates, commissions, replies) and exceptions with a named owner.
- When it works. System of record: when a transaction is recorded. BI: when someone opens the report. System of action: when data changes, an event arrives or a deadline hits.
- Who takes the next step. System of record and BI: a person. System of action: the system, for work with clear rules, and a person with full context, for work that calls for judgment.
How is a system of action different from RPA, iPaaS or an AI agent?
A system of action orchestrates a complete process, and RPA, iPaaS and AI agents each handle part of it. RPA repeats clicks on a screen, an iPaaS syncs data between systems and an AI agent interprets messages and documents. A system of action combines context from all your systems, your rules, exceptions with an owner and write-back.
- RPA. Mimics a person's clicks. It handles fixed tasks and works as long as the screen stays the same.
- iPaaS or integration. Moves data between systems with mapping rules. Decisions and exceptions stay with your team.
- AI agent. Reads, interprets and drafts. It performs best inside a process with rules and approvals.
- System of action. Runs the process end to end: it reads from every system, applies explicit rules to repeatable work, calls agents where something needs interpretation and writes back to each system.
You will also see it called an AI system of action or an agentic system of action. Bessemer Venture Partners, for example, published a roadmap on AI systems of action. In that framing, the agent is one component, and the process around it (context, rules, approvals and write-back) is what gets the work finished.
What is a governed action?
A governed action is one the system executes within the rules and approvals your company set, and records along with the reason that triggered it. In Puente OS, every change to the system can be rolled back to the previous version, and everything goes into production with your team's approval.
In practice, a governed action meets four conditions:
- Explainable. It records which data triggered it and which rule it applied.
- Logged. Anyone can reconstruct what happened to an order or a payment.
- Within your approvals. Your company sets amounts, thresholds and who signs off: a credit note above a set amount waits in an App until finance approves it.
- Versioned, with rollback. If a rule changes or a step goes wrong, the system rolls back to the previous version, and whatever already ran stays in the log so it can be corrected.
Several of our customers require explicit, auditable rules for their critical logic: a written rule can be reviewed, tested and improved.
Why does the work between systems end up on your team?
Work between systems ends up on your team because each system does its own job well and whatever sits between them (the handoff, the check, the "someone has to move this") lands on a person. Every new tool adds a handoff, and your team ends up acting as human middleware, connecting systems by hand.
According to Asana's Anatomy of Work Index, which surveyed over 10,000 knowledge workers, 60% of people's time at work goes to "work about work": communicating about work, searching for information, switching between apps and chasing the status of tasks. A study published in Harvard Business Review followed 137 people at three Fortune 500 companies: they toggled between apps and websites roughly 1,200 times a day, and reorienting took them just under four hours a week, about 9% of their time at work.
We call that cost the coordination tax: the meetings, approvals and manual handoffs that grow with every sale.
I saw it up close before Puente. My co-founder Octavio and I worked together at Walmart Chile, and we were the third floor. We figured: if the world's largest retailer runs this way, everyone does. That floor can be built.
What does a system of action look like in a real operation?
In a real operation, a system of action looks like processes that run end to end and bring your team only the cases that call for judgment. Here are three system of action examples from retail, eCommerce and logistics: the order that ships with its label, payment reconciliation, and the part of the operation that lives in spreadsheets.
Example 1: from order to customer
At 11:40 p.m. on a Friday, an order lands in the storefront:
- The workflow reads the order as soon as it is created.
- It confirms stock in the ERP and picks the warehouse based on the customer's delivery zone.
- It picks the courier by weight, cost and committed service level.
- It creates the label in the courier portal.
- It updates the status in the ERP and in the sales channel.
- It notifies the customer with the tracking number.
When a field is missing, like an incomplete address, the exception reaches the right person with the order and a suggested action, ready to resolve in one click.
A version of this flow is already running in production. At one of our customers, a multichannel electronics seller in Mexico that ran on spreadsheets, the system validates the address, picks the carrier by zone, cost and insurance, and creates the label: 97.9% of orders get their shipping label with no human intervention.
Example 2: reconciliation and payments
A payment hits the bank with an incomplete reference, and someone matches it by hand against the invoice in the ERP.
With a system of action, the workflow reads the bank transactions, finds the invoice that matches on amount, date and customer ID, applies the tolerance finance defined and records the reconciliation. Anything outside the rules reaches finance with candidate invoices already suggested.
Example 3: where the operation lives in spreadsheets
In many operations, returns live in a spreadsheet and a WhatsApp group. With a system of action:
- The customer requests a return on WhatsApp and attaches a photo.
- An agent reads the message and the photo, and identifies the order and the reason.
- The workflow checks the purchase date against your return policy.
- It creates the record in Puente's Databases, generates the pickup label and alerts the warehouse.
- When the product arrives, it prepares the credit note for finance to approve.
Puente acts on your systems, and where operations live in spreadsheets, it also keeps the record. That is the case for the electronics seller in the first example, which runs without an ERP: its 38,628 orders processed end to end between November 2025 and August 2026 live in Puente's Databases.
What is a system of action built with?
A system of action is built from integrations with your systems, a data layer that connects information across them, rules that decide, something that interprets ambiguous input and an interface where your team approves. In Puente OS, that takes the shape of four building blocks: Apps, Agents, Workflows and Databases.
- Databases, together with integrations, for context that spans systems: orders, stock, labels and payments in one place.
- Workflows with explicit, auditable rules for repeatable work. They trigger when data changes or on a schedule, and they act inside your systems.
- Agents for work that needs interpretation: a customer message, a scanned document, an ambiguous exception.
- Apps where your team sees, decides and approves what calls for their judgment.
In Puente OS, an AI system of action means AI is what builds it: you describe what your operation needs in plain language and get working software. The write-back is concrete: at a Chilean multichannel pet retailer, Puente has executed 8,362 price changes in Shopify.
How do you implement a system of action, step by step?
You implement a system of action one process at a time: pick the one that hurts most, map how it works today, write its rules and put it into production connected to your systems. With Puente OS, each process reaches production in 2 to 4 weeks, and each new one builds on what is already running.
- Pick a process that hurts. High volume, manual handoffs and a visible cost when it fails. The messier, the better.
- Take a baseline. From the last few weeks of data: cases coming in, time per case and team hours spent.
- Map the trigger, the decisions and the exceptions. What event starts it, what a person decides today, which cases fall outside the rules and where each piece of data lives.
- Write the rules explicitly. For example: "if the package exceeds a set weight and the address is outside the coverage zone, it goes with the second courier."
- Decide where each exception goes. Either the system resolves it or it reaches a named owner with full context.
- Set up write-back and permissions. What the system executes on its own and what needs approval.
- Put the process into production and compare it against the baseline from week one.
Steps 3 and 5 are the core of autonomous operations design: repeatable work runs on your rules, and your team decides what calls for judgment.
How do you measure whether a system of action works?
You measure a system of action process by process, with operational metrics: the share of cases the system completes end to end, how long the full cycle takes, how many exceptions show up by type and how fast they get resolved, and how much volume the same team handles month over month.
- End-to-end resolution rate. Cases the system completes with no intervention, divided by total cases in the period. This is the primary metric.
- Cycle time. Order to label, payment to reconciliation.
- Exceptions by type and time to resolve. An exception that keeps repeating is a rule waiting to be written.
- Volume per person. How many orders, labels or payments the same team handles.
- Coordination hours. Follow-up meetings and "where are we on this?" messages.
Compare each metric against the baseline from step 2. At the electronics seller in Mexico, monthly volume grew 40% with the same operations team (from 3,742 to 5,247 orders a month), and label generation went from 5 to 7 hours per batch to 15 minutes.
Picture a different Monday: the weekend's operations are already closed out, and your team touches one order in a hundred. That picture is our design goal, and we move toward it one process at a time. The closest measured data point is that customer's label generation: 97.9% of orders get their shipping label with no human intervention.
What changes for your operations team with a system of action?
With a system of action, your operations team keeps the work that calls for judgment: resolving exceptions, negotiating with suppliers, taking care of customers and improving the process. The system absorbs the repeatable volume, so operations can scale 2 to 5 times without multiplying headcount, and every new process builds on rules already captured.
For the first process, we look for one that pays for itself in under 90 days, so the next step is decided with your own data.
Your ERP records what happened. Your BI shows you what happened. Puente makes it happen.
Key takeaways
- A system of action reads from your systems of record, connects the data, decides with your rules and acts.
- It orchestrates the complete process; RPA, iPaaS and AI agents each handle part of it.
- Every action is governed: explainable, logged and within your approvals, and every change to the system can be rolled back.
- In Puente OS it is built with Apps, Agents, Workflows and Databases, and repeatable work runs on explicit rules.
- It is implemented one process at a time, in 2 to 4 weeks each, and measured by cases resolved end to end.
Want to see what the third floor would look like in your operation? We start with a one-month pilot: by the end of that month your first process is live in production, and if you continue, the pilot fee is credited in full toward implementation. Book a demo with our team.
