Registry
Source: core/registry/registry.gleam, core/registry/builder.gleam
The tool registry manages tool discovery and dispatch. It follows the same split pattern as the loop subsystem: a pure dispatch module with zero external imports, and a composition root builder that wires concrete tool plugins.
Modules
registry.gleam
Pure dispatch functions. No imports from services/ or plugins/. Operates on List(Tool) -- a list of Tool records (from core/tool/tool.gleam).
Key functions:
find_in(tools, name)-- looks up a tool by name in a custom tool list. ReturnsResult(Tool, String).schemas_from(tools)-- extracts JSON schemas from a tool list for API registration.to_definitions_from(tools)-- converts a tool list toList(ToolDefinition)for the completions API.dispatch_from(tools, name, args_json)-- dispatches a named tool call with JSON arguments. Returns aToolResult.
builder.gleam
Blessed Violator #3. Wires all 8 tool plugin modules with their behaviour dependencies (Guardrail, Logger, DndChecker, SessionStore, MemoryStore). This is the only module in core/ that imports from plugins/.
Key functions:
all_tools(conn, user_key)-- returns the fully-wiredList(Tool)with all 8 tool modules: bash, web, memory, session_search, code, cron, telegram/send_message, and browser (plus sub-tools).make_memory_tool_fn()-- returns afn(Connection, String) -> Toolfactory used by the reflection hook to spawn background memory consolidation with its own DB connection.
The Split Pattern
registry.gleam → pure dispatch (find, filter, map over Tool lists)
builder.gleam → composition root (imports tool plugins, wires their behaviours)This is the same pattern as loop (orchestrator vs. runner). The pure half is testable without any concrete implementations; the builder half is the only place that knows which tools exist.
Related Pages
- Loop -- The orchestrator/runner that dispatches tools via the registry
- Tool -- The
Tooltype definition and execution engine - Blessed Violators -- Why builder.gleam can import from plugins/