Describe the business system. Swirls operates it.

Describe the apps, data, workflows, agents, connections, and access in one reviewable .swirls project. Your coding agent authors against the Swirls language. The LSP and CLI check its work. The managed runtime provides the production services the declared system needs.

The source tells the runtime what to operate.

Apps, data, workflows, agents, connections, and access share one system model. Swirls turns those declarations into supported runtime services and keeps their operations in one place.

You declare

One business system in .swirls

Apps
Data
Workflows
Agents
Connections
Access

Swirls managed runtime

The production services are part of the platform.

Operating

Hosting

Serve supported Apps and endpoints.

Durable execution

Carry waits, retries, and long-running work.

Identity and access

Apply supported entry and resource boundaries.

Credentials

Supply stored secrets to declared work.

Managed state

Keep declared records and workflow state.

Operations

Keep runs, traces, reviews, and failures visible.

The business gets

One system that stays in service

People use the App
Events start work
Runs keep their state

01 · Describe

Give the coding agent a finite target.

General-purpose code leaves the architecture open. The Swirls language gives the agent named primitives and typed references for the complete business system.

support-system.swirls
database tickets {
  schema: @prisma {
    model Ticket {
      id      Int    @id @default(autoincrement())
      summary String
    }
  }
}

workflow triage_ticket {
  root {
    type: database
    database: tickets
    operation: insert
  }
}

app support_desk {
  page queue {
    render: @openui {
      root = ViewTable("open_tickets", "Open tickets")
    }
  }
}

The interface and the work behind it use the same named data and ship from the same source.

02 · Prepare

Check the structure and review the business behavior.

The LSP gives the coding agent feedback while it works. swirls doctor validates the merged project. You decide whether the process, rules, and result match the business.

Project check

swirls doctor

Passed
Declarations
Parsed
References
Resolved
Embedded code
Checked

Your review

Does this system match the business?

Structural validation cannot prove the requirements or the result are correct. You make that call.

03 · Operate

The runtime carries the production responsibilities.

Swirls hosts supported interfaces, runs long-lived work, supplies stored credentials, applies supported access rules, and keeps the system state available to the next step.

Support system

Runtime services active

Hosted interfaces

Serve supported Apps and endpoints.

Durable work

Carry waits, retries, and long-running state.

Runtime access

Apply supported entry and resource boundaries.

Credential delivery

Supply stored secrets to declared work.

Source validation, deployment history, and rollback support safe changes to these running services.

04 · Inspect

Follow the work while it runs and after it finishes.

The operating record stays with the system. See which step is active, where a person reviewed the work, what failed, and which source defined the run.

Quote request · #1842

Waiting for review

Runs

See the current state and outcome of each run.

Steps

Follow the path through workflow and agent work.

Reviews

See where a person paused or continued the work.

History

Connect operational behavior to the defining source.

You own what the system should do. Swirls owns the production services it runs on.

You own

The process, system design, business rules, acceptance criteria, and every change to intended behavior.

Swirls owns

Structural validation, hosting, durable execution, managed state, credential delivery, supported access enforcement, and operational history.

Bring the job. Put the whole system on one runtime.

Start with a working build, a named process, or grounded client discovery. Define what the system must do and let Swirls carry the production services around it.