The Hyperlambda Generator: One Sentence In, a Verified Backend Tool Out

Not text to code. Text to a verified execution tree.

Hyperlambda is not text that gets executed. It is an AST: a tree where every executable node is the name of a function the runtime knows. The generator is a model fine-tuned on that language, and the runtime sits between the model and your server with three locks.

One sentence in, one live agent tool out

This ran on the cloudlet serving this page. The generator reports its own execution time: 3.03 seconds from the sentence to a live, typed, documented tool over a SQLite table. The last panel is a public endpoint you can call right now, and the full measured ledger, failed first attempt included, is in From Prompt to MCP Tool in 5 Seconds.

// Returns the daily trend of anonymous carbon footprint submissions, one entry per day [...]
.arguments
   days:int
validators.default:x:@.arguments
   days:int:7
data.connect:billionair
   data.select:"select date(created) as day, count(*) as submissions, avg(total_kg) as average_total_kg from footprints where created >= date('now', '-' || @days || ' day') and total_kg > 0 group by day order by day desc"
      days:x:@.arguments/*/days
   return-nodes:x:@data.select/*

$ curl "https://hyperlambda.dev/magic/modules/mcp-demo/footprint-trend?days=365"
[{"day":"2026-09-02","submissions":2,"average_total_kg":8150.0},
 {"day":"2026-09-01","submissions":1,"average_total_kg":13400.0}, ...]

The tool that makes tools

Connect an agent to a cloudlet over MCP and the generator is in its tool list. When the agent hits a capability that does not exist, it describes it in a sentence, hands the sentence to the generator, invokes the result, and carries on with the conversation. The tool persists, so tomorrow's agent is more capable than today's. That is the whole argument of AI Agent Builders, and it only works because the three locks above live in the runtime, not in the prompt. The measured version, a complete role-secured CRM in one conversation, is in the CRM ledger.

The generator sees nothing but your sentence

It cannot see your database, your files, or the conversation you are having. The sentence is the entire specification, and it survives as the documentation your agent reads. The model was trained on hundreds of thousands of Hyperlambda snippets whose comments all read like docstrings, so a prompt that reads like one lands inside the training distribution. A prompt that reads like chat does not.

1. Lead with what it does and when to use it. That sentence is what a model reads when deciding whether to call the tool.
2. Name every input, with its type and default. "Takes days, an integer, defaulting to 7." Hyperlambda types become JSON Schema types for free.
3. Name the database, the tables, the columns, the paths, the URLs. A fact that is not in the sentence does not exist. "Some data from a database" produces garbage.
4. State the output shape. "A JSON array where each object has day, submissions and average_total_kg." A bare "return the rows" frequently returns nothing.
5. One task per generation. Fetch, then transform, then send, as separate tools. Multi-step epics degrade output.
6. Put implementation notes last. They are for the generator, not for the agent that reads the description afterwards.

The honest edge: verified does not mean correct. The verifier proves every instruction exists; it does not prove the code does what you meant. The first generation in the worked example above compiled, verified, saved, and threw a 500 when invoked. The fix was one clause in the prompt and a 1.83-second regeneration. Invoke, read the response, regenerate. Hand-editing is not the workflow, and does not need to be.