Orchestration, compiled.

Why a new language?

• Orchestration written inside a general-purpose language is invisible: no tool can verify, diagram, or gate a flow it cannot read.
• A declared flow is visible: the compiler derives the dependency graph from it, so a breaking change is refused before production.
• One declaration, three projections: the running code, a live diagram, and typed tools agents can call.
• Deliberately small: it coordinates, never computes. Business logic stays in your languages; only contracts and wiring are declared. Nothing to rewrite.
• No orchestrator in the path: a compiled flow is plain code inside your service. Service A still calls Service B directly, no engine, no broker, nothing new to run. Durable execution is opt-in, per capability.

capability publish_report {
    description: "Render a report and store it for distribution"

    accepts { dataset_id: String }
    returns { report_url: String }
    errors  { render_failed, store_unavailable }

    flow {
        call render_report {
            args { dataset_id: context.dataset_id }
            on_error: render_failed
        } as rendered

        call store_asset {
            args { asset: rendered.artifact }
            on_error: store_unavailable
        } as stored
    }
}

The compiler is free, with nothing to install but itself, and the flows it compiles run as plain code in your services: no orchestrator in the call path. The platform above is the paid product, for governance and for the capabilities you choose to make durable.

If you run more than a handful of services and this problem feels familiar, I would like to hear from you.

LinkedIn