Workspace

What is a Workspace?

For the purposes of this agenda, a workspace is the sociotechnical environment made available to a worker, human or AI, to use for a particular activity or practice, encompassing the tools, materials, and information they can draw on to pursue their work. The particular activity can be a general task—so that I might describe my desk as a writing workspace given the pens and papers it provides—or a specific domain, bundling together a number of different tasks and tools common to a practice so that I could describe my programming workspace as the collection of tools and products (e.g. VSCode, GitHub, AWS, etc.) I use to write, run, and deploy code. Workspaces are then always workspaces for some kind of work, understood through the affordances that make that work possible and actionable.

Introduced by psychologist James Gibson and popularized in design and Human-Computer Interaction (HCI) by Don Norman, affordances can broadly be understood as the actions an environment makes possible (e.g. climbing a tree to get a better view of something far off) for those interacting with it [7, 8]. For this agenda, we are particularly interested in how affordances serve larger goals or bodies of work.* This builds on relational [9], activity-theoretical [10], and sequential framings [11] so that, for this agenda, affordances in a workspace are understood and examined for how they enable a worker to complete the particular tasks in their broader work. To better formalize how workers might represent, learn about, and make use of what is actionable in their environment we can draw on uses of affordances in reinforcement learning [12, 13, 14, 15, 16]. To examine how tasks are structured, sequenced, and bundled into jobs—and how these arrangements shape opportunities for AI augmentation and automation—we can draw on work in labor and organizational economics [17, 18, 19, 20, 21]. Together, these perspectives allow us to examine what a workspace makes possible in relation to both the demands of the work and the abilities of the worker.

How effectively a worker can use their workspace, recognizing and utilizing what it affords, can depend either on their skill, on what their workspace makes available, or both. For example, as a novice, I might not fully understand how to best use the tools in my environment or the features provided by a given application, such as Excel or VSCode. With greater experience, I may discover new ways of working and better understand how to use what my workspace provides, while also recognizing where my workspace falls short of what I might need. As a developing programmer, I might then import a new library, install an extension, or rework my workflow to address what I now—through working—know. My workspace thus changes not only through ordinary day-to-day activity (e.g. file edits, deletions, etc.) but also as I adapt its tools and workflows to what I learn through doing the work [22].†

Nor does this development occur only at the individual level. Across a practice, workers encounter the possibilities and limitations of existing tools and methods, making do with difficulties, developing workarounds, or introducing improvements [23, 24, 25]. Some changes remain local or private; others are shared and adopted more widely, becoming part of the resources and know-how available across the practice [22] (Fig. 1). My programming workspace then not only includes all the work I've done but also the accumulated contributions of others: the libraries and frameworks they develop, the collaboration practices they establish, and the knowledge they share [26, 27]. What I can accomplish within it can then expand both as I learn to make better use of what my workspace offers and as what is offered itself changes. A worker can become more capable both by learning to use what's available and by changing what is itself available.

Workspaces are then sociotechnical environments because what they make available—and how it can be used—is shaped by both the social conventions (e.g. ways of working, collaborative norms, hierarchies) and technical arrangements (e.g. tools, information formats, infrastructure) of the practice in which they are situated [28]. Through their work, workers maintain, adapt, and extend these arrangements, carrying forward established ways of working while responding to new possibilities and limitations. A workspace is therefore both a setting for work and an accumulated outcome of the practices it supports [29]. It is in this sense that workspaces are always for a particular activity or practice: their tools, resources, and possibilities become meaningful in relation to the work being pursued.

When workers repeatedly confront similar problems, the ways they address them can converge into shared methods, tools, and expectations. Over time, these arrangements help form a recognizable practice, making it possible to speak of a programming workspace or a workspace associated with a particular occupation, rather than only the environment available to one worker [30]. As some problems become persistent or specialized, further practices and their supporting workspaces may emerge within or alongside existing ones: data engineering, for example, develops its own tools and conventions around problems that also arise in software engineering.

LLM Agents & Digital Workspaces

Generative AI is an increasing part of working life: by May 2026, 45% of U.S. workers aged 18-64 reported using it for their jobs, with adoption extending across computing, finance, education, and public relations [31]. Underlying many of these applications are large language models (LLMs), machine learning models trained on large collections of text to learn statistical patterns in language, including relationships among words, concepts, and contexts [32]. Learning these relationships allows them to predict the next token (i.e. a small unit of text, such as a word or a character) within a sequence from prior context, ranging from the text that immediately preceded it to the broader conversation supplied to the model. By predicting successive tokens, these models generate text for applications such as chatbots, coding assistants, and writing tools. Yet, on their own, LLMs remain limited by the information available to them and the reliability of their generated responses [1, 32].

LLM agents, or simply agents, work to address these gaps by equipping language models with tools for gathering information and acting in external environments; using LLMs to help interpret context, decide how to proceed with a task, and act on those decisions, with feedback from each action informing subsequent decisions [33, 34]. These tasks can range from checking today’s weather in San Francisco to arranging a trip there, a potentially complex, multi-step sequence which could include: clarifying the user’s preferences and budget; aligning their calendar's availability against available options; coordinating sub-agents to compare flights, accommodation, and prices across websites; and making decisions with the user’s explicit approval or autonomously within the scope of their consent. This expanded capacity to take on more complex, sequenced work has likewise expanded the range of tasks that can be delegated to AI, with agents increasingly being deployed across the workforce, particularly in computer-intensive areas such as IT, knowledge management, and software development [35, 36].

Yet if AI is taking on more human work, it is important to understand how we, as people with bodies—with biological needs, personal desires, interpersonal concerns, and living histories—differ from these digital workers. While we have defined workspaces to be ultimately agnostic of the kind of entity working with and within them, focusing instead on what a workspace makes possible in relation to both the demands of the work and the capabilities of the worker, the ways in which agents and humans are capable can significantly differ, even as agents increasingly share features of how we work (Fig. 2). For a more speculative and philosophical investigation into the differences between us and LLM agents, see Agent Phenomenology.

Like humans, agents work with the tools, materials, and information a workspace makes available to them as they pursue a particular activity. How effectively they pursue and accomplish that work depends on their capabilities, on what is available, and on how well they can recognize and use it. As the prior section described, a worker can become more capable both by learning to use what’s available and by changing what is itself available, potentially leading to larger changes across the practice. Whereas human capabilities are honed through personal experience, an LLM agent’s underlying capabilities are largely set when its model is trained, with its ability to adapt during work typically coming from the information its system supplies, such as tool results and stored records, rather than through changes to the model itself (Fig. 2) [2, 32, 37].

Because workspaces are commonly the result of human activity, both at the individual and occupational level, they often develop around human skills and needs, with tools, materials, and processes arranged accordingly [9, 38]. However, this does not mean that all workspaces are always arranged exclusively for human workers. Work, and the workspaces that support it, can be progressively reorganized to automate particular tasks or entire processes [39]. As this happens, workspace arrangements may increasingly reflect the requirements of machine operation, with human work shifting toward supervision, maintenance, and intervention [40, 41]. Historically, automating particular forms of work has often required changes to the tools, information, and processes through which that work is carried out [42]. However, the extent and difficulty of these changes can vary with how the work is organized and connected to other activities [42]. When retailers adopted barcode scanning in the 1970s, for example, its benefits depended not only on scanners but on IT systems and on suppliers’ investments in packaging and labeling, which made the products themselves machine-readable [42].

The extent and difficulty of these changes, however, can vary with how the work is organized and connected to other activities [42]. AT&T, for example, took nearly a century to automate telephone call switching, a technology invented in the 1880s, despite having the capital, manufacturing capacity, and technical knowledge to do so [42]. Its delays stemmed in part from how thoroughly telephone service had been designed around operators, from switching equipment and numbering plans to directories, leaving call switching entangled with nearly every other part of the business [42]. Thus, while usable inputs, well-specified procedures, and manageable exceptions are often pre-conditions that support automating a given activity, actual adoption also depends on the costs and organizational changes required as well as how the given activity connects to the wider work or process [39, 42].

Earlier accounts of computerization often emphasized how tasks needed to be specified through explicit rules in order to support automation, treating non-routine problem-solving and complex communication as harder to automate [43]. Tasks such as navigating a car through city traffic or deciphering the handwriting on a personal check, for example, were cited as ones that could not yet be described as programmable rules [43]. With the advent of LLMs and agents, and their demonstrated capabilities across a wide range of work, this perspective is being revisited. In AI exposure research, Eloundou et al. estimate that LLMs are relevant to roughly 14% of tasks per occupation on average, rising to 46–55% once complementary software built on the models is fully taken into account [44]. A newer measure based on observed use places computer programmers and customer service representatives, whose work centers on problem-solving and communication, among the most exposed occupations [45]. Eloundou et al. note, however, that their approach focuses on software capabilities rather than on the business process reengineering, new intangible assets, or workforce retraining that realizing this potential may involve [44]. 

Agents may be unevenly supported across practices, both by what their models have learned during training and by the information, tools, and feedback their workspaces make available. Even where an agent has access to the same materials as a person, it may receive them in a form that leaves out cues or relationships the person uses to make sense of the work. A document’s layout, for example, can distinguish headings, comments, and supporting notes, but those distinctions may be lost when an agent receives only its plain text. What supports a human worker may need to be represented or structured differently for an agent to use it well [38]. Bringing agents into workspaces built around people therefore involves examining what existing arrangements support and what may need adapting, a design inquiry developed further in Agent-Computer-Human Experience (ACHE).

Comparing how an agent carries out the same work under different workspace conditions gives us a way to investigate what particular arrangements contribute to its success or difficulty. Programming provides a useful starting point for examining this relationship. The success of coding agents has encouraged expectations that agents could perform other forms of computer-based knowledge work, but understanding what supports that success matters when considering how far it might extend across different working environments.

Coding Agents & Programming Workspaces