← All notes
Architecture

Tools are plugins, not special cases

The moment a runtime knows the name of a tool, every new tool becomes a change to the runtime.

The easy way to give agents a web-search capability is to implement web search in the runtime and expose it. Then someone needs a database query, so that goes in too. Within a few months the runtime is a pile of integrations and adding a capability means editing it.

Norien never hardcodes a tool. A tool is a published record with a JSON Schema for its input, a JSON Schema for its output, a runtime, its permissions, and the environment it needs. The supervisor knows the protocol, not the tools.

One protocol

stdin   { "input": { … }, "context": { … } }
stdout  { "output": { … } }   or   { "error": { … } }
stderr  logs

That is the whole contract for a node or python tool. An http tool declares a URL with placeholders instead, and the runtime substitutes and calls it — from the agent side the two are indistinguishable.

Storing the schemas verbatim rather than reinterpreting them has a second payoff: they are already valid JSON Schema, which is what a Model Context Protocol server expects, so that compatibility is a translation layer rather than a rewrite.