action.do: The Atomic Building Blocks of Modern Agentic Workflows

In the world of business automation, complexity is the enemy. As systems grow, simple scripts evolve into tangled webs of dependencies, making them fragile, difficult to debug, and impossible to scale. We need a better way to build—a method that prizes clarity, reliability, and reusability. Enter the concept of the atomic action, the fundamental building block of modern agentic workflows.

On the .do platform, an action.do is more than just a piece of code; it's the foundation of reliable Business-as-Code. It’s a self-contained, observable, and composable unit that performs a single, specific task. This is the new paradigm for building robust business automation.

The philosophy is simple: Define. Execute. Repeat.

What is an Atomic Action?

Think of an "atomic action" in the same way you think of an atomic database transaction: it's the smallest, indivisible unit of work that must either succeed completely or fail cleanly. There is no partial success.

An action.do encapsulates this principle. It is a self-contained, reusable function designed to perform one specific task and do it well.

Good Action: send-invoice
Good Action: update-crm-record
Good Action: enrich-user-profile
Bad Action: manage-all-billing-and-crm-updates

This atomicity is the key to building reliable systems. When a workflow fails, you don't have to untangle a monolithic script; you can pinpoint exactly which atomic workflow step failed and why. Debugging becomes simpler, and your system becomes inherently more resilient.

From Code to Composable Action: A Practical Example

Defining an action on the .do platform transforms a simple function into a managed, reusable, and observable asset. Let's look at how you can define an action to enrich user data using a third-party service.

import { Do } from '@do-platform/sdk';

// Initialize the .do client with your API key
const-do = new Do(process.env.DO_API_KEY);

// Define a new atomic action to enrich user data
const enrichUserAction = await-do.action.create({
  name: 'enrich-user-profile',
  description: 'Fetches user data from Clearbit and updates the DB.',
  inputs: {
    email: 'string',
  },
  handler: async (inputs) => {
    const userData = await clearbit.lookup(inputs.email);
    const dbResult = await db.users.update({ email: inputs.email, data: userData });
    return { success: true, userId: dbResult.id };
  }
});

console.log('Action created:', enrichUserAction.id);

Let's break this down:

Contract (name, description, inputs): We define a clear contract. This action is named enrich-user-profile and strictly requires an email as a string. The .do platform uses this to provide automatic input validation.
Handler Logic: The handler contains the core logic. It performs a single, focused task: it calls the Clearbit API and then updates a local database. It has clear inputs and a predictable output.
Managed Entity: Once created, this isn't just a function anymore. It's a versioned, observable action.do on the platform. It can be called, monitored, and composed into larger workflows without ever touching the underlying code again.

How is an action.do Different from a Serverless Function?

While an action.do might look similar to a serverless function (like AWS Lambda or Google Cloud Functions), it operates at a higher level of abstraction, designed specifically for building Services-as-Software.

A serverless function gives you a runtime environment. An action.do gives you a fully managed business capability. This includes:

Built-in Observability: Rich logging, versioning, and execution history are included out-of-the-box.
Automatic Schema & Validation: Define your inputs once and let the platform handle validation for every execution.
Seamless Composition: Actions are designed from the ground up to be plugged into .workflow.do agents, abstracting away all the boilerplate and infrastructure glue.
Enhanced Security: The platform provides a secure execution environment, managing credentials and access control.

The Golden Rule: Actions Do, Workflows Orchestrate

A common question is, "Can an action call another action?"

The answer is no, and this is a core design principle for building scalable systems. Actions are atomic; they perform a single task. To create a sequence of tasks, you use a workflow.

action.do (The Task): Focuses on the what. It's the verb—'enrich user', 'send email', 'generate report'.
workflow.do (The Orchestrator): Focuses on the how and when. It defines the sequence, logic, and error handling that connects multiple actions. For example, "On user signup, first run enrich-user-profile, and if successful, then run send-welcome-email."

This separation of concerns is critical. It prevents the creation of "spaghetti" automations where actions have hidden dependencies on each other. Your agentic workflow becomes a clear, readable process, and your actions remain independent, reusable, and easy to test.