The useful question is rarely whether a system can do a task. It is which parts of skilled work should be handed to a system, which must stay with a person, and how the seam between them earns trust.
Most conversation about AI in skilled work gets stuck on the wrong question: can the system do the job. It is the wrong question because almost any task can be partially automated, and the interesting decisions are about where to draw the line, not whether a line can be crossed. Our Human and AI Collaboration research is about that line. Which parts of expert work belong to a system, which belong to a person, and what makes the handoff between them trustworthy.
Everything below is drawn from sessions where the line was drawn in practice, on running equipment, with somebody's production at stake.
Two Different Kinds of Work Hide Inside One Job
Watch an expert work and you will see two very different activities braided together. One is recall and correlation: remembering the relevant precedent, pulling the right reference, cross-checking a dozen things that have to line up. The other is judgment: weighing tradeoffs, reading a situation, deciding what to do when the consequences are real and the answer is not in any reference.
People are extraordinary at the second and merely adequate at the first. We forget, we tire, we take shortcuts under pressure. A system is the reverse: tireless and complete at recall, and genuinely poor at judgment that requires understanding stakes. The opportunity is to split the braided work along its natural seam and give each side to whatever is actually good at it.
The Failure Mode Is Spending Judgment on Recall
When the two are tangled, experts burn judgment on retrieval.
An engineer knew that a 24 V output from their controller told an upstream conveyor it was safe to feed. They did not know the tag, the routine, or the conditions, and the answer crossed a controller boundary. They had been searching a 112 MB export by hand for eight or nine minutes when they asked, and had not found it. The traced answer came back in about twenty seconds with the program, routine, and rung number attached to every claim.
Nothing about those eight minutes required an engineer. Opening the export, guessing at a naming pattern, cross-referencing candidates, jumping from a call site into an instruction body and mapping the arguments back is mechanical work that a person happens to be the only one doing. The expertise showed up in the sentence that started the session and in what they did with the answer afterward.
When a person's judgment is spent compensating for unreliable recall, you have not used the person well. You have used the most expensive part of them to patch the cheapest.
Elimination Is the Cheapest Thing Recall Buys
The most useful output of complete recall is often a negative result, and negatives are what tired people are worst at establishing.
A merge point was releasing product in alternating slugs instead of its configured ratio. The first question was whether the deployed gating code matched the reviewed source. A byte-level diff answered it in minutes: identical, apart from export whitespace and one comment alignment. That is the least interesting finding available and it removed an entire category of cause. The alternative is a day spent reading logic that turns out to be correct, plus an argument about whether the right version got downloaded.
The session did not produce the root cause. It cleared the code, confirmed the running configuration against the operator's expectation, documented an export trap that would have sent a manual investigation the wrong way on its first step, and reduced the fault space to two testable mechanisms with a discriminating test written for them. The rollout over the following weeks found the defects, on the line, with people testing. That division is worth being precise about, because elimination reads like a non-result until you count the days it does not cost.
Trust Comes From a Legible Seam
The hard part is not deciding where the line goes. It is making the handoff trustworthy. A system that does recall but hides how it got its answer forces the expert to either accept it blindly or redo it, and both defeat the purpose.
The clearest case we have ran on a lane that had been decommissioned in the warehouse host while its belts kept running. Naming the two enable bits that governed the whole lane took one search. The step that decided whether the change actually happened was the next one, when the engineer pushed back: this is a large control area, are you certain this will not hit other lines. The answer was an untruncated cross-reference on both tags, showing no motor outside the lane commanded by either bit, plus the finding that the shared merge conveyor at the end of the lane belongs to the adjacent zone, so stopping the lane can only stop it contributing to that merge rather than starving or backing up anything.
That is an answer an engineer can verify in their own editor before touching a running area. Reassurance is not. The engineer disabled both bits and reported back that every listed unit turned the state they wanted.
Legibility also means the system declining to fill a gap. Asked about four tag names copied off a screen, the lookup returned not found with close matches rather than a plausible-sounding answer about tags that do not exist. That refusal is what made the rest of the session possible. In the OEE decode, roughly half the operator-facing abbreviations had no confirmed expansion for that site, and they were flagged as unconfirmed with a note to ask a site expert instead of being expanded into something plausible.
When the seam is visible, something specific happens to trust: the people who trust the system least use the transparency most, which means they are verifying rather than rubber-stamping. That is well-calibrated trust, and it is the actual goal. We are not trying to make people trust the system more. We are trying to make trust track reality, so it is relied on exactly where it is reliable and questioned everywhere else.
The Seam Runs Both Ways
A division of labor that only lets the system correct the person is not a division of labor.
In that four-tile session the first hypothesis was a jam or gateway cluster, which is a reasonable read of four zones going red together on shared infrastructure. The operator pushed back with two facts from standing in front of the machine: the jam latch is clear, and the screen flashes like a motor fault. Both were right, and both came from a kind of knowledge that is not in any export. Tracing the jam-reset instruction confirmed the operator's read and reframed the whole session.
The live reads then went the other direction and contradicted the premise of the original question. Three of the four tiles had no fault bits set anywhere in the controller. It took sixteen cited reads at good quality to say that, which is the only acceptable way to tell the person on the floor that what they are looking at is not true.
Designing the Division on Purpose
The principle we keep returning to is minimum viable automation: automate the recall and correlation, preserve the judgment, and make the boundary between them something a person can see and check.
In practice, on these sites, that has been literal. The engine holds read-only connections and writes nothing. Every corrective action across these sessions was taken by a person: an engineer clearing two enable bits, a controls engineer writing pallet counts back to empty during a five hour palletizing stop, a technician chasing a motor connection error to a cable. When four lanes needed to physically stop and the diagnosis landed below the controller, the two effective levers were both physical, and the choice between clearing product and pulling power under lockout was the engineer's to make.
That boundary has a cost and it is worth naming. The loop closes on the engineer rather than the tool, which means the tool's value depends on the engineer having time to act on it. We take that trade deliberately for a running plant.
The grand version, where the system makes the consequential calls too, is both harder and, in most operations, not what anyone wants. The valuable version respects the seam. The system carries tireless attention to detail and cites where every claim came from. The person keeps the decisions that carry consequences, and keeps the standing to overrule. Getting that division right, over and over in different kinds of work, is the research. Nexus is where we find out whether we have it right.