Skip to content

Principles

A few choices shape everything in Lainstack. They explain why the product works the way it does, and what to expect as it grows.

Every step of an automation is a block: a supported, documented piece with typed settings, typed outputs and known failure modes. Each one has a reference page listing its settings, outputs and exits.

Blocks are meant to be reused, and so is everything built from them:

  • An automation that several workflows need becomes one automation they all call.
  • A sign-in is stored once as a connection and picked by every block that needs it.
  • Shared data lives once in a reference table.

When a workflow needs something the blocks cannot do, the lasting answer is a new block that everyone can use, not a private script nobody else can maintain. For small gaps, JavaScript Transform runs a short piece of code inside the automation, tested like any other block.

Reuse over repetition. Two workflows call one shared automation instead of each rebuilding the same steps.

Lainstack does not ask you to move your data or replace the tools your teams rely on. Automations read from and write to those systems through their own interfaces: HTTP and SOAP APIs, object storage, mailboxes. When a workflow changes, the systems of record do not have to.

Lainstack is built so that you can leave, which is also why it is safe to stay.

  • Open standards. JSON Schema files can be imported as fields, XML is checked with XSD, schedules use cron and IANA time zones, sign-in uses OAuth, and AI clients connect over the open Model Context Protocol.
  • Your automations are files. Download automation saves an automation as a JSON file, and Import brings one back.
  • Your AI provider. AI blocks and agents use your own provider account: OpenAI-, Anthropic-, Gemini-, Azure- or Bedrock-compatible models, or your own gateway.
  • Open source. The core will be released as open source under the AGPLv3, and it is built to be self-hosted. It is not published yet. During the private beta, Lainstack runs as a managed service, and self-hosting is available by request.

AI is a tool inside a workflow, not the workflow. It runs only in the blocks where you add it, with the model and provider you choose. Agents can read the workspace, but can change nothing until you turn on write access, and even then risky changes wait for a person to approve them. Steps and spending have limits you set. See Use AI blocks and Build your first agent.

You choose which steps need a person: an approval before an order goes out, a correction when data cannot be read, a review when a check finds something. The run waits, the escalation goes to the person or team you chose, and the decision is recorded with the run. Everything else runs on its own.

Each run keeps which version ran, every step it took, what went into each step and what came out, with secrets left out. When something goes wrong, you can see exactly where and why, test a fix against the same data with writes held, publish it and resume the runs that failed. See Debug a failed run.

Last updated: