A language for growing agent programs

Small programs.
Visible decisions.
Room to grow.

Give models the judgment. Give programs the structure.
ALGAL makes both readable, bounded, and inspectable.

Try a program
reply.algalOne program. Two views.
01 / Read the intentSource ↓
program reply(email: text) -> text {
  budget { max_agent_calls: 2 }

  let intent = decide "What does this email need?" using email
    as choice {
      help: "Help with a problem",
      sales: "Information before buying",
      other: "Anything else"
    }

  let task = match intent.value {
    help => "Draft a helpful support reply.",
    sales => "Draft a concise sales reply.",
    other => "Draft a clarifying question."
  }

  return generate task using email
}

A decision. A pure match. A draft.
The model sees the context you declare. The program makes the limits visible.

2 executor attempts, at most0 model calls in match
02 / See the structureExpand ↗
Generated reply program graph: email flows into a typed decision, a pure decision adapter and match, then generation. Email also flows directly into generation as explicit context.
Generated from the compiled manifest, including the pure decision adapter. Arrows are data dependencies.

Executable source, not pseudocode. The Bun compiler lowers .algal into the existing algal.organism.v1 format. Both runtimes execute the compiled manifest.

One executable meaning

Read it. Run it.
Ask what happened.

A diagram comes from the program. An execution overlay comes from its receipt. The views stay connected to the artifact they explain.

  1. 01

    Write a program

    Immutable values, explicit model effects, exhaustive choices, and declared budgets.

    .algal source
  2. 02

    Compile its structure

    A deterministic compiler produces a typed manifest and a source-map sidecar. Diagrams come from that manifest.

    .algal.json + diagram
  3. 03

    Keep the evidence

    Receipts record execution. Replay checks the orchestration against recorded external answers.

    receipt + verification

Replay checks execution consistency. It does not establish that a model answer is true or attest that a provider performed an operation.

The same core, more ambitious programs

Start small.
Grow deliberately.

Refine a draft. Suspend for approval. Apply a child program to a collection. Propose a new program. Every effect and boundary has a place in the graph.

Bounded refinement

Improve it.
Check it.
Know when to stop.

An editor rewrites a draft. A critic returns ship or revise. A repeat cell carries the draft into the next round, up to 4 rounds.

The final verdict still matters. Reaching the round limit returns the last outputs; it does not turn revise into success. The graph sends that result to hold.

The boundary is part of the program4 rounds maximum

Each round contains an editor and a critic. The parent's attempt budget also bounds nested execution.

Inspect the manifest ↗
Actual program / repeat + guarded branchesExpand ↗
Generated refinement graph. Draft enters a repeat cell bounded to 4 rounds. Its final verdict selects ship or hold through explicit guards.
The loop is a bounded child operation. The outer dataflow graph stays acyclic.
Durable approval

Pause the work.
Keep the progress.

A model reviews evidence and proposes a recommendation. The process can suspend while a child program waits for a host-supplied approval message.

On resume, a pure check requires both an approve decision and a matching release identifier before the publication effect becomes eligible.

Authority remains with the hostRecommend → wait → authorize

This example publishes a report to a local mailbox. The model does not approve or deploy a release.

Run the durable process demonstration ↗
Actual program / tools + durable childExpand ↗
Generated release review graph: evidence feeds recommendation, a proposal is recorded, the child waits for approval, and an authorization expression guards publication to a local mailbox.
Data dependencies retain the order. Mailbox capabilities are admitted by the host.
Bounded composition

One useful program.
A collection of questions.

The each cell applies a pinned child program to each question, up to 8 items. A pure function joins the answers.

The child's interface makes it reusable. Its content digest fixes which program is being called. The parent bounds how much work the collection can create.

Fan-out is explicit structure8 items maximum

Independent work is visible in the graph. This does not promise concurrent execution or a wall-clock speedup.

Inspect the manifest ↗
Actual program / each + collectionExpand ↗
Generated question swarm graph: a list of questions enters an each cell with maxItems 8, then answers flow to the pure join.v1 function.
A reusable child is an artifact with a declared interface, not an invisible prompt template.
Programs as values

A program can
propose its successor.

A designer produces a child manifest as data. A bounded spawn operation admits and runs it, and its digest is appended to a persistent population slot.

That is the starting point for a habitat. Foundry and civilization workflows evaluate candidates on declared cases; host selection decides what to retain or promote.

Proposal is not promotionInspect → evaluate → select

The graph shown records a proposed child's digest. It does not itself prove improvement or promote a winner.

Explore measured populations and lineage ↗
Actual program / spawn + persistent slotExpand ↗
Generated habitat graph: a goal reaches a designer agent that proposes a child manifest; spawn runs the admitted child, then its digest joins population history and is written to a slot.
Execution explains what a program did. Evaluation and lineage explain why a version was retained.

These are generated views of existing executable manifests. The first source-language release covers values, decisions, generation, and pure selection; composition, waits, and evolution remain available through the manifest API.

From one program to a measured population

Growth needs
a selection rule.

Better programs come from evidence. Keep the candidate, its evaluation, and the host's decision connected—so growth has a history you can inspect.

  1. 01 / proposeCandidate artifacts

    Model-produced plans or manifests

  2. 02 / admitTyped, bounded programs

    Host compilation and checks

  3. 03 / measureEvaluation evidence

    Declared cases and work limits

  4. 04 / selectRetain or promote

    Host policy and recorded lineage

Conceptual lifecycle of the existing foundry and civilization workflows. This is not a recorded run or a promise that a candidate improves.

Start with a real artifact

Twenty lines.
A graph you can inspect.

Clone the repository and use Bun 1.3 or newer. Compile the source, check its graph, and export the diagram. No model credentials are needed for these steps.

Get ALGAL on GitHub ↗
Terminalsource → manifest → diagram
# Install from the repository root
bun install --frozen-lockfile

# Compile readable source
bun cli.ts compile examples/source/reply.algal \
  --out reply.algal.json \
  --source-map reply.source-map.json

# Check it and export its structure
bun cli.ts check examples/source/reply.algal
bun cli.ts diagram examples/source/reply.algal \
  --format svg --out reply.svg

The compiler emits the existing manifest contract. Model execution uses an explicitly configured executor or scripted responses.

01

Pure core, explicit effects

Immutable values and deterministic expressions carry the structure. Models, tools, and durable state have visible boundaries.

02

Bounds before execution

Programs declare limits. The host owns admitted functions, providers, tools, and capabilities. A manifest grants no OS isolation.

03

Evidence you can inspect

Content-addressed programs and receipts connect source, structure, and execution. Measure quality on the workload that matters.