AI Is Not a Tool. It Is a Participant in the Work System.

I was reading the work system theory wiki entry for the third time and something clicked that I had been missing. Alter (2013) defines a work system as a system in which human participants or machines perform processes and activities using information, technology, and other resources to produce products or services for customers. The phrase I kept rereading was "or machines." Alter wrote that in 2013, years before ChatGPT, before Copilot, before anyone outside of AI labs thought about autonomous agents as coworkers. He already made space for a non-human participant. The field just did not know what to do with that line yet.

I think the reason most AI implementation conversations feel stuck is that we keep treating AI as a technology in the old work system sense. We ask questions like "how useful is the tool" and "what is the adoption rate" and "does the user accept the system." These are TAM questions. They assume an operator using an instrument. But if you place AI inside the work system framework instead of inside the technology acceptance model, the unit of analysis shifts. You stop asking whether the tool is adopted. You start asking what the participant is doing, what processes it performs, how it changes the division of labor, and what governance structures you need for a participant that cannot be held accountable the way a human can.

The work system framework identifies nine elements. Processes and activities, participants, information, and technologies sit inside the system. Customers and products or services straddle the boundary. Environment, infrastructure, and strategies sit outside but affect the system directly. In a traditional work system, the technology element provides the tools that human participants use to perform processes. A database, a spreadsheet, a CRM system, all of these are technologies in the framework. They do not perform processes. They enable human performance of processes. The participant is always human.

An AI agent that writes code breaks this neat distinction. When a developer asks Copilot to generate a function, Copilot does not enable the developer to write the function. Copilot writes the function. The developer reads it, tests it, accepts or rejects it. The technology is not a tool being used. It is performing a process that used to be the human participant's job. That means AI occupies a different slot in the framework than the database or the spreadsheet. It is not in the technology element. It is in the participant element, or at least somewhere between the two, which is exactly the kind of boundary problem that the framework was designed to surface.

Alter's work system lifecycle model makes this even more interesting. The WSLC describes how work systems evolve through a combination of planned change through formal projects and unplanned change through adaptations, workarounds, and experimentation. When a human participant learns, their capability changes gradually through experience. When an AI participant is updated, the change is not gradual. A new model version replaces the old one overnight. A fine-tuning update changes how the system responds to certain inputs. A guardrail adjustment shifts what the AI will and will not do. The pace of change in the AI participant is discontinuous and externally driven, not organic and internally driven the way human learning works. The WSLC does not account for this asymmetry yet. I think it needs to, because the rhythm of change in the participant element determines the rhythm of adaptation in the whole work system. If the AI updates every two weeks and the humans around it cannot adjust their routines that fast, the work system enters a state of chronic misalignment between participant capabilities.

I wrote about sociotechnical systems and joint optimization a few days ago, and the same logic applies here. Bostrom and Heinen (1977) brought the principle into IS in the very first volume of MIS Quarterly. You cannot design the technical subsystem and add the social subsystem around it. They must be designed together. When the AI participant in a work system gains a new capability, say it can now handle exceptions it could not handle last month, the human participants need to know about it, trust it, adjust their review practices, and renegotiate the division of labor. That is not a technical update. That is a sociotechnical redesign of the work system. Most organizations treat AI model updates as deployment events. They are actually work system reconfiguration events, and they should be managed with the same rigor as a change in team structure or a process redesign.

The practical implication is that Alter's work system framework is the most useful tool I have found for designing around AI, precisely because it forces specificity. When people tell me their organization is adopting AI, I ask them to draw the work system. Who are the participants? Which processes does each participant perform? What information does the AI participant need, and what information does it produce? Where does the human review the AI's output, and where does the AI act without review? How does the division of labor change when the model updates? These are not abstract theory questions. They are the questions that most AI implementation plans skip, and they are exactly the questions the work system framework was built to answer.

I am not claiming Alter predicted AI agents when he defined work systems theory. I am claiming that he built a framework robust enough to hold them, and that most of the organizations deploying AI today have not taken advantage of that robustness. They are treating AI as a technology adoption problem and measuring it by use rates. It is not a technology adoption problem. It is a work system redesign problem, and the work system framework is the blueprint they are not using.