From Serverless Function to action.do: A Developer's Guide

Serverless functions changed the game. Whether you call them Lambdas, Cloud Functions, or just FaaS, they gave us an incredible power: the ability to run code in response to events without managing a single server. For years, they've been the go-to tool for everything from simple data processing to powering entire backends.

But as our applications grew more complex, and as we started building sophisticated, multi-step automations and "agentic" systems, the cracks in the serverless-for-everything approach began to show. A sea of disconnected functions, mountains of boilerplate for orchestration and validation, and a lack of clear business context.

What if there was a better abstraction? A primitive designed not just for event-driven compute, but for defining the fundamental steps of any business process?

This is where action.do comes in. It’s time to evolve from writing functions to defining Actions.

The Limits of Functions in Agentic Workflows

Think about a common business process: onboarding a new user. This might involve:

1. Validating their sign-up data.
2. Enriching their profile with a service like Clearbit.
3. Creating an account in your database.
4. Sending a welcome email.
5. Notifying the team on Slack.

Using traditional serverless, you'd create five separate functions. Then, you'd need another service, like AWS Step Functions or custom orchestration logic, to chain them together. For each function, you'd handle API keys, logging, input validation, and error handling—often in slightly different ways.

This approach has several hidden costs:

• Lack of Business Context: A function-3a5b doesn't tell you it's the "Enrich User Profile" step. It’s just code. Its business-level purpose is lost.
• Orchestration Overhead: You become an infrastructure plumber, spending time stitching services together instead of focusing on the core business logic.
• Discoverability Issues: How does a new developer on your team know that a perfectly good function for sending templated emails already exists? They probably don't, so they write another one.
• Brittle Composition: If the output of one function changes, the downstream function breaks without a clear contract. Debugging becomes a distributed treasure hunt through logs.

Serverless functions are powerful, but they are a low-level compute primitive. For building robust, scalable business automation, we need a higher-level building block.

Enter action.do: The Building Block of Automation

An action.do is the smallest, indivisible unit of work in a system. We call it an atomic action. It's a fully managed, reusable function that performs a single, specific task.

• send-invoice
• update-crm-record
• enrich-user-profile
• run-fraud-check

Each action.do is an encapsulated, observable, and composable unit—the foundation of a reliable Business-as-Code strategy. It's not just a function; it's a declared business capability.

Let's look at what that means in practice.

From Unstructured Code to a Defined Action

Imagine you want to create the "Enrich User Profile" step from our onboarding example. Instead of provisioning a generic serverless function, you define an Action on the .do platform.

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) => {
    // Core logic lives here
    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 down why this is a leap forward:

1. Self-Documenting: The name and description aren't just comments; they make this action discoverable and understandable to anyone on your team.
2. Built-in Validation: The inputs schema is a contract. The .do platform automatically validates incoming data, so your handler code can trust its inputs. No more manual if (!inputs.email) boilerplate.
3. Focus on Logic: The handler contains only what matters: the actual business logic. Infrastructure concerns like versioning, logging, and security are handled by the platform.
4. A Reusable Asset: Once created, enrich-user-profile becomes a reusable component in your organization's toolkit. It can be easily plugged into any agentic workflow that needs it.

It's More Than a Wrapper

"So," you might ask, "is this just a fancy wrapper around a serverless function?"

No. An action.do is a fundamentally different abstraction.

The key difference lies in the principle of atomicity and orchestration. An action.do is designed to be atomic—it does one thing. It cannot call other actions. To connect multiple actions into a sequence, you use a .workflow.do agent. This crucial separation of concerns is what makes systems built on the .do platform so robust and easy to reason about. You separate the what (action.do) from the how (workflow.do).

This is the core of Services-as-Software—treating business capabilities as well-defined, managed, and composable software components.

Define. Execute. Repeat.

Serverless functions were a necessary step in the evolution of cloud development. They freed us from the server. Now, it's time for the next step: freeing ourselves from the boilerplate and cognitive overhead of managing raw functions.

By elevating your business logic from simple code to defined, atomic actions, you build a more resilient, scalable, and understandable system. Your automations are no longer brittle chains of functions but robust workflows composed of reliable, reusable building blocks.

Stop thinking in functions. Start building with Actions.