Closable vs. Open: Which Business Problems AI Can Actually Finish

In February 2017, JPMorgan Chase disclosed a program called COIN (Contract Intelligence) that read commercial-loan agreements and extracted their key terms automatically. Bloomberg reported the number that made the story travel: work that had consumed roughly 360,000 hours of lawyers’ and loan officers’ time each year was now done in seconds, with fewer errors than the humans it replaced. Read past the headline and the interesting part is not the speed. It is the shape of the task. A commercial-loan agreement has a finite set of clauses. Each extraction is either right or wrong against a standard the bank already owned. And no counterparty rewrites the contract in the night to defeat the reader. The document sits still.

That is the whole reason COIN worked, and it is a reason that does not generalize. A loop that reads a static document to a fixed standard is running a closable problem: the inputs are enumerable, success is measurable, and nothing adversarial changes the game after the machine commits. The problems AI finishes are the closable ones: countable inputs, a checkable finish line, no opponent who gets a move after you act. The problems it can only amplify are the open ones, where the constraints don’t fully exist until you move and someone moves back.

What follows: why the closable half of your operation really is nearly finished, why the open half never will be, and why sorting your work by that single line, before you buy anything, is the highest-return hour a leadership team can spend this quarter.

The strongest version of “AI will finish this work”

Let me give the automation-maximalist view its strongest form, because the weak version (“AI replaces everyone”) is a straw man and knocking it down teaches nothing. The strong version is narrower and largely correct. A great deal of expensive knowledge work is closable, and closable work genuinely gets finished by an iterate-to-done loop. Invoice matching. First-pass contract review against a known playbook. Reconciling two ledgers. Generating the standard monthly report from the same tables every month. Producing forty variants of an ad and keeping the ones that convert. Classifying support tickets. In each case you can enumerate the inputs, you can write down what “correct” means, and you can let a loop grind until the output clears the bar. Concede this completely, because pretending otherwise is how incumbents get overrun: the back office of most companies is a stack of closable problems that have not yet been recognized as such, and the savings when they are recognized are real and large.

The place the argument breaks is the quiet extrapolation from “this closable task got finished” to “the business is a pile of tasks like this one.” It isn’t. The moment success stops being measurable against a fixed standard, or an adversary enters who adapts to your move, the loop loses the thing that let it finish. It can still help, enormously, but it stops being a solver and becomes an amplifier inside a game that stays open.

So the honest version of the steelman is this: closable problems get finished, and most organizations have far more of them than they’ve admitted, but a finished closable task is not evidence that the open problems next to it are closable too.

The category error

The mistake is to look at a closable win and reach for the same loop on an open problem, expecting it to finish. It never finishes, because the finish line keeps moving.

Consider pricing. A model can produce a defensible price in seconds: a competent recombination of the known patterns, as the last essay argued. But pricing against a live competitor is not a document that sits still. Airlines revise fares constantly through shared distribution systems; a fare you post in the morning can be matched or undercut by a rival’s automated system by the afternoon, and then you respond, and then they do. There is no state of the board at which pricing is “done,” because the board has an opponent. The same is true of a negotiation, where the counterparty reveals their real constraint only in response to your offer; of positioning, where the market re-sorts every competitor each time one of them moves; and of regulatory strategy, where the rule you are optimizing against can be rewritten by a body that is watching what you do. These are open problems. They are defined by constraints that do not fully exist until you act and someone acts back: exactly the constraints an executive is paid to read, from the first essay’s four: the market, the adversary, the commitment, the definition of good.

Ask an AI loop to “finish” one of these and you get a confident artifact that is right about the closable core and blind to the open frontier. The pricing model is internally immaculate and assumes a static competitor. The negotiation script is fluent and assumes the counterparty’s opening position is their real one. The output looks finished, which is worse than looking unfinished, because it invites you to stop thinking at the exact point where thinking was the job.

The tell is simple and worth memorizing. Ask of any problem: can I write down what “correct” means, and is there anyone who gets to move after I commit? If correctness is checkable and no one moves after you, it is closable; hand it to the loop. If correctness is socially or adversarially determined, or the constraints surface only once you have acted, it is open; the loop is an amplifier, and the judgment stays with you.

Where this leaves the tooling

The practical consequence is that you want two different postures from your AI, not one, and most tools blur them. On closable work you want a loop that runs to a standard and stops: governed, logged, and cheap, so it can grind through volume without a human in the seat for every pass. That is what a gateway is for: AOCore, with its AOSentry governance layer, exists to let closable execution run at volume behind guardrails and an immutable audit trail, so the finished work is trustworthy without being re-checked by hand each time. On open work you want the opposite: a fast amplifier that produces many disposable options for a human to test against constraints the machine cannot see, which is what a multi-model workspace like AODex is for. The error is asking the amplifier to be a solver, or trusting the solver on a problem that was never closable. The engineering companion to this series draws the same line through a codebase; the line is the same, only the work on either side of it changes.

What to do

Before you automate anything, sort it. Take your team’s actual weekly work and put each item on one side of the line: closable, or open. Be honest, because the sorting is where the money is. Most organizations discover two things at once. First, that far more of the back office is closable than anyone wanted to admit (reporting, reconciliation, first-draft review, ticket triage) and that all of it can go to a governed loop now, this quarter, for real savings. Second, that the handful of things they were most afraid to automate are open problems that were never going to be finished by any tool, and that the right move there is not a solver but an amplifier feeding a human who owns the constraints.

The failure mode to refuse is the blended pilot that runs a loop at an open problem, declares partial success because the closable core came out clean, and then ships the confident-but-blind artifact into a live game. That is the pilot that lies, and it lies precisely because the closable part looked finished.

Sort your problems before you staff them. The closable ones are nearly finished already. The open ones are the business.