Changelog

All notable changes to the kit are listed here, newest first. The format follows Keep a Changelog.

Unreleased — 0.1.0

The first public release. The packages are not on a registry yet; see Installation.

Brain

• @pilotoo/memory-protocol, @pilotoo/memory-core and @pilotoo/memory-server: named memories of three kinds (graph, collection, personal), access by membership and labels, REST routes, a stateless MCP endpoint with six tools and per-memory token grants, PostgreSQL and pgvector stores, Bedrock and OpenAI-compatible adapters, and BrainKnowledgeSource for agents.
• Graph memories resolve names before writing: pages keep every alias, a source’s names are matched against existing pages its audience can read, and doubtful matches become a possible duplicate for an admin. Compilation is transactional, a recompile is a diff, and sources added with an externalId are versioned.
• Facts have a life: retired or superseded, never silently deleted, with a history an admin can show; deleting a source rebuilds what other sources still support, and erase removes everything derived. Facts from sources with the same labels consolidate into one entry.
• Admins curate pages: merge, split, rename, lock, add and edit facts, keep two pages apart, and a Health scan, all with undo. See Curating a memory.
• Personal memories reconcile a new fact with the old ones and answer add, update, delete or noop.
• A memory’s knowledge language: pages in the language of their sources by default, or one fixed per memory; answers follow the question.
• @pilotoo/web-auth: the Google sign-in, signed cookies and identity guard shared by Connect and Brain.
• apps/brain-api with its web app, as a Docker image. See Brain.
• Compiles go to a durable per-memory queue in PostgreSQL, worked by Brain up to four memories at once; a source waiting or running reports pending, a model call gives up after 90 seconds, and a job that throws waits longer before each retry. See the compile queue.
• Connectors: a workflow that adds or removes sources, run on a schedule or by hand with a daily cap, a test run that writes nothing, and Fed by on each memory. Brain links a user’s Pilotoo Connect account so connectors read with the owner’s connections. See Connectors.
• Workflow tools on Brain’s MCP endpoint behind a per-memory connectors grant, and the desktop app reaches Brain with BRAIN_REMOTE_URL and BRAIN_REMOTE_TOKEN as opt-in brain_ tools. See Use it from an agent.
• Citations open the source’s text version at the cited passage, the graph has a documents view, and a source’s text is extracted from PDF and HTML files.
• @pilotoo/web-auth can link an account: a consented personal token for another product, and a bounded sign-in return path.

Server

• @pilotoo/server: a NestJS module, PilotooModule.forRoot, with a Socket.IO streaming gateway, REST routes, PostgreSQL persistence and run replay.
• Agents defined in YAML files, model profiles and providers, agent templates, and tenant agents managed through the API.
• Server tools registered in code, with opt-in tools; subagents and background tasks.
• Skills, attachments (S3 or custom store), scheduled runs, usage reporting and a model gateway.
• Identity through a resolver, AUTH_IDENTITY_URL, or a fixed local identity.

Client

• @pilotoo/chat-core: an environment-agnostic client with session, conversation and agent catalogs, stores and a socket.io transport.
• @pilotoo/chat-protocol: the typed wire protocol, versioned with a major and a minor number.
• Client tools, blocking and one-way, declared per run.

UI

• @pilotoo/ui: DOM chat components (ChatProvider, ChatPanel), settings and design tokens for Tailwind v4.
• @pilotoo/chat-ui: React Native chat components, also rendered on the web.

Voice

• @pilotoo/voice: read-aloud and dictation behind ports, with browser engines.
• @pilotoo/voice-native: a Tauri speech plugin for desktop.

Local backend

• @pilotoo/local-server: the same runtime on SQLite, with no PostgreSQL, for a user’s own machine and the desktop app.

Workflows

• @pilotoo/workflow: a port-wired node graph with validation, an expression language ($input, $trigger, $node, $vars, $item, $index, and ?? fallbacks) and a runtime on LangGraph. See Workflows.
• Node kinds: three triggers (manual, webhook, schedule), set, if, switch, output, approve, http, code, forEach, tool, llm, agent, command on hosts that lend it, and one connection.<tool> kind per connection tool.
• The code node runs in a QuickJS sandbox in a worker thread (@pilotoo/workflow/quickjs) with a timeout, a memory limit and a cap on snippets running at once. The local backend runs it in a terminable worker instead.
• A trigger.schedule node can carry a cron and a time zone; the server keeps the schedule in step on each save.
• Six agent tools: workflow_list, workflow_run, workflow_kinds, workflow_get, workflow_validate and workflow_save. A run answers each node that ran with its port and output.
• The visual builder in @pilotoo/ui/workflows: a searchable node palette grouped by app, Arrange, a multiline code editor, and a run view with an inspector for each node’s input, output, timing and error.

Connections

• @pilotoo/connections-core, @pilotoo/connections-server and @pilotoo/connections-mail: connect external services for agents to use, as a library, over a tools API and MCP, from remote sources, or as the standalone Pilotoo Connect service. See Connections.
• Providers: GitHub, Gmail (read, compose and organise), Email over IMAP and SMTP with a guard on addresses and ports, and Logicpanel Hub.
• Credential types shared by providers, with one OAuth client and one account per type, and credentials made of fields entered in the settings form.
• Include and exclude tool patterns per provider and tenant.
• Custom gateways: a tenant registers a tool gateway that becomes a provider, reached by URL or by a worker that polls Connect. See Custom gateway.
• The desktop app takes connection tools from a remote service with CONNECTIONS_REMOTE_URL and CONNECTIONS_REMOTE_TOKEN.