Too much machine, too little

It is tempting to tell the current shift as one story: machines are getting more capable, and every kind of work will absorb that capability at its own pace. Look at where the capability actually landed, though, and there are two stories pointing in opposite directions.

In knowledge work, there is too much machine. Systems can now draft, analyze, search and act faster than the people responsible for them can follow. In the skilled trades, there is too little. The electrician, the plumber and the carpenter work with tools that have barely changed in decades, while the work itself keeps growing.

Software goes where software already is. Knowledge work was digital before the shift began: its inputs and outputs were already text, data and screens, so new capability could pour straight in. Trade work is physical. Its inputs are walls, pipes, wiring and weather, and capability has to be carried there deliberately, by someone willing to learn the work first. Almost nobody has.

For the knowledge worker, the tools took the labor and left the accountability. A professional who once wrote the analysis now signs off on one a system wrote. A salesperson who once researched an account now answers for messages they did not draft. The work moved; the responsibility did not.

That creates a job nobody trained for: commanding a system. It means deciding what the system may do without asking, checking what it produced, and knowing when to overrule it. These are skills of judgment rather than operation, and the systems arrived before anyone taught them.

A tool that adds automation without adding a way to govern it makes the command problem worse. More output, less clarity about where it came from, and the same person answerable for all of it.

In this world, a good tool gives command back. People decide how far a system may act on its own, and every step it takes is written down where they can see it. A claim that cannot point at its source does not ship. And the tool fits into the systems a team already runs instead of asking them to start over.

Hyves, our division for knowledge work, is an AI go-to-market team for business-to-business companies. From one work email it researches the user’s company, searches their market, and writes a business case for every account worth opening. An agent per account then works the people inside it: the ones who feel the problem first, the buyer last, blockers never.

Two design choices carry the principle. A send mode chosen per account decides how far Hyves may act on its own, so that decision belongs to the person, one account at a time. And Hyves is a layer on the CRM a team already runs, not a replacement for it. The aim is to add capability without taking command away.

The trades have the opposite problem. The work keeps growing while experienced hands retire, and the masters who could teach the next generation are the ones leaving. Knowledge that took a career to build leaves with each of them, often unwritten, because so much of it lives in the hands and eyes rather than in documents.

The frustrating part is that the technology exists. Vision models, augmented reality and cheap sensors were practically designed for the trades. Trade work is spatial, visual and done with the hands busy, which is exactly the situation those technologies suit. Almost nobody builds them for the trades.

Part of the reason is that the trades do not look like a software market. The firms are small and dispersed, the buyers are rarely at a desk, and a job site is unkind to anything designed in a clean office: dust, noise, gloves, weak signal, no patience. A demo that impresses in a meeting room can fail in its first hour on site.

Here a good tool carries capability to the work rather than asking the work to come to a screen. It respects the tradesperson’s judgment instead of trying to replace it, and it helps carry what the retiring master knows to the apprentice who needs it. Above all, it works on site, in the conditions the job actually has.

Raven, our division for the trades, is in the making. We are doing field research with working tradespeople, and early prototypes are in build. It is unannounced by design. It ships when it survives a job site, not a keynote.

The two problems are opposites, and the tools that answer them will look nothing alike. The test for a good tool is the same in both worlds, though: after it arrives, does the person at the center of the work have more command over it, or less?

For the knowledge worker, that means governing capability that is already there. For the tradesperson, it means receiving capability that should have arrived long ago. In both cases, the judgment stays with the person doing the work. A tool that moves it anywhere else has added to the debt, however impressive it looks.