All research
November 2025·12 min read

36 Atomic Actions: A Complete Taxonomy of Business Operations

Every business process, regardless of industry or complexity, decomposes into a finite set of primitive operations. After analysing thousands of workflows across NDIS compliance, MSP operations, property management, and HR automation, we identified 36 distinct atomic action types that together cover the complete space of business operations. This paper presents the taxonomy, explains the design principles behind it, and demonstrates how the 36 atoms compose into arbitrarily complex real-world workflows.

The Case for a Finite Taxonomy

When we began building Atomic Work, we faced a foundational question: is business automation fundamentally unbounded — a space where every new integration and every new use case requires new primitives — or is there a finite set of atomic operations that, composed correctly, can express any business process?

The intuition behind the finite taxonomy came from chemistry. The periodic table does not have one element for every substance. It has 118 elements from which every substance in the observable universe is composed. The power of the periodic table is not completeness in the naive sense — it is the discovery that apparent complexity reduces to a small set of well-understood primitives with defined properties.

We hypothesised that business operations have the same structure. After mapping thousands of real workflows across regulated industries, SME operations, and enterprise processes, the hypothesis held. 36 atomic action types, organised into four categories, cover the complete space of business operations we have encountered.

Category One: Human Actions (12 atoms)

Human actions are atomic operations that require a person to take a deliberate action: decide, approve, review, sign, or acknowledge. They are the most important category because they represent the irreducible human element in automated processes — the decisions that should not be delegated to a machine.

The 12 human action atoms include: HUMAN_APPROVAL (binary approve/reject with optional comment), HUMAN_REVIEW (review and annotate a document or record), HUMAN_ESIGN (legally binding electronic signature), HUMAN_TASK (freeform task completion with defined output), HUMAN_DECISION (multi-option decision with typed outcomes), HUMAN_ACKNOWLEDGEMENT (explicit confirmation of receipt), HUMAN_FORM (structured data collection via form), HUMAN_UPLOAD (file or document submission), HUMAN_SELECTION (choose from a defined set of options), HUMAN_ESCALATION (flag for senior review), HUMAN_INSPECTION (structured observation with condition report), and HUMAN_INTERVIEW (guided conversation with structured output).

Each human action atom carries: the identity of the required actor (or a dynamic routing rule), a response deadline with escalation policy, the interface to be presented to the actor (magic link, in-app, or Slack), a typed output schema that downstream atoms can rely on, and an immutable log entry created on completion.

Category Two: AI Actions (8 atoms)

AI action atoms are operations performed by language models or specialised AI systems. They are distinguished from integration atoms by their non-deterministic nature — they produce outputs that are probabilistically correct rather than deterministically computed — and from human action atoms by their speed and scalability.

The 8 AI action atoms include: AI_GENERATE (produce text, structured data, or a document from a prompt and context), AI_CLASSIFY (categorise an input according to a defined taxonomy), AI_EXTRACT (pull structured data from unstructured text or images), AI_SUMMARISE (condense a document or dataset to key points), AI_VALIDATE (check a document or dataset against defined criteria), AI_TRANSLATE (convert between languages with domain-specific terminology), AI_VISION (analyse an image or document visually — the engine behind Napkin Scan), and AI_ROUTE (determine the correct path through a conditional workflow based on content).

AI atoms are always paired with a confidence threshold and a fallback path. When an AI atom produces output below the confidence threshold, the workflow automatically routes to a human review gate rather than proceeding on uncertain output. This is the structural implementation of human-in-the-loop: AI runs where it is confident, humans are invoked where it is not.

Category Three: Integration Actions (11 atoms)

Integration atoms are operations that read from or write to external systems: databases, CRMs, communication platforms, calendar systems, document tools, and payment processors. They are the connective tissue of the workflow — the steps that make automation useful by actually changing the state of the systems that the organisation depends on.

The 11 integration atoms include: CRM_WRITE (create or update a record in HubSpot, Salesforce, or similar), DB_READ (query a database or spreadsheet), DB_WRITE (write a record to a database or spreadsheet), CALENDAR_BOOK (create or update a calendar event with attendees), EMAIL_SEND (send a templated or AI-generated email via Gmail, Outlook, or SendGrid), SLACK_MESSAGE (post to a Slack channel or direct message), DOC_GENERATE (create a document from a template and data payload), FILE_STORE (persist a file to Google Drive, SharePoint, or S3), WEBHOOK_CALL (send a structured payload to an external URL), PAYMENT_TRIGGER (initiate a payment via Stripe or a payroll integration), and CREDENTIAL_VAULT (securely retrieve a stored credential for use in a downstream step).

Integration atoms enforce schema contracts at both their input and output boundaries. A CRM_WRITE atom that receives a malformed contact record fails immediately with a typed error — it does not silently create a partial record that corrupts the CRM. This is the integration equivalent of the type safety that governs the entire atomic workflow execution model.

Category Four: Control Flow Actions (5 atoms)

Control flow atoms govern the structure of execution rather than performing operations themselves. They are the grammar of the workflow language — the atoms that make composition possible.

The 5 control flow atoms are: BRANCH (conditional routing based on the typed output of a preceding atom), PARALLEL (execute multiple sub-workflows simultaneously and wait for all to complete), MERGE (synchronise the outputs of parallel branches into a single execution path), DELAY (pause execution for a defined duration or until a defined datetime — essential for inspection scheduling, SLA timers, and follow-up sequences), and LOOP (repeat a sub-workflow for each item in a collection — used for bulk processing, batch notifications, and iterative operations).

Control flow atoms interact with all other atom categories. A BRANCH atom receives the typed output of an AI_CLASSIFY step and routes to different human approval paths depending on the classification result. A DELAY atom followed by a HUMAN_APPROVAL atom implements the inspection notice requirement under Queensland tenancy legislation. A LOOP atom over a list of maintenance requests implements a batch contractor dispatch workflow.

Composability and Real-World Workflows

The power of the 36-atom taxonomy is not the atoms themselves — it is the combinatorial space they define. A workflow with 10 steps drawn from 36 atom types has 36^10 possible configurations. In practice, the vast majority of real business processes are expressible in fewer than 15 steps using 5-8 distinct atom types. The complexity of the taxonomy is lower than it appears; the expressiveness is higher.

A complete NDIS participant onboarding workflow uses: HUMAN_FORM (referral intake), AI_CLASSIFY (eligibility assessment), DOC_GENERATE (service agreement), HUMAN_ESIGN × 2 (participant and guardian signatures), DB_WRITE (plan activation in case management system), CALENDAR_BOOK (first support session), and EMAIL_SEND (confirmation). Eight atoms, five atom types, covering a process that previously required two days of manual coordination.

A P1 incident escalation workflow for an MSP uses: WEBHOOK_CALL (PagerDuty alert received), AI_CLASSIFY (severity classification), BRANCH (P1 vs P2 routing), SLACK_MESSAGE (on-call engineer notification), CALENDAR_BOOK (incident bridge), HUMAN_TASK (RCA completion), and DOC_GENERATE (RCA report). Seven atoms. The entire workflow from alert to RCA report, fully structured and auditable.

The 36-atom taxonomy is not a closed system. We anticipate that new integration categories — particularly in healthcare data systems, legal e-discovery, and financial compliance — will require additional atoms in the integration category. The design principle is conservative: a new atom is added only when the capability cannot be expressed as a composition of existing atoms. The goal is not completeness in a theoretical sense but practical expressiveness for the business operations that organisations actually need to automate.

Atomic Work - The Atomic Engine | B2B Workflow Automation