Module reference
Each agent-facing module has a page below. To enable a module in an
app, add it under tools.modules.<id> in the YAML; the
language reference documents the shape
of that block.
context_builder is auto-loaded on every app and is not declared
explicitly for ordinary apps.
By category
Core I/O
| Module | One-liner |
|---|---|
| filesystem | read, write, edit, multi_edit, glob, grep, delete. |
| bash | Run shell commands from the session workdir. |
| http | HTTP requests. |
| web | Web search + fetch (extract is a fetch parameter, not a separate tool). |
| browser | Drive a real browser session (open / act / read). |
| database | Connect to SQL databases (sqlite, postgres, mysql). |
Intelligence and orchestration
| Module | One-liner |
|---|---|
| memory | Cognitive memory: goal, todos, facts (system catalog module). |
| agent_spawn | Spawn sub-agents (modes via one Agent tool). |
| behavior | Runtime rule engine: pre/post-tool checks, semantic classifier. |
| context_builder | Auto-loaded. Tool index, discovery meta-tools, prompt assembly. |
| scheduler | Recurring session wake-up (schedule → digitorn-background). |
| llm_provider | LLM call path note (not a tools.modules package like bash/web). |
Knowledge and retrieval
| Module | One-liner |
|---|---|
| rag | Hybrid retrieval over knowledge bases (BM25 + dense + Text2SQL). |
| index_module | Token-aware code indexing (index module id). |
UI / preview surfaces
| Module | One-liner |
|---|---|
| workspace | Git-backed change tracking (baseline / diff / approve). File I/O: see filesystem. |
| preview | Inspect and drive the live app preview pane. |
| previewshot | Headless screenshot of a built preview (gallery thumbs). |
Built previews are also served over HTTP under
the session preview URL served by Digitorn. There is no
web_preview tool module and no PreviewProxy / PreviewPublish
agent tools in this build (see the stub page
web_preview for the redirect note).
Widgets live under ui.widgets in the client manifest, not as a
Go tool module.
Integration
| Module | One-liner |
|---|---|
| mcp | Connect to external MCP servers. |
| channels | Bidirectional I/O: webhook, cron, rss, telegram, discord, whatsapp, pieces. |
| pieces | Activepieces connectors as agent tools. |
| lsp | Language Server Protocol diagnostics (notify_change, diagnostics). |
| cron_native | Stub package (no tools). Use scheduler or channels / automations. |
Registered in digitornd: bash, browser, database,
filesystem, http, lsp, mcp, pieces, preview,
previewshot, rag, scheduler, web, workspace.
System catalog (not blank-imported packages): memory,
agent_spawn, context_builder, channels (manifest for
background).
Stub packages (empty / non-functional as tool modules today):
cron_native, cron, memory package dir, agent_spawn package
dir, context_builder package dir, channels package dir,
behavior package dir, index package dir. Behavior rules still
run in internal/runtime/behavior; the empty internal/modules/behavior
package is not the engine.
Not shipped as tool modules: queue, vector, dev_tools,
web_preview, widget.
YAML aliases
| Written in YAML | Becomes at compile time |
|---|---|
tools.modules.workspace (legacy file I/O intent) | filesystem |
shell (legacy) | bash |
The Git change-tracking module is still registered as workspace
in the runtime; do not confuse it with the filesystem alias.
Tool naming
Modules expose actions via a fully-qualified name (FQN) like
bash.run or filesystem.write. The runtime promotes a curated
subset to short PascalCase names (Bash, Write, Edit, Grep, Glob, Agent, Remember, ...) so the LLM sees short tool names
in the chat UI. When restricting per-agent module access
(Agents - Per-agent module access),
list the action names in their FQN suffix form
({ bash: [run] }, not { bash: [Bash] }).
How modules are exposed
Modules are the runtime's built-in capability set. Each module exposes its own surface (config, params, constraints) that you wire up from YAML.