Engineering Went 10x. The Company Didn’t.

I opened by telling the room what I actually came for. We have 10x’d product development at my company. That number is worth nothing while it stays inside engineering.

For the acceleration to materialize, it has to leave the building. It has to go through business development. It has to go through sales. It has to go through marketing. And it will not, and it cannot, unless those teams embrace the same 10x that engineering did. I am hiring business people who understand that. If I can find them, we are going to have a very good time.

So the ninety minutes were spent on the one thing we consider every time we build anything: making the cost of a process predictable. The most reliable way to make token spend predictable is to spend almost no tokens at all.

The prompt that works and leaves nothing behind

Here is what most people do with AI today. They open a window, type one good prompt, read the output, check it, and it works. Nothing about that is wrong. The problem is what it leaves behind, which is nothing.

The next person who needs that job done writes a slightly different prompt. They may be less sophisticated at it than you were. Two things follow. The work stays fully probabilistic, every single time anyone runs it. And the cost stays high and unpredictable, because every run pays full price for reasoning that was already done.

A good prompt is a personal skill. An organizational asset is something else. It runs the same way for the next person, and it costs the same on Tuesday as it did on Monday.

Label every step: deterministic or thinking

A pipeline is a set of steps, and the first thing you do is mark each one. Is it deterministic, meaning a rule produces the same output from the same input every time? Or is it thinking, meaning a judgment that a rule genuinely cannot make?

Students find this out fast: most steps they assumed were thinking are mechanical once you look at them. The five types below are how you make that cut precisely rather than by instinct.

• Coordination — binds, routes, records. Decides nothing about the work. Deterministic.
• Mechanical — a rule. Same input, same output, no tokens spent on the decision.
• Thinking — judgment a rule cannot make. The only place a model belongs, and the only place that costs.
• Test — runs the real checks and compares against the state before the change.
• Gate — permits or refuses. Its condition is written as code, never as a sentence in a prompt.

Thinking is the only line item that moves

Thinking is a variable cost. Mechanical steps are a fixed cost, and almost zero at that.

That sentence is the whole economic argument, and business students get it faster than engineers do. Every step you convert from thinking to mechanical moves spend from a line that scales with volume to a line that does not move at all. The pipeline should avoid thinking at all costs, and then buy the best possible judgment in the one or two places that are genuinely left.

What I showed them

I built a framework that takes the thing you would have typed as a prompt and converts it into a workflow. The output is highly deterministic. Where thinking genuinely remains, it exposes exactly which steps those are rather than hiding them in prose, and it puts guardrails around each one.

A business team enters its process in plain text and verifies the flowchart that comes back. The organization supplies the verification rules and the tools. Nobody on that team writes code, and what comes out is still something an auditor can read.

Two guardrails carry most of the value

A gate’s condition lives in code, never in a prompt. A prompt is a request. A rule is a rule. If the approval limit is a sentence asking the model to be careful about anything over five thousand dollars, there is no approval limit.

A thinking step may never write a mechanical step’s output. Evidence a model can edit is not evidence. The translation lands immediately with this audience: the auditor does not get write access to the ledger, however good the auditor is.

The hardest question is what counts as one unit of work

Everything downstream of that answer trusts the units it produced, which makes it the one layer where the right choice genuinely depends on the domain. The test is two competent people given the same input with no way to talk to each other. If they produce the same units, write the rule. If they would argue, spend a model.

A forty-page contract into reviewable obligations is judgment, because where one obligation ends is arguable. A support inbox into cases is judgment, because two emails may be one problem and one email may be three. An invoice against a purchase order is both, and that is the answer most teams need. Matching line items is arithmetic. Deciding whether the mismatch is a dispute, a discount or a typo is not.

The question students cannot usually answer is the useful one. If your first step is a model, what checks it? A bad decision downstream fails a test. A bad decomposition produces units that each look fine and collectively miss the thing that mattered, and nothing downstream catches it, because everything downstream trusts the units.

What the room took away

Teams spend the back half of the session drawing a loop for a real process: refund requests over five hundred dollars, supplier invoices that do not match their purchase order, inbound résumés for one open role, contract renewals with changed terms. They decompose it, classify every step as deterministic or thinking, find the single judgment that needs a model, and write one gate as a condition rather than an intention.

The trap built into the exercise catches most teams. They let the thinking step do the deciding and the doing at once. The question that springs it is short: what happens when it is wrong, and how would you know?

The session ran well at Wichita State, and the part that landed hardest was decomposition itself. Teams kept splitting a step into smaller and smaller tasks until the one task that genuinely required thinking fell out of it. Everything left around that task turned mechanical, which is exactly the result you want and never the one people expect.

The ask I left them with is the same one I opened with. Convert yourself into a pipeline. Then find every step in it that does not need to think.

An AI system you can trust in a business is mostly code, with judgment in the few places only judgment will do.

Course materials are open: github.com/TheChrisOneil/agentic-loop

Chris “Buzz” O’Neil is CTO at EverBetter. linkedin.com/in/thechrisoneil