Last time I showed how an agent discovers the available APIs at runtime using the discover verb. But one question remains unanswered: how does a cold-start agent that has never seen the language before discover discovery? You need to know the language in order to write a program, so how is this chicken-and-egg problem solved?
It turns out that there exists, in fact, one particular program an agent can submit without either knowing or guessing the grammar.
The empty program
When a Neander runtime like Grotto receives the empty program, it is not treated as a syntax error but as valid input. The specification requires the runtime to answer with a special response envelope that contains the Neander Reference document explaining the language, plus the runtime's current configuration.
{
"success": true,
"result": "# The Neander Reference...",
"meta": {
"neanderVersion": 1,
"thalerBudget": 500,
"memoryBudgetKb": 1024,
"maxDurationMs": 30000,
"perCallTimeoutMs": 5000,
"maxProgramSizeBytes": 262144,
"maxNestingDepth": 128,
"maxRepeatLimit": 10000
}
}
This is the entire bootstrap mechanism. One round-trip, and the agent now knows about the Neander language and every limit the runtime enforces. The rule that everything in Neander is a program extends even to requesting the manual for how to write a program.
It is worth mentioning that Grotto optimizes the request processing in this special case. The empty program never spawns a worker that lexes or parses it. The dispatcher immediately returns a prepared Reference Response, which makes bootstrapping an agent a very cheap task.
A little nudge to break the ice
For an embedding application, out-of-the-box bootstrapping and discovery are real convenience benefits. All that it still needs to take care of itself is to register its APIs with the runtime and to connect agents to itself.
The latter must in some shape or form, depending on the underlying technology, inform the agent that it now has access to a submitProgram operation. And ideally, this memo also contains a little nudge to break the ice, namely: Send the empty program first to learn about the language.
A little kindness goes a long way. Agents are smart, but not (yet) mind readers.
Two documents, separate audiences
Now that the Neander Reference is introduced, it is worth stressing that there exist, in fact, two documents describing Neander, and this split is deliberate because they address two very different audiences.
The Reference is served by the runtime to agents who want to write programs to call the APIs of the embedding application. It is example-driven and has three parts: a get-started, a cookbook of copy-and-ship recipes, and the actual language reference for lookup. It answers the how question, but does not explain why the language is the way it is. This is the job of the other document.
The specification is the normative, precise, and exhaustive definition of the language. It informs coding agents who plan and execute a runtime implementation as well as humans who evaluate the technology to assess whether embedding it into their own systems is a viable option. It also serves as the single source of truth for generating or updating the Reference. The two documents are supposed to always be in sync, but if push comes to shove, the specification wins.
Next from the Grotto
We have now covered bootstrapping and discovery at the beginning of a dutiful friendship between the agent and the API. And so it is time to shift our focus to what comes next: The End. Or rather, the question: is there an ending?
We all know that programs can run forever. And thanks to Mr. Turing, we know that we can never know for sure.
But Neander lives up to its namesake's reputation and proves to be way too predictable for that.
In the meantime, read the Neander spec, embed Grotto in your own app, and let me know how the cold start goes.
Top comments (0)