Developer reference

What a flow may contain, what the engine exports, what a package and a collection are on disk, and what an agent tells a board — each rendered from the file the code is held to.

The reference documents#

• The DSL reference — Every node type, channel, edge and requirement a flow may declare, version by version.
  rendered from LGFlow/docs/reference/dsl-reference.md
• The API reference — The programmatic surface: what each module exports and what it throws.
  rendered from LGFlow/docs/reference/api.md
• The solution package format — What a solution package may contain, and the four gates into the library.
  rendered from LGFlow/docs/reference/package-reference.md
• The collection format — What a knowledge collection is on disk — the contract between whatever builds an index and whatever answers from it.
  rendered from LGFlow/docs/reference/collection-format.md
• The monitoring protocol — What an agent tells the board, and what the board may tell an agent.
  rendered from LGStudioMonitor/docs/protocol.md

Which document answers which question#

The vocabulary every document assumes#

Four words, and one rule about numbers. Having these straight makes the rest of the reference read easily; not having them straight is where most confusion starts.

Channels#

A flow's state is a set of named channels, declared with a type and a reducer. The types are string, number, boolean, list, object, any and file. The built-in reducers are replace, append and merge; anything else is looked up in the registry.

A node writes to the channel named in its output, and the reducer decides what writing means — replace overwrites, append adds to a list, merge folds into an object. Which matters most in a fan-out, where several copies of the same node write at once.

Nodes#

Fourteen kinds: handler, llm, tool, tools, fanout, ask, form, read, flow, agent, work, knowledge, index and database. That is the whole list, and there is no planner among them — Plan and Execute is composition.

Edges#

A plain edge goes from one node to the next. A conditional edge reads a channel and chooses, with routes mapping a value to a target and limits capping how many times a route may be taken — which is how a loop goes round and how it stops.

Requirements#

requires is what the flow needs from whatever deploys it, and the division inside it is deliberate. services and settings carry prose. packages names npm dependencies. mcp is the one that is declared rather than described: the server's name and the tools this flow may call, and nothing about transport, address, command or credential, which are the deployment's.

All three arrive on the same object at run time, so a name may not be two of them at once — a handler reading services.crm has to know which was meant.

Error handling#

What the engine throws#

What a flow can say about failure#

How a failure is categorised at run time#

Separately from the class, every failure is filed under one of these, and the category goes on the journal entry and the run's exit event:

llm · tool · timeout · agent · delegation · validation · trigger · runtime · unknown

From the error's class, its code, and which call it came out of — never from its message, so the wording can be improved without moving anybody's counts. Deploy and monitor has the reasoning, including why delegation is kept apart from agent.

Version compatibility#

A flow declares a version and gets exactly that version's features. Every version from 0.1 still compiles, and a flow at 0.12 is refused the things 0.13 added rather than being quietly upgraded. So the question this table answers is: what may a flow at version N declare? — everything listed at N and every row above it.

All 43 features, grouped by the version that introduced them — read out of the compiler's own FEATURE_VERSIONS when this page was built, not transcribed. The current language version is 0.33.

The subject guides#

Longer-form than the reference and shorter than a tutorial: one per subject, each rendered from the product's own documentation.

• Writing a flow — The language from the inside: channels, nodes, edges and what the compiler refuses.
  rendered from LGFlow/docs/guides/writing-a-flow.md
• Bringing the three up — What to start, in what order, and the two traps that cost an evening.
  rendered from LGFlow/docs/guides/bringing-it-up.md
• Deployment — What the Studio writes, what it vendors, and how the folder becomes an image.
  rendered from LGFlow/docs/guides/deployment.md
• Running agents — Starting, stopping, and what a running agent is doing when nobody is asking it anything.
  rendered from LGFlow/docs/guides/running-agents.md
• Monitoring — What the board knows, how it learns it, and what it will not store.
  rendered from LGFlow/docs/guides/monitoring.md
• What a run shows — Reading a run: the tree, the journal, and the four questions kept apart.
  rendered from LGFlow/docs/guides/what-a-run-shows.md
• Triggers — A schedule, an event or a webhook — what starts an agent when nobody is talking to it.
  rendered from LGFlow/docs/guides/triggers.md
• Subflows — One flow running another as a single step.
  rendered from LGFlow/docs/guides/subflows.md
• Multi-agent — Agents that call other agents, and what that costs.
  rendered from LGFlow/docs/guides/multi-agent.md
• Human in the loop — The points where an agent waits for a person, and who that person is.
  rendered from LGFlow/docs/guides/human-in-the-loop.md
• Testing — Scenarios over a flow, and what a test can and cannot tell you.
  rendered from LGFlow/docs/guides/testing.md
• Evaluating — Scored evaluations with a judge, and reading the score honestly.
  rendered from LGFlow/docs/guides/evaluating.md
• Worked examples — The example flows in the repository, and what each one demonstrates.
  rendered from LGFlow/docs/guides/worked-examples.md