Glossary
The vocabulary of an in-browser agent — from the virtual filesystem to capability-gated skills. Each term links to the page where it lives.
Dornick's signature abstraction. Instead of stuffing everything into one system prompt, the model sees the live page as a navigable filesystem — /page (the DOM), /conversation (the message log), /user (dropped files), /skills (installed capabilities), and /host (anything you mount). The agent reads only what it needs, when it needs it.
Learn more →The agentic loop at Dornick's core. The model has six tools — tree, read, write, ls, grep, and complete — and runs a real plan-act-observe cycle rather than a single-shot chat completion.
Learn more →A veto-and-transform callback fired at one of 19 lifecycle events (before/after a field fill, tool call, message, handoff, and more). Hooks can rewrite a value, block an action, or trigger side effects. Defined programmatically or as declarative JSON.
Learn more →A capability-gated bundle of behaviour the agent can invoke — Dornick ships eight (resume-intake, kyc-id-check, payment, signature, consent, wizard, booking, address). Skills package the prompt, tools, and guardrails for a common flow.
Learn more →Passing control from one agent to a specialist sub-agent. An exit-intent trigger can summon a rescue agent; a topic switch can route to an expert. State moves through the shared virtual filesystem.
Learn more →The W3C draft for how a web page exposes typed, callable tools to AI agents, through document.modelContext. Distinct from MCP: no network hop, and the tools are the page's own JavaScript. Dornick speaks both sides of it — it calls the page's tools, and publishes its own back.
Learn more →The browser API WebMCP defines. Pages call registerTool() on it to publish tools; agents call getTools() and executeTool() to use them. Canonical since May 2026 — the deprecated navigator.modelContext alias still resolves to the same object in Chrome.
Learn more →Chrome's mechanism for shipping an experimental API to real users without a browser flag. WebMCP's runs from Chrome 149 to 156. It matters because native document.modelContext is reachable by the browser's own agent, while a polyfilled one is not.
Learn more →An open protocol for connecting agents to tools and data. Dornick is both an MCP client — mount remote MCP servers under /host — and an MCP server, exposing your page as a tool surface to hosts like Claude Desktop.
Learn more →An opt-in companion package that reads a file format entirely in the browser — PDF, DOCX, XLSX, ZIP, OCR, Whisper. The file never leaves the page; heavy dependencies lazy-load only when a parser is used.
Learn more →Dornick runs client-side with your own LLM API key. There is no Dornick backend. For production, the ~1 KB @dornick/server proxy keeps the key server-side while still streaming responses over SSE.
Learn more →Dornick's chat overlay renders inside a Shadow DOM, so its styles are fully isolated from — and can't be broken by — your page's CSS. Framework-agnostic and drop-in.
Learn more →The layer that carries requests to a model. Dornick supports a browser transport (BYOK, direct fetch) and a proxy transport (via @dornick/server). Same agent code; swap the transport to change how the key is handled.
Learn more →A VfsMountHandler binds a virtual path to a real source. Writes to /page/form/fields/<name>.json are intercepted and dispatched to the DOM; reads from a mounted /host path hit whatever data source you wired up.
Learn more →The declarative object (or data-dornick-config JSON) that tells Dornick what to collect: the persona, the target form or element, and the dataPoints — field names paired with the questions the agent should ask.
Learn more →Install Dornick, paste a config, and your form turns into an agent that fills its own inputs.