A2APP / A LANGUAGE BUILT FOR AGENTS

Intent in.Workflow out.

A compact DSL for agents to compose tools, data and native interfaces. Built on Makepad Splash, with a bounded workflow runtime and an inspectable path from pixels to components.

Start building Explore the docs

Open source · Rust host · Makepad Splash VM

tool_workflow.octoscriptSOURCE EXAMPLE

use mod.tool

let task = "prepare release notes"
let result = tool.call("text.echo", task)
result

01 / SOURCEDefine

02 / HOSTExecute

03 / RESULTReturn

EXPECTED OUTPUT · TEXT.ECHO

"prepare release notes"

Host-authorized tool accessRun locally

LLM-generated sourceHost-controlled executionOptional native UI

01 / WHY A DSL?

Designed for the agent. Bounded by the host.

An LLM needs a language it can generate, check and repair. An application needs to know exactly what that program can do. Octoscript makes both sides explicit.

A smaller target to generate

A canonical grammar, versioned profile and structured diagnostics give the agent a focused generate–check–repair loop.

GENERATE → CHECK → REPAIR

Authority stays with the host

Registered tools, data contracts and per-step grants define available effects. Valid source cannot authorize itself.

REVIEW → GRANT → EXECUTE

Built to embed in an app

A shared Rust VM, explicit resource limits and host-pumped deferred work fit application lifecycles and UI event loops.

COMPACT → BOUNDED → EMBEDDABLE

Why not just generate Python or JavaScript?

General-purpose languages excel at ecosystem access. Octoscript chooses a smaller execution contract for generated programs embedded in an application: the model expresses work, and the host can inspect and control each step.

Design question	Python / JavaScript	Octoscript
Generation target	General-purpose syntax and ecosystems; the app defines its accepted surface.	Canonical grammar + profile + tool catalog.
Authority	Determined by embedding, isolation and exposed APIs.	No tool authority by default; host-issued grants.
Execution budget	Limits and app integration depend on the selected runtime.	Explicit instruction, time and memory bounds; host-driven yield and resume.

Compactness and efficiency are design goals. Safety and reliability come from checks, grants, budgets and host isolation—not an unmeasured performance claim.

Read the motivation and execution model

02 / WHY SPLASH?

Fork the foundation. Keep the UI ecosystem.

Splash brings a Rust VM, composable objects and a live UI language. Octoscript adds a bounded workflow contract and capability-controlled execution. VM hardening lives in the shared Makepad fork; UI composition continues to reuse Splash.

Why fork, and what stays shared?

WORKFLOW HOST

Octoscript

Tools · data · execution

UI HOST

Makepad UI

Widget DSL · native rendering

SHARED VMMakepad Splash

Shared implementation · host-specific bindings and VM instances

03 / MEET SPLASH

One language for UI, behavior and drawing.

Meet Splash from Rik Arends and the Makepad project: a live-editable UI language and the VM foundation of Octoscript.

component.splashUI HOST

View {
    width: Fill
    height: Fit
    flow: Down
    spacing: 12

    title := Label {
        text: "Ready to build"
    }
    launch := Button {
        text: "Run workflow"
    }
}

:=Named child:Property{ }Composition

UI excerpt: requires a host with Label, Button and other widget bindings.

01
Object composition
Type { … } instantiates definitions; name := identifies children. UI remains reusable and addressable.
02
Types and styling
+: merges inherited properties. Themes and kits share defaults across component instances.
03
Behavior and Rust
Functions and callbacks describe interaction; Rust registers components, owns state and implements services.
04
Drawing and motion
Shaders, instance values, uniforms and Animator support custom GPU visuals and state transitions.
05
Live iteration
A UI host can reload or update Splash, then inspect widgets and rendered frames to guide repairs.

Reuse Splash for UI. Keep workflow admission explicit.

Author Splash directly, or realize an L0 / L1 card tree, lower it through a kit, then evaluate renderer UiNodes and emit widget source. Sharing makepad-script does not share host permissions.

Explore Splash syntax, Rust and UI hosts

04 / GENERATED UI PROFILES

Declare the UI. Let the host render.

UI generation has its own contract: declarative L0 and a bounded L1 arithmetic extension. Below, distinguish these capabilities from the four implementation layers.

DECLARATIVE UI

Compose what belongs

Components, data bindings, keyed collections, state, and event transitions. Realize the node tree without a VM.

ComponentsBindingsState

BOUNDED EXPRESSIONS

Add a little calculation

Everything in L0, with bounded pure arithmetic expressions for values that the interface needs to derive.

L0 + arithmeticPure expressions

THE RENDERING HANDOFF

UiNode
Theme / component kit
Splash DSL
Native widgets

L0–L3: a verifiable component pipeline

These four layers describe how a card becomes an operable UI. They are separate from the language capabilities declared in card headers above.

L0
Check & realize
Card + host data → UI tree
Validate origins, state, keys and traversal budgets.
L1
Lower through a kit
UI tree + kit → component calls
Preserve roles, parameters, themes and source IDs.
L2
Evaluate & translate
Calls → UiNode → Splash
Evaluate source into UiNode; Rust emits widget descriptions.
L3
Mount & interact
Widgets → pixels + events
Real layout, rendering, input and state feedback.

Capability status: UI L0 is implemented; UI L1 admits bounded pure arithmetic only. UI L2 is unimplemented and rejected before parsing. No UI L3 capability profile exists. Pipeline layer L3 confers no execution authority.

Syntax, complete examples and level checking →

Component catalog and live examples Read the Makepad integration guide

05 / ONE LOGIC, MULTIPLE HOSTS

Share the Rust logic. Choose the UI host.

Makepad-drawn widgets and platform controls are both UI targets. A host can compose them in one page while keeping language, logic and rendering responsibilities clear.

Cross-platform widgets

Makepad

Rust + GPU backends share layout, drawing, components and interaction across native and WASM.

Platform controls

Android

Rust-evaluated tree → JNI → Java builder → Android / Material views.

Platform controls

OpenHarmony

Rust → ArkUI C API → native nodes; shell and specific platform handoffs remain in ArkTS.

Backend & integration points

iOS

Makepad has an iOS backend and native-view hooks; a complete UIKit tree requires a dedicated adapter.

ONE PAGE · COMPOSITION SCHEMATIC

Native camera / WebView surfacePlatform view lifecycle and capabilities

Makepad controlsPlatform input

SHARED RUST STATE · EVENTS · SERVICES

One page, coordinated interaction.

The host coordinates rectangles, clipping, layering, focus, keyboard and lifecycle. A native preview can carry camera frames, Makepad can draw custom overlays, and platform controls can supply system input.

Historical example: two camera hosts.

In the recorded development branch, camera/native and camera/oh depend on octosense-camera-logic. This is not the current Camera bundle architecture. They share the state machine and scene generation, rendering through Makepad kits or ArkUI C API nodes.

Inspect the shared logic and hosts

Makepad widgets and platform system controls are different backends. Same-page composition needs host adapters; arbitrary shaders do not become system controls automatically.

Read the platform mapping and composition details

06 / THE APP IS THE WORKBENCH

Put the tools in the app. Let the agent work directly.

From Studio for human developers to inspection and control primitives inside the app, reachable over a socket. An agent can understand and drive the running UI without operating an IDE window.

app --remote127.0.0.1:PORT / HTTP

01
Observe
Read widget IDs, types, text, state and current rectangles.
/snap?q=Button
02
Act
Click, drag, scroll, press keys and type using fresh bounds.
/click · /m · /k · /t
03
Verify
Wait for a real frame; inspect app pixels and behavior logs.
/g · /gseq · /log
04
Repair
Inspect reflected properties, try an edit, then persist it in source.
/tweak/state · /tweak/apply

Instrumentation is enabled explicitly for development. Headless means no Studio GUI is needed; visual checks still use the real GPU, with inspection and capture support determined by each host.

These instruments serve a coding agent. Runtime app agents are managed by OctoSense and octos, with permitted account workspaces, tools and conversation routes. Standalone card-host registers no agent services.

Explore the interactive app and agent architecture Read how language, instruments and A2App fit together

07 / PIXELS → COMPONENTS → APP

Give the pixels a component model.

Two flows preserve the link from visual source to runtime, letting an agent move into code and back to real widgets and interactions for verification.

image-to-card

Design related screens together, then connect their visuals, data and actions into a working service experience.

GitHub

01
Measure the source
Preserve the prompt, atlas, scene crops and coordinate transforms.
02
Map semantics
Map text, controls, numerical charts and artwork to appropriate components.
03
Bind the service
Extract service cards and connect reducers, state, grants and actions.
04
Verify and package
Inspect widgets and real frames, then export native or WASM packages.

AIRCON / SCENE 05

Example: installation after delivery

Select a source element to inspect its native component type and service event.

SOURCE ID: choose_time
WIDGET: KitButton
EVENT: installation.open_slots

The source button becomes a KitButton with separate control and label children; the installation service handles its action.

Original air-conditioner installation design with text, product photo and a choose-time button — 01 / DESIGN REFERENCE

Actual Makepad native render of the same installation card, with separate text and button widgets — 02 / NATIVE WIDGET RENDER

Archived source and native render; highlights locate mapped source regions. This iteration retains typography, icon and shadow differences. The inspector shows recorded mappings; it does not call an installation service.

kits/sketch

Use document hierarchy, symbols and source IDs to turn a design family into reusable native components.

GitHub

01
Read the design
Parse artboards, groups, fonts, masks and stable source IDs.
02
Compose natively
Keep text as labels, controls interactive and artwork traceable.
03
Inspect and repair
Verify trees, layout, real input and native frames.
04
Promote to a kit
Extract shared definitions, tokens and bindings for new pages.

TASKPLAN / ATRO / CAMO

Extract a reusable vocabulary from a design family.

A Camo music row retains its cover Image, title Label and play control, then becomes a shared CamoTrackRow. Instance parameters supply content and state while preserving source IDs.

The initial import preserves a fixed artboard; responsive layout and application behavior still need authoring. Quantitative charts use numerical widgets and explicit data, rather than painted curves.

COMPONENT STRUCTURE

CamoTrackRow
├─ Image       cover
├─ Label       title
├─ Label       artist
└─ control     play

KitButton  ·  KitFormField
KitTabBar  ·  TaskplanProjectCard

ONE DEFINITION → MANY INSTANCES → NEW PAGES

Read both flows and their mapping rules Try the aircon service example

RUST → WASM → MAKEPAD

Designs you can operate.

Explore Material components and Flutter example designs, drawn by the real Makepad renderer.

WebAssembly / WebGL

Choose an example

Choose a delivery speed, tap Gift wrap, check Send updates and confirm. The state below comes from real slots inside WASM.

Runtime: Not started
Last action: —
Component nodes: —

Start to inspect state

Loads on demand. State lasts for this instance. Flutter designs are Octoscript recreations; some nodes only illustrate or navigate. Device capabilities are not simulated.

Demo source Pinned sources Build digest

Makepad component lab

Start the lab to interact here.

MATERIAL 3 · FLUTTER DESIGNS

Requires WebAssembly and WebGL. The component catalog and instructions remain readable HTML; canvas accessibility differs from HTML forms. Full catalog and support scope →

08 / HUMAN REVIEW

From source to a human decision.

A workflow can run without a screen. When it needs a person, an App Card exposes the data, the context, and the next action.

01
Receive an event
Keep the original message attached to the proposed action.
02
Compose the interface
Present structured data through native components.
03
Review the next step
Let a person confirm or dismiss the proposal.

Component catalog and live examples

FROM EVENT TO APP CARD

Ms. Lin · Willow SchoolA little change to Friday

octoscript

Understand→Compose→Review

CALENDAR CARDREADY FOR REVIEW

A new time for the school visit

The school email proposes a new time. Review the calendar change here.

FRI, 18 SEP3:30 pm

School garden

Open original message

Ms. Lin · Willow School
Hello Alex, our school visit has moved to Friday, 18 September, at 3:30 pm. Please meet us in the school garden. — Ms. Lin

The source stays with the action

Interactive concept · sample data · no external actions

09 / YOUR FIRST WORKFLOW

A few lines Something to run

Check the source, register a local demonstration tool, and run. Then replace the demo tool with the services your application provides.

01
Get the source
Clone the Octoscript repository.
02
Check and run
The checker validates source before execution.
03
Connect your tools
Register tools in your embedding host.

Host tool catalog

tool_workflow.octoscript

use mod.tool

let task = "prepare release notes"
let result = tool.call("text.echo", task)
result

Expected output: text.echo → "prepare release notes"

Terminal

git clone https://github.com/OctoSense-org/Octoscript.git
cd Octoscript

cargo run --locked -p octoscript-cli -- \
  check examples/tool_workflow.octoscript

cargo run --locked -p octoscript-cli -- \
  run --allow-echo examples/tool_workflow.octoscript

Requires Rust and Cargo · run from the repository root

10 / DOCUMENTATION

A clear next step

Start with the architecture. Go deeper when you need to.

APPS & AGENTS

Intent in.Workflow out.

Designed for the agent. Bounded by the host.

A smaller target to generate

Authority stays with the host

Built to embed in an app

Why not just generate Python or JavaScript?

Fork the foundation. Keep the UI ecosystem.

Octoscript

Makepad UI

One language for UI, behavior and drawing.

Object composition

Types and styling

Behavior and Rust

Drawing and motion

Live iteration

Reuse Splash for UI. Keep workflow admission explicit.

Declare the UI. Let the host render.

Compose what belongs

Add a little calculation

L0–L3: a verifiable component pipeline

Check & realize

Lower through a kit

Evaluate & translate

Mount & interact

Share the Rust logic. Choose the UI host.

Makepad

Android

OpenHarmony

iOS

One page, coordinated interaction.

Historical example: two camera hosts.

Put the tools in the app. Let the agent work directly.

Observe

Act

Verify

Repair

Give the pixels a component model.

image-to-card

Measure the source

Map semantics

Bind the service

Verify and package

Example: installation after delivery

kits/sketch

Read the design

Compose natively

Inspect and repair

Promote to a kit

Extract a reusable vocabulary from a design family.

Designs you can operate.

From source to a human decision.

A new time for the school visit

Make room for a fresh start

One less thing on arrival

A few lines Something to run

A clear next step

Run an app, follow its agent

Why a DSL for agents?

Splash → A2App

Pixels → components

Syntax & L0–L3

Components & WASM lab

Purpose & architecture

UiNode to Makepad

The shared VM