Knowledge Work as Atomic Operations
All knowledge work, however you slice it, gets completed through a series of atomic operations.
When someone sits down to accomplish a knowledge task, they perform a sequence of discrete cognitive acts. They formulate queries. They search for information. They retrieve documents. They read and extract what is relevant. They evaluate sources. They synthesize findings. They condense, summarize, and compress. They expand and elaborate. They draft, revise, and refine. They structure and restructure. They compare and contrast. They decide and justify.
The specific sequence varies by task. A researcher follows a different path than a claims adjuster, who follows a different path than a marketing analyst. But in every case, the work decomposes into these atomic operations. When the sequence completes successfully, a deliverable emerges: a report, a decision, a recommendation, a document, an analysis.
This has always been true. What has changed is which of these operations can be delegated to machines.
What Computers Could Do Before
Software has long been able to assist with knowledge work, but only with certain types of operations.
Computers excel at storage and retrieval. They can hold vast quantities of documents and fetch them on demand. They can search structured data with precision. They can route information between systems. They can apply rules to structured inputs. They can calculate, tabulate, and visualize. These capabilities are genuinely powerful, and they have been the backbone of knowledge work infrastructure for decades.
But computers could not perform operations that required understanding natural language. They could not read a document and extract the key points. They could not evaluate whether a paragraph was relevant to a question. They could not synthesize information from multiple sources into a coherent narrative. They could not draft a response that addressed the nuances of a situation.
These operations — the ones involving comprehension and generation of natural language — remained stubbornly human. Software could present the document to a person, but the person had to read it. Software could store the draft, but the person had to write it. Software could route the customer inquiry, but the person had to understand it and compose a reply. The human performed every operation that required actually understanding or producing language.
This was the bottleneck. Not storage. Not retrieval. Not calculation. The bottleneck was the cognitive work that happened between retrieval and output — the reading, evaluating, synthesizing, and writing that only humans could do.
The First Change: Delegating Language Operations
Large Language Models change this equation. For the first time, the atomic operations involving natural language can be delegated to computers.
An LLM can read a document and extract key points. It can evaluate whether content is relevant to a query. It can synthesize information from multiple sources. It can summarize, condense, and compress. It can expand an outline into full prose. It can draft communications. It can translate between formats, styles, and languages. It can assess tone, sentiment, and intent.
This means that workflows which previously required human involvement at every language-dependent step can now proceed automatically through those steps. The human specifies the goal, reviews the output, and intervenes at key decision points — but the mechanical work of processing and generating language can be delegated.
This alone is transformative. Processes that took hours can take minutes. Work that required dedicated staff can run unattended. Bottlenecks at human-dependent steps dissolve. A literature review that took a researcher three days of reading and note-taking can be compressed into an afternoon of reviewing AI-generated summaries and making judgment calls. A compliance check that required a specialist to read every document can become a system that flags the documents that need human attention.
The operations are the same. The sequence is the same. What changes is who — or what — performs each step.
The Second Change: Participating in Orchestration
But there is a second capability that is equally important and often overlooked.
Beyond executing individual operations, LLMs can participate in — or even drive — the orchestration of those operations. They can decide which operations to perform and in what sequence.
Consider what orchestration involves. Someone or something must determine: What information do we need? Where should we look for it? What queries should we use? Which results deserve deeper investigation? How should we structure the analysis? What is the right output format? When is the work complete?
Traditionally, these orchestration decisions were either made by humans in real time or encoded in advance by system designers who anticipated the workflow. The human analyst decided what to search for next based on what they had found so far. The software developer hardcoded the processing sequence based on how the task typically unfolds.
LLMs introduce a third option. The orchestration decisions themselves can be delegated to the model. Given a goal and a set of available capabilities, the LLM can determine the path. It can formulate a research plan, execute it step by step, evaluate progress at each stage, adjust course when initial approaches fail to yield results, and continue until the goal is met.
This is the distinction between using an LLM as a worker — executing individual operations within a predefined workflow — and using it as a planner — deciding which operations to invoke and how to sequence them. Both are legitimate uses. The design challenge is knowing where each applies.
Two Modes of Integration
This gives us two fundamentally different ways to integrate LLMs into systems.
Mode 1: LLM as Worker
In this mode, the system designer defines the workflow. Step one extracts key information. Step two evaluates against criteria. Step three generates a summary. Step four formats the output. The sequence is predetermined and fixed.
The LLM executes each step but makes no decisions about what step comes next. It is a powerful worker — capable of cognitive operations that previously required humans — but it operates within a structure defined externally. This mode maximizes predictability. You know exactly what will happen for any given input. The path through the system is fixed and auditable. You can optimize each step independently. When something goes wrong, you can identify exactly where.
Mode 2: LLM as Planner
In this mode, the system provides the LLM with capabilities and goals rather than a predetermined sequence. Here are the tools you can use: search, retrieve, analyze, summarize, compare. Here is what we need: an assessment of this situation with supporting evidence. Figure out how to get there.
The LLM decides the path. It might search, evaluate results, decide to search again with a refined query, retrieve promising documents, extract relevant sections, compare findings, and synthesize a conclusion. The specific sequence emerges from the model's judgment about what is needed at each step. This mode maximizes flexibility. It handles novel situations that do not fit predetermined workflows. It adapts when initial approaches fail. It can tackle open-ended problems where the right process is not known in advance.
The Hybrid Reality
In practice, the most effective systems combine both modes in layered architectures.
A document review process might have a fixed outer workflow — intake, classification, analysis, recommendation, output — where the overall structure exists for good reasons: compliance, consistency, auditability. But within the analysis step, the task might be genuinely open-ended. Different documents require different approaches. Some need deep research; others are straightforward. That step invokes an agent that adapts its approach to the specific document, while the outer workflow ensures every document passes through the required stages.
Conversely, a customer service system might need an agentic outer layer — customers ask unpredictable things, and the system must interpret and respond flexibly. But when the agent determines that a customer needs a specific artifact — a policy summary, an account statement, a coverage explanation — it invokes a proven deterministic pipeline that produces that artifact reliably every time.
These patterns nest recursively. A deterministic workflow calls an agent that selects among deterministic tools, each of which might have agentic substeps. The architecture becomes a tree where each node chooses its mode — deterministic or agentic — based on what that layer of the work actually requires.
Design Implications
This analysis has several practical implications for building AI systems.
Choose the top level deliberately. What sits at the top of your system sets its overall character. Deterministic tops provide predictability and auditability — important for regulated processes, compliance-sensitive workflows, and situations where consistency matters. Agentic tops provide flexibility and adaptability — important for customer-facing interfaces, research tasks, and situations with high variability. The choice should reflect the nature of the domain, not the capabilities of the technology.
Encapsulate complexity in well-designed tools. When agents have access to well-orchestrated tools, they operate at a higher level of abstraction. Instead of reasoning through ten micro-steps, they select among three proven capabilities. Each tool encapsulates a reliable workflow. The agent's job becomes selection and sequencing, not reinventing processes. This matters because every decision point for an agent is a potential failure point. Fewer decisions about better-designed options yields more reliable results.
Match the mode to the task. Some tasks are predictable — same inputs, same process, every time. These are candidates for deterministic orchestration. Optimize them, lock them down, make them reliable. Other tasks vary significantly based on context. The right approach depends on what you encounter along the way. These are candidates for agentic approaches that can adapt. The art is identifying which is which, and being honest about it. The temptation to over-automate predictable tasks with agentic approaches is real — and wasteful. The temptation to over-constrain variable tasks with deterministic workflows is equally real — and produces brittle systems.
Conclusion
Knowledge work has always consisted of atomic operations. LLMs change which operations can be delegated to machines — specifically, the ones involving natural language. But they also change something more fundamental: they enable machines to participate in orchestrating those operations, not just executing them.
Effective AI systems leverage both capabilities. LLMs execute atomic operations that previously required human cognition. And LLMs help plan and coordinate those operations in ways that adapt to circumstances. The design challenge is determining where each mode applies and building architectures that combine them effectively.
The technology is powerful. The design choices determine whether that power translates to reliable, valuable systems. Understanding the structure of the work itself — the atomic operations, the orchestration decisions, the places where flexibility matters and the places where consistency matters — is the foundation for making those choices well.