Operations Aren't Diagrams. They're Living Systems

For years, I watched smart people try to draw their operations.

Boxes connected by arrows. Swim lanes. Decision trees. Whiteboards covered in sticky notes that nobody wanted to throw away. Slide decks titled "Q3 Process v17" sitting in shared folders, slowly going stale.

Every operations leader we've worked with has done some version of this. The drawing is always a heroic effort. And six months later, it's obsolete and inevitably wrong.

I used to think this was a process problem.

Companies had processes. The processes lived in systems. The systems ran the processes. So if we mapped more carefully, automated more aggressively, integrated more thoroughly, the operation would eventually become legible and reliable.

Then the pattern became impossible to ignore.

‍

“The processes inside the systems were running fine. The pain was somewhere else. “

‍

The pain was in all the work that didn't fit a process. The exceptions. The judgment calls. The coordination between people that no system could see. The decisions that depended on context the systems didn't have. The questions that had to be answered before the next step could even happen.

That work consumes the majority of operational bandwidth. And it's invisible to every workflow tool ever built.

The wrong question

Workflow automation tools have been around for thirty years. RPA, Zapier, Make, n8n, the long tail of internal BPM platforms inside enterprise software. They all share an assumption: that operations are made of steps, and that if you can connect the steps with logic, you've automated the operation.

This assumption isn't entirely wrong. Some operations really are step-shaped. When the form is submitted, send the email. If the amount is over $5,000, route to the manager. These rules exist, and automating them creates real value.

But step-shaped automation only covers the part of the work that already fits a process. It doesn't cover the rest. The supplier who misses a deadline. The order with an exception. The two systems that disagree about the price. The new regulation that changes how compliance has to work. We've been calling these "edge cases" for so long that we've stopped noticing they're not edges. They're the actual texture of operations.

Vertical software has been promised a smarter answer to this. Best-of-breed suites for procurement, supply chain, S&OP, quality make the pitch that the workflows inside these suites are deep enough to handle the complexity that horizontal automation can't. But they aren't really different in kind. They're just deeper and more complex implementation of the same step-shaped paradigm. The workflows are richer, the data models are more specialised, but they still expect work to fit predefined shapes. And they make a different problem worse: every suite models its own slice of the operation, but no suite models the operation itself. And over time, these rules and logic compound making them them almost impossible to maintain.

A newer generation has gone further. Agentic vertical specialists like Pactum and Lio aren't running deeper workflows. They're deploying AI agents that negotiate with suppliers, run procurement requests end to end, and execute purchases autonomously. But it's a smarter, faster horse - running on the same tracks as its predecessors.

The agents are more capable than the workflow automations they replaced, but they're still built around the same operating assumption: humans are the operators, agents are the assistants. The human runs the function. The agent makes them faster inside it. Which means the team's capacity is still bounded by how much human attention the function requires. You get faster procurement, but you don't get capacity back. The function speeds up but the human effort doesn't free up.

And the agents only cover the work inside the artificial functional silo. Artificial because the invisible lines that divide functions were arbitrarily decided long ago. The questions that sit between procurement and inventory, between procurement and finance, between procurement and the operation as a whole, are still owned by humans. That work doesn't fit any silo. We call it DarkOps. It's where most operational pain lives, and it's invisible to every tool that runs inside a function.

The agent that negotiates the supplier deal doesn't know what technical specifications have been requested. The agent that runs the procurement request doesn't know whether the inventory team is sitting on overstock that makes the purchase unnecessary. The agent that closes the contract doesn't know what the planning team will need from this supplier next quarter. The hard work isn't inside the silos. The hard work is in between. And as the operation grows, the only way to keep up with DarkOps is to throw more manual effort at it - which is ironically the cost that the agentic tools were supposed to eliminate.

Horizontal agentic platforms like Maisa and Wonderful go in the other direction. They give you the building blocks: a foundation for automation with AI, deploying them, monitoring them. Strong technology. But they have no opinion about operations. You still have to decide what process to follow, what workflows to design and you take the coordination role. The platform is generic. The operation is yours to figure out. The smartest companies in the world are now hiring teams to translate workflows into agent specifications. They've replaced the spreadsheet with a prompt. The problem doesn't go away, it simply gets recreated on a faster and more expensive piece of technology.

Different answers. Same problem. Each one solves a piece. None of them models the operation.

The reason isn't that any of these tools is bad at what it does. It's that they're all answering the wrong question.

The right question isn't what are the steps?

The right question is how the work gets handled, and by whom and where.

Operations are outcome-driven and run by teams

Which means every operation eventually comes down to two questions. What is this for? And who runs it?

Talk to a procurement leader  and the first thing you'll hear is what the team is for - the cost-of-goods target, the supplier-reliability bar, the OTIF rate they're trying to hit and the compliance posture they have to maintain. Operations don't exist for their own sake. They exist to deliver outcomes the business has agreed on. Outcomes are why the operation is there at all.

Then you'll hear about people. Who handles vendor onboarding, who runs the negotiation, who escalates the high-value POs, who watches the contracts for renewal. How they work together. Who hands off to whom. Who escalates what to whom. Operations don't run themselves. They're run by teams.

And running through it all, you'll hear about rules and policies - Spend authority, Approval thresholds, Compliance requirements, Approved-supplier policies. Operations don't run in open space. They run inside guardrails the business has set.

That's not a flowchart. It's a living system: outcome-driven, run by a team, bounded by rules.

Take any of those away and the operation breaks. A team without outcomes is busy but unaligned. Outcomes without a team are aspirations. Either of them without rules is a liability waiting to happen. Workflow tools capture only the rules, and even then only the simple ones. Vertical suites capture some of the outcomes, inside a single function. The team itself, the part that actually runs the operation, has lived in someone's head this entire time.

When I look at the operational chaos most companies live with, what I see isn't a missing flowchart. It's an operation that's missing some part of itself. A team that exists in someone's head but never got built into the system. Outcomes that everyone says they're aiming at but no one actually owns. Rules that drifted out of date five quarters ago. The operation runs on muscle memory because the design of it never got captured anywhere.

The job of running an operation isn't designing a workflow. It's defining the outcomes, standing up the team that runs toward them, and bounding both with the rules the business needs to enforce. Then keeping all of that alive as the business changes.

A different interface

If operations are outcome-driven and run by teams, then the way to describe an operation should look like the way you'd describe an operation to someone who has to run it. Which is to say: in words.

When you describe an operation to someone who has to run it, you don't draw a flowchart. You describe a structure. Here's what we're trying to achieve. Here's the team that's going to do it. Here's what each role owns. Here's how they coordinate. Here's what we expect them to escalate. Here's what they're not allowed to decide on their own. You're not connecting boxes with arrows. You're naming an outcome, the people who'll pursue it, and the rules they'll operate within.

That's the interface we built Canvas around.

In Kovant Canvas, you describe your operation in natural language across all three dimensions. You describe the outcomes: what the operation is for, what success looks like, what the business is trying to achieve. You describe the team: each role and what it's responsible for, what triggers their work, who they coordinate with, when they escalate to a human. You describe the rules: spend authority, approval thresholds, compliance constraints, the policies the operation has to operate within. The way you'd describe an operation that needs to be run.

Canvas reads what you wrote. It deducts what's needed. It composes a team of autonomous agents from a library of seventy-plus operation blueprints we've built across procurement, inventory, demand planning, quality, logistics, and more. The blueprints are the proven operational patterns. Your prose is the configuration that makes them yours.

The result is a working operation. Not a flowchart. An operation aimed at the outcomes you set, run by the team you described, bounded by the rules you defined.

Why this matters

Kovant runs your operations end-to-end on prebuilt foundation agents. Outcomes set by you, work executed autonomously.

That's the difference. The companies winning the next decade aren't going to be the ones with the most sophisticated workflow automation. They're going to be the ones whose operations think. Operations that can adapt when things change. Operations that handle DarkOps as easily as they handle the workflows. Operations that get smarter with every quarter that passes, the way a good team does. Living systems, not diagrams.

You can't build that out of step-shaped automation. You can't build it out of a deeper procurement suite, or a procurement agent, or a digital worker construction kit. You build it the same way you'd build any high-performing operation: by setting clear outcomes, standing up the right roles, defining how they work together, bounding them with the rules they need to follow, and trusting them to run.

When we showed the early version of Canvas to our design partners, the moment that consistently surprised them wasn't the speed or the autonomy. It was the register. Watching their own operation come alive on the screen, described in words they'd written, in the voice they actually use. One of them said it felt like writing the org chart they'd had in their head for years and finally seeing it work.

That's what we have built. An interface that matches how operations actually exist in the heads of the people who run them. Outcomes for the work. Words for the team. Rules for the bounds. Canvas for the design.

What's next

We've been working with a small group of design partners for months. The feedback has been better than we expected. We're opening Canvas to a wider audience inside our customer accounts in the coming weeks.

If your operations live in slides and spreadsheets, and the team running them lives in someone's head, we'd love to talk.

You don't draw operations. You describe them. Then you let them run.

Welcome to Kovant Canvas.

‍