Curiouser and Curiouser: A Framework for Building With AI in Ops

Ops teams can finally build their own AI workflows. Some are doors worth opening, others are floors you fall through, and four questions tell you which is which.

By Kelly Breakstone Roth, Co-Founder & CEO of Prysmic · April 2026 · 7 min read

Something rare is happening in operations right now.

For years, the tools to actually build lived somewhere else: in engineering, in IT, in a vendor's roadmap. The ops team was the one with the problem, not the one who got to solve it. That is no longer true. With AI, the tools are in our hands. You can build something yourself in an afternoon. You can take a process you have been doing by hand for five years and have it watching itself by Friday. You can stop waiting and start creating.

It is hard to overstate how freeing this is. After a long stretch of being handed other people's software, ops leaders are finally asking different questions. What can I create? What can I improve? What have I been blocked on for years that I can finally touch? A real professional unlock, the kind that sparks genuine creativity and doesn't come around often.

Curiosity is the right response. Explore. Play. Build.

The Wonderland problem

But this is Alice-in-Wonderland country. Some workflows look like the little door in Chapter One: tidy, contained, a clean job. Then the cake says Eat Me, the scope grows faster than the workflow can hold, and suddenly you are too big for the room you built. The model sounds certain, and then the answer disappears when you look again. A job that started as a single afternoon's curiosity becomes a pool of tears of your own making, one you have to swim through every week just to keep the thing running.

These are not just Wonderland hazards. They are the known failure modes of enterprise AI. Researchers at Harvard and BCG call it the "jagged frontier": the same technology that performs brilliantly inside one zone produces confident nonsense just outside it, with no obvious line between the two. Wharton's Ethan Mollick, who helped coin the term, has written that working well with AI is less about the model and more about knowing where the edge is.

Most ops teams don't fail at AI because AI doesn't work. They fail because they pick workflows that look like they sit inside that frontier (quick, contained, clean) when they actually sit just outside it. By the time the difference shows up, they are rebuilding the same workflow every time a portal redesigns a page, a supplier format shifts, or the model changes its mind.

The point is not to stay out of Wonderland. It is to know which doors open into something useful, and which ones leave you swimming in a pool of your own making.

So here is the framework I walk through with customers who ask: what should I attempt myself, and what shouldn't I?

Four questions before you build an AI workflow

1. Reach: How many systems does it touch, and can you actually get to them?

One or two systems with clean APIs is manageable. Three or more, in mixed formats and weak integrations (or worse, with no integration surface at all) is a different kind of problem.

Most people ask the first half of this question and skip the second. The second matters more. A lot of the tools ops teams live inside (carrier portals, supplier portals, forwarder platforms, broker systems) have no API. They have logins, CAPTCHAs, PDFs, and export buttons that break when the vendor changes a menu. No-code platforms can paper over this with scraping, but scraping is borrowed time. A workflow that depends on a system that was not built to be worked with will break every time the vendor redesigns a page, and the team that owns it will spend more weeks fixing it than it ever saved.

This is also where orchestration quietly begins. Carrier billing, supplier invoicing, landed cost reconciliation: these are not one-step tasks. They pull from rate cards, portal exports, PDFs, ERP records, and dispute threads that live for weeks. That is not a workflow you build on the side. That is case management, and it only grows the closer you get to it.

2. Memory: Does the workflow need to carry state across time?

"State" is the workflow's memory of where each case stands over time. In logistics, that timeline is rarely a week, it is months. A PO is cut in March. Production confirms in May. The first container leaves in July. A short delivery surfaces in August. A claim opens in September. A credit posts in November. A revised forecast feeds December planning. State is what keeps all of that stitched together so the step happening in November knows what the step in August decided.

If every run is independent (a price check, a threshold alert, a single classification), state doesn't matter. Simple is fine.

But if a single case has to live for months and cascade across claims, credits, replacements, partial receipts, and forecast revisions, the workflow needs durable, reliable state. This is where most DIY builds quietly fail. They can answer the question in front of them, but they cannot carry the case forward. An alert can tell you something is wrong; it can't resolve it.

3. Reliability: How right does the output have to be?

This is the question the current AI moment is underestimating. Models can produce a clean-looking classification, a plausible HTS code, a supplier match that reads as 90% correct, and be wrong in ways that are hard to catch without context. That is tolerable when a person is reading the output. It is not tolerable when something downstream depends on it being right.

"AI-safe" in operations is not just about data privacy. It is really three things:

• Output trust. Can you catch the model when it is confidently wrong? Do you have evaluations, guardrails, or second-pass checks built in, or are you taking the first answer on faith?
• Data exposure. What is the model actually seeing? Are PII, rate cards, customer contracts, or payment details flowing somewhere they shouldn't? Most lightweight builds do not answer this cleanly, because they were not designed to.
• Explainability. Six months from now, when finance asks why a line was flagged or a code was assigned, can you reconstruct the decision? Or is the reasoning gone?

Reliability has a cost curve. The higher the stakes, the more scaffolding the workflow needs around the model. That scaffolding is buildable. It is not something most ops teams should be building alone.

4. Autonomy: Is the workflow recommending, or is it executing?

This is the single most important question of the four.

A recommendation is an AI output that a human reads, judges, and acts on. A flagged mismatch. A suggested classification. A summary of five invoices. If the model is wrong, the human catches it before anything happens downstream.

Execution is different. Execution is the model acting on its own: issuing a debit note, posting a charge, updating an ERP record, sending a reply, kicking off a payment. When AI executes, you are not just trusting the model's answer. You are trusting the system around the model to catch failure before it ships.

AI is forgiving when it recommends. It is unforgiving when it executes. That is not a function of how smart the model is. It is a function of what has to be true around it: auditability, rollback, escalation, recovery. Those things do not ship with an LLM. They have to be built deliberately, and that is what turns a workflow into a system.

The practical rule: if the output is advisory, you can probably own it. If the output takes action, think twice. If the action lands on your ledger, do not build it yourself.

A useful lens

A frame that helps here comes from Ethan Mollick's Co-Intelligence: the distinction between a "centaur" workflow and a "cyborg" one. In a centaur, the human and the model work in a clean division of labor: AI proposes, human decides. In a cyborg, the two are intertwined in real time, passing context back and forth, with the model making decisions of its own along the way.

Both are productive. They are also different categories of build. A centaur workflow is what most ops teams can realistically own. A cyborg workflow, with AI coordinating state, taking actions, and carrying cases over months, is not a workflow at all. It is infrastructure, and infrastructure belongs to the people who build infrastructure.

At the Cheshire Cat's fork

To sum this up, here is what to take away.

When Alice reaches a fork in the road, she asks the Cheshire Cat which way to go. His answer: "That depends a good deal on where you want to get to." The AI-build decision in ops is the same exchange. The road worth walking depends entirely on the shape of the work you are walking into. Here is how to read the two paths.

Build yourself when the workflow is narrow, informational, sitting inside a system you can reach, and recommending rather than executing. Those are the roads worth walking. They will make your team faster, your process clearer, and your curiosity pay off.

Skip the build when it spans systems you cannot cleanly reach, carries a financial blast radius, lives for months, or takes action on its own. That kind of work is real and valuable. It just isn't something your ops team should be running on the side.

AI belongs in all of it. The choice is which roads you walk yourself, and which ones need a different kind of build entirely, one you were never going to finish in an afternoon.