Defining Services-as-Software with a Library of Reusable Actions

In today's fast-paced digital landscape, automation is the engine of efficiency. We start with simple scripts to glue systems together, but as we scale, we often end up in a "script jungle"—a tangled web of brittle, duplicated, and hard-to-maintain code. What if we could move beyond these disposable scripts and build a truly composable enterprise?

The answer lies in shifting our perspective from writing one-off automations to building a comprehensive internal service platform. This is the core idea of Services-as-Software: treating your business logic not as fleeting code, but as a durable, versioned, and discoverable library of services. The fundamental building block of this new paradigm is the atomic action.

The Problem with Traditional Automation

Think about your current automations. A new user signs up, and a script fires off to enrich their profile, add them to a mailing list, and create a CRM record. A month later, another team needs to enrich user data for a different workflow. Do they reuse the existing logic? More often than not, they copy-paste or rewrite it, leading to:

• Logic Duplication: The same task is implemented in multiple places, creating inconsistencies.
• Poor Observability: When a multi-step script fails, it's often difficult to pinpoint which specific task was the culprit without digging through logs.
• Lack of Reusability: Code isn't structured for easy reuse, hindering development speed.
• Brittleness: A change in one API can break multiple, seemingly unrelated scripts.

This approach doesn't scale. To build robust, enterprise-grade automations, we need to think in smaller, more reliable units.

Meet action.do: The Building Block of Automation

On the .do platform, we formalize this concept with action.do. An action.do is the smallest, indivisible unit of work in any agentic workflow. It's a self-contained, reusable function that performs a single, specific task.

Encapsulate any single task—from sending an email to running a complex calculation—into a reusable, observable, and composable Action. The foundation of reliable Business-as-Code.

This philosophy can be summed up in three words:

Define. Execute. Repeat.

By defining every business task as an action.do, you create a standardized, atomic unit that is inherently testable, reliable, and designed for composition.

From Code Snippet to Composable Action

Let's see what this looks like in practice. Imagine you want to enrich user data using a service like Clearbit and update your database. Instead of a loose script, you define an action.do.

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

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

// Define a new atomic action to enrich user data
const enrichUserAction = await doClient.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 down why this is so powerful:

• name & description: The action is self-documenting and discoverable within the .do platform. Another developer can immediately understand its purpose.
• inputs: It has a formal, versioned contract. The action explicitly declares it requires an email of type string. The platform can enforce this, preventing bad data from ever reaching your logic.
• handler: This is the core logic. It's focused on a single responsibility: getting data and updating the database. It is isolated and can be tested independently.
• Managed Execution: Once created, this action is a first-class citizen on the .do platform. It's versioned, secured, and fully observable, with logs and metrics captured automatically.

Building Your Internal Service Library

Now, imagine creating more actions: send-welcome-email, create-invoice, update-crm-record, provision-user-account. Your collection of simple, atomic actions quickly becomes a powerful library.

This library is the foundation of your Services-as-Software platform.

• Discoverability: Teams no longer need to ask, "How do I enrich a user profile?" They can simply search the action library for enrich-user-profile and use it.
• Composability: While actions are atomic and cannot call each other directly (a key design principle for reliability), they are designed to be orchestrated by a .workflow.do agent. This powerful separation of concerns allows you to build complex business logic by composing simple, reliable units.
• Reliability: If the send-welcome-email action fails, it doesn't bring down the entire user onboarding process. The failure is isolated to that specific workflow step, making debugging trivial and the overall system much more resilient.

Frequently Asked Questions

Q: What is an 'atomic action' on the .do platform?

A: An atomic action is the smallest, indivisible unit of work in a workflow. It's a self-contained, reusable function that performs a single, specific task, like 'send an invoice' or 'update a CRM record'. This atomicity ensures reliability and simplifies debugging.

Q: How is an action.do different from a serverless function?

A: While similar in that they execute a piece of code, a .do Action is a fully managed, versioned, and observable entity within our platform. It includes built-in input validation, logging, and security, and is designed to be seamlessly composed into larger Agentic Workflows, abstracting away infrastructure concerns for a superior developer experience.

Q: Can actions call other actions?

A: No, actions are designed to be atomic. To orchestrate a sequence of actions, you use a .workflow.do agent. This separation of concerns—single tasks in action.do and orchestration in workflow.do—is a core principle for building robust and scalable systems.

Q: What kind of logic can I put inside an action?

A: An action handler can contain virtually any code: API calls to third-party services, data transformations, database queries, or complex business logic. The key is that the action should focus on successfully completing one well-defined task.

Conclusion: Build Your Composable Enterprise

Stop writing brittle scripts. Start building a library of reusable, atomic action.do units. By treating your internal business processes as a first-class service platform, you create a system that is more reliable, scalable, and faster to adapt. This is the future of business automation—a composable enterprise built on a foundation of simple, powerful actions.

Ready to transform your business logic into reliable, scalable services? Get started with the .do platform today and build your first atomic action.