Agentic business platform

The software your company runs on, built the way you work.

Customers, catalog, expenses and approvals, on a foundation where accounts, permissions, audit and workspace isolation already work. Describe a new process and it becomes a module.

$npm create flowdular@latest
MIT licensed core. Self-host anywhere.
MITCore license
12Modules in the repository
6Delivery gates
18Agent skills
TypeScriptEnd to end, server to screen
The platform beneath your product

A working foundation, not another starter kit.

Flowdular owns the shared concerns every business platform needs, so each capability you add stays a small, explicit module that people and agents can read, test and replace.

OOperations Demoactive
FFinance Demoactive
NNorthwind Tradingactive

Accounts and workspaces

Multi-tenant from the first request: a sign-up wizard, workspace slugs in the URL, memberships, invitations and external sign-in providers.

sales.orders.readsales.orders.managesales.orders.approveauth.users.readcatalog.items.managesystem.settings.manage

Permissions and audit

Roles built from module.entity.action scopes, API tokens and per-module settings. A module endpoint declares the permission it needs and denies by default, and agent, workflow and automation actions append to a trail that cannot be edited unnoticed.

authuserscatalogagentsworkflowsorders

Module composition

Enable a module with one command. The CLI writes the composition, installs the package, grants scopes, and the running app reloads without a rebuild.

lease acquired run r_41dtool catalog.items.search 3 rowstool parties.contacts.create idempotentrun committed audit #1 284

Agent runtime

Reusable agents run against registered tools with leases, recovery, idempotency and durable run history. Tools reach data only through approved endpoints.

Workflows

Typed pipelines on a visual canvas: agent, action, validator, gate, input and output nodes, with dry runs and run history.

Allow sign-up
Email confirmation
Session lifetime

Administration

Users, roles, modules, settings and audit in one place. Module settings live in the module drawer. Two locales out of the box.

Operator CLI

Dry run by default, --apply to write, --json for machines. Modules add their own namespaced commands with declared risk and approval.

$pnpm flowdular doctor --json
$pnpm flowdular module new sales.orders --spec modules/sales-orders/spec/module.yaml
$pnpm flowdular module enable sales.orders --apply
$pnpm flowdular auth sync-scopes --module sales.orders --apply
$
Workflows

Say what should happen. Watch it run before it is real.

A decision your team keeps making by hand becomes a process you can draw, test on sample data, and only then let near the real thing. Some steps are a rule, some are a person, and some are an agent reading the case and deciding.

  1. The need

    Before we pay a new supplier, somebody should check them. Right now it depends on who opens the invoice.

    Finance lead

  2. You draw it

    Five steps, named the way your team already says them out loud.

    New supplier checkDraft
  3. You test it

    It runs on sample data first. No agent is called and nothing is written.

    Going live is a separate confirmation.

    Sample dataSteps passed
  4. It runs without you

    Then it runs on a schedule you set, or when another system calls in.

    ScheduleSigned webhook
Pull the data
Read and decide
Check your rule
Approve paymentclears the rule
Send to a personneeds a person

No elevated permissions

Publishing checks every permission the process needs against the person publishing it, and checks again before each live run.

No silent changes

What runs live is the revision you confirmed. Editing it creates a new draft that has to be tested and confirmed again.

No duplicate runs

A schedule fires at most once per slot, and a slot missed while the platform was down is skipped, never replayed. A webhook needs a fresh, valid signature.

No missing history

Every run opens step by step in an inspector, and the record is chained so an entry edited later stops matching.

Security

The questions a buyer asks first, answered in the code.

No badges and no promises for a later release. Every line below is a property of the running system, and the file that implements it is in the public repository.

Your data cannot cross into another workspace

Every workspace-owned table has row-level security enabled and forced, bound to the workspace identifier set for the current transaction. The database refuses a row from another workspace even when application code asks for it.

No connection that can switch the rule off

The role the application connects with is neither a superuser nor allowed to bypass row-level security, and the platform proves that on the live connection through its readiness check.

Background work sees less than the app

Scheduled and recovery work connects as a separate read-only role granted only the few columns it needs to find a job. Payloads, inputs and permission snapshots stay unreadable on that connection.

Every action names the permission it needs

Each module declares its permissions in one file, and its endpoints refuse a request that does not carry the matching one. A route is never open because someone forgot to close it.

Recorded history cannot be quietly rewritten

Agent, workflow, automation and sandbox actions append to a hash-chained trail where each entry covers the one before it. A verify call walks the chain and reports the first entry that no longer matches.

Keys never sit in the database

Provider credentials and stored run payloads are encrypted with keys the deployment supplies from its own secret store. A database dump on its own reveals nothing readable.

How a change ships

From a business brief to a pull request, with every step checked.

The sandbox ties design and implementation to an approved specification. One session, one preview, one delivery, whether the change touches one module or five.

AM

We need customer orders with an approval step above 10 000.

Planner routed the brief to

BusinessUXBackendFrontendAgentic
modules/sales-orders/spec/module.yamlhash 3f9a2c
id: sales.ordersversion: 0.1.0capabilities: [api, database, client, translations]entities: - orderpermissions: - sales.orders.read - sales.orders.manage - sales.orders.approverules: - approval above 10000
Approve spec
Gates for sales.orders
spec-schema0.4s
module-schema0.6s
dependencies1.1s
typecheck8.2s
tests5.7s
format0.9s
6 of 6 passed
Sandbox preview

Orders

Rendered inside the real shell, with real permissions

feat(sales.orders): orders with approvalsandbox/orders-approval into main
spec-schemamodule-schemadependenciestypechecktestsformat
Gates passed · Ready for review
Eject locallyOpen pull request
Sandbox

The workshop where features get built.

A separate application that turns a business brief into a reviewed module. It drives the coding agent your team already uses, in an isolated workspace, against the same gates the platform runs.

Flowdular sandbox: the brief box above three delivered sessionsFlowdular sandbox: passing gates beside the diff of a new moduleFlowdular sandbox: the preview tab showing the draft expense claims screen inside the application shellFlowdular platform: the module catalog with the new module enabledFlowdular platform: the expense claims screen the sandbox session built
A brief starts a sessionDescribe the module or the change in business language and pick the coding agent. The planner names the modules and the first specialist.
Your coding agentClaude Code or Codex CLI on your machine, or the bundled simulation that calls nothing.
Isolated workspaceEach session gets a real pnpm workspace linked to the platform packages, never your repository.
Reviewed deliverySix gates and a live preview every turn, then eject into modules/ or open a pull request.
The module contract

Every module owns its API, data, screens, translations and tests.

A module is a package with a spec. The scaffold derives endpoints, permissions, migrations and client entry points from it, and validation keeps them in sync for as long as the module lives.

modules/catalog
  • spec/module.yaml
  • module.json
  • migrations
  • 0001_catalog_core.up.sql
  • 0002_catalog_history.up.sql
  • src
  • acl/permissions.ts
  • api/endpoints.ts
  • agent/tools.ts
  • services/database-repository.ts
  • client/CatalogView.tsrx
  • platform.ts
  • translations
  • en.json
  • pl.json
  • tests
  • endpoints.test.ts
  • migrations.test.ts
src/api/endpoints.ts
const list = defineEndpoint({ id: 'catalog.items.list', path: '/api/catalog/items', methods: ['GET'], access: { kind: 'permission', permission: PERMISSIONS.read }, handler: ({ octane }) => jsonResponse({ items: service.list(principalFromContext(octane)!.tenantId), }),});
  • An approved spec/module.yaml is the source of intent.
  • Permissions are declared once and enforced on every route.
  • Every query is tenant-scoped and every mutation checks the session.
  • Translations ship per module and are validated for key drift.
auth.coreusers.coresystem.coreprofile.coreparties.corecatalog.coreexpenses.coreagents.coreautomations.coreworkflows.coresandbox.coreauth.coreusers.coresystem.coreprofile.coreparties.corecatalog.coreexpenses.coreagents.coreautomations.coreworkflows.coresandbox.core
Agents

The part that decides, kept on a short leash.

A process can hand a case to an agent. What that agent may reach is not a matter of trust: your workspace binds it to a model provider, narrows its tools, and every run is recorded at a pinned version.

  • A run is pinned to one immutable agent revision.
  • The workspace narrows the tools the code allows, and each run narrows them again.
  • A tool outside that set is refused before it is called.
  • Provider credentials are encrypted with a key held outside the database.

The same guardrails in your editor

Eighteen skills in .ai/skills load into your coding agent, and AGENTS.md carries the contract, so the rules are the same in the sandbox and in your terminal.

/module-new /module-update /core-extend /bug-hunt /perf-audit /ux-design /auth-security-review /test-hardening /migration-authoring /translations-i18n /cli-extension /agent-tool-design /workflow-development /release-eject-pr
Invoice triagerev 7completed

Tools this run could call

9declared in code4kept by the workspace2granted to this run
parties.customer.getcatalog.item.list
run.queuedidempotency=inv-8f2
agent.startedrevision=7 attempt=1
tool.callparties.customer.get
tool.deniedTOOL_NOT_GRANTED
run.completed1.4s
Model provider bound per workspace
Open source

Built in the open. Owned by you.

Flowdular is developed publicly on GitHub. The core is MIT licensed, the roadmap lives in issues, and a change lands only through the same gates the sandbox runs.

  • MIT licensed core with no seat limits.
  • Self-host with the included Docker Compose and Kubernetes manifests.
  • CI verifies types, tests, specs, formatting, the build and the container.
  • Contribute a module or a fix through a pull request with gate evidence.
flowdular/flowdularThe agentic foundation framework for OctaneJS
TypeScript MIT main
StarForkIssues
Licensing

MIT core. Enterprise when you need it.

Use the foundation freely, in any company, forever. Add an enterprise agreement when your organization needs support, guarantees and integrations.

CoreMIT license
Free forever

The complete foundation in the repository.

  • Platform core, foundation modules, CLI and sandbox
  • Commercial use, modification and redistribution
  • Self-host on your own infrastructure
  • Community support on GitHub
Source and license on GitHub
EnterpriseCommercial license
Per organization

For companies running Flowdular in production at scale.

  • Commercial terms with warranty and indemnification
  • Priority support and fixes with an SLA
  • Guided deployment, upgrades and module reviews
  • Enterprise integrations: SSO, SCIM, audit export
Contact us

Common questions

Can we use Flowdular commercially without paying?

Yes. The core is MIT licensed. Build and sell products on it, modify it and keep your changes private.

What does the enterprise license add?

Commercial terms, support with response times, help with deployment and upgrades, and the integrations larger organizations require. The code you run stays the same core.

Which AI models do the agents use?

Agents run through model providers configured per workspace. The default local provider simulates runs without calling any external service, so you can start offline.

Do we own the modules the sandbox builds?

Yes. A module is ordinary code in your repository, delivered as files or as a pull request. There is no runtime dependency on a hosted service.

Start here

Keep the foundation. Shape everything above it.

Walk through what the platform already does, or start a working app on your machine in one command.

Run it locally

$npm create flowdular@latest my-app
$cd my-app
$pnpm flowdular setup quick --apply --confirm reset-local-auth
$pnpm dev
Node.js 22.22 or newer. No database server to install.

See what it does

The product tour, the module contract and the code behind every claim on this page.

See demoBrowse the source on GitHub