ADF

Export is immediate (the agent is one .adf file; copying it and using Open is documented), but restoring a working agent on another machine takes several documented steps: import the owner seed phrase to unlock sealed keys, re-add a model provider key (app-level keys are not in the file), re-register app-level MCP servers, then review and accept the file. One shortfall (restore is not a single action).

• README highlights
• Security and identity guide (import identity)
• Settings guide (key-less provider copy)
• MCP integration (register missing servers)
• ADF spec: not guaranteed to transfer

The spec places config, instructions, memory, loops, timers, triggers, lambdas, files, messages, audit, logs, sealed identity keys and per-agent credentials in the .adf file; the project holds nothing. Items outside the file (app-level provider keys, app-scoped MCP credentials, WhatsApp session directory, runtime settings) can be re-linked by the owner without any ADF-registered client (MCP OAuth uses dynamic client registration; subscriptions use OpenAI/xAI client ids). A customised global base prompt is an app setting and does not travel; recorded, not counted, because the default install uses the shipped prompt.

• ADF spec: one file, one agent
• ADF spec: not guaranteed to transfer
• MCP HTTP OAuth design (DCR, sealed tokens)
• Settings guide (per-agent keys in adf_identity)

The runtime is MIT-licensed with no licence check, account or ADF-run relay; the only ADF-project endpoints (GitHub update check, MCP registry, skill catalog, online docs) are optional, have off switches or bundled fallbacks, and are not needed to start or act. Mesh uses LAN, tailnet or owner-chosen addresses. Desk grade; a provider-blocked run is required at certification.

• LICENSE
• Network traffic
• App updater
• ALF spec relays

Tool calling is the documented minimum and local open-weight models (Ollama, LM Studio, vLLM, llama.cpp) are first-class provider options; triggers, timers, lambdas and middleware run in the runtime. However, video input is implemented by injecting OpenAI-format video_url parts and is documented only for hosted providers (OpenRouter, Gemini), and no test against a local model is published, so under G12 at least one capability is not shown to survive a local model.

• Settings guide: model requirement
• Studio docs: media input
• ADF spec: tool calling requirement

State is local-first: the agent is a SQLite file on the owner's disk with no ADF account or hosted copy, so no termination, ban or shutdown by the project can remove access to it.

• Capabilities
• README

The whole agent is a SQLite file whose protected schema (schema v32) is specified table by table in the public spec; logic (lambdas, skills, hooks) is stored as source files; adf_audit blobs are documented Brotli-compressed JSON; secrets are sealed to the owner's seed-derived key and a per-install runtime key in the OS keychain. Minor gaps recorded: runtime_* meta keys are declared opaque (one integer cursor today) and the turn-checkpoint JSON shape is undocumented.

• ADF spec: protected schema
• ADF spec: runtime_* keys
• ADF spec: audit blob
• ADF spec: envelope unlock order
• Database schema version

The spec requires and the executor implements recording every runtime-authored prompt text (system prompt snapshots, dynamic instructions, compaction summaries, loop_inject reminders) as rows in adf_loop; model id is stored per assistant row, tools and permissions in adf_config, and inherited app settings in an adf_effective_runtime snapshot. Edge gaps recorded, not counted: the snapshot omits side-loop and model_invoke model overrides (which are in the file config), and an owner-authored pre-LLM hook's rewritten request is not stored.

• ADF spec 1.5 No Secrets in Context
• Agent executor context injection
• Effective runtime config

The project operates no service that receives agent content: crash upload is disabled, there is no telemetry SDK, and the update check sends a fixed staging id shared by all installs. The provider holds nothing (local operation).

• Crash reporter config
• Shared staging id
• Network traffic

Source shows no paid placement: the MCP registry has no sponsor fields and no ADF-hosted model is offered. The only first-party preferences (base prompt pointing at ADF docs and the first-party skill catalog, which is the default catalog entry) are disclosed in NETWORK.md and the recorded system prompt and can be removed or replaced (Settings, include_base_prompt/bare_prompt). No binding no-steering commitment exists; pass rests on source.

• Default skills prompt section
• Network traffic: skill catalog
• ADF spec: bare_prompt

The record spans adf_loop, adf_logs and adf_audit. Tool calls made from code (timers, triggers, lambdas, sys_code) are logged only on rejection or error, not on success; log writes swallow errors (catch non-fatal) and failed loop writes go only to the console and a memory buffer; adf_logs is a ring buffer trimmed to 10,000 rows by default and error messages are truncated. Three shortfalls.

• adf-call-handler best-effort log
• Lambda completion log
• LOGGING_DEFAULTS max_rows
• Log trimming
• Loop write fallback

The record tables carry no hash, chain or signature, and no verifier ships. The sealed-epochs design is marked 'deferred. Not scheduled', and the spec notes the logs 'can be edited by whoever holds the file'.

• Sealed epochs design status
• Record table schemas

By default the agent cannot write adf_* tables (db_execute disabled and refuses adf_*; db_query is read-only; loop_clear and msg_delete disabled; sys_update_config for logging/audit is approval-gated; deleted loops are always archived). But sys_code/sys_lambda (on by default) run in a Node vm worker the docs say 'does not provide hard isolation', and the agent can evict adf_logs rows by flooding the 10,000-row ring buffer through normal calls.

• db_execute adf_ guard
• Default tools
• Security architecture: sandbox
• sys_lambda log row

All source is MIT with open-source dependencies and releases are built in GitHub Actions, but the default Studio installers have no reproducible build, build attestation or provenance; only code signing and notarisation (the npm CLI, not the graded offering, gets npm provenance). A prebuilt resources/wasm/coreutils.wasm is committed without a build recipe.

• Release workflow
• Releasing
• electron-builder config
• LICENSE

Agent and owner identities are did:key Ed25519, needing no resolver; the owner root is a locally generated 12-word BIP-39 seed recoverable on any machine without the provider, agent keys are sealed in the file and can be regenerated, and recipients verify signed ALF messages directly from the DID. Recorded caveats: no signed rotation attestation yet, and channel (Slack, email, etc.) actions are not DID-signed.

• did:key derivation
• Mnemonic identity
• Security and identity guide
• ALF spec did:key
• Identity spec rotation

The loop transcript shows the agent's own tool calls, a config.changed event lists changed keys (in memory only, no values or author), and adf_audit keeps cleared loop segments by default; there is no versioning, attribution of owner or update changes, or restore for config, instructions, memory files, tools or model.

• Umbilical events: config.changed
• Umbilical is in-memory
• Memory management: audit defaults
• Sealed epochs (deferred)

The base prompt, tool-instruction sections and compaction prompt are editable in Settings and agents can suppress runtime prompt layers (bare_prompt). But a settings migration run at every start re-appends the {{soul.md}}/{{mind.md}} sections to a custom base prompt and the skills-catalog placeholder to a custom skills section (contrary to the settings guide), and built-in tool descriptions and runtime nudges are fixed in code.

• Soul/mind migrations
• Migrations run at startup
• Settings guide claim
• Hard-coded nudges

Files, mind.md, the document and meta keys are viewable, editable and deletable in the UI, but the persistent loop (including compaction summaries reused across restarts) can only be cleared whole, and local_* tables the agent uses for contacts and structured memory can be listed and dropped but not edited row by row.

• Local table IPC channels
• Memory management
• Agent memory guide
• Default prompt: local_* for memory

Owners can connect any MCP server or add lambdas without review, and every built-in tool has an enable switch in the agent config; no always-on tool was found.

• Capabilities: MCP
• Default tools

Many protections are configurable (local-fetch guard, sandbox network, limits, logging and audit, host access), but some are hard-coded: cloud-metadata/link-local and daemon-port fetch blocks, a 300 s sandbox ceiling, the non-optional vm sandbox for code, and a forced idle after 4 consecutive tool-less replies.

• SSRF guard
• Sandbox max timeout
• Forced idle

App updates are opt-in: the app checks but downloads nothing until the owner clicks, and checks can be disabled, so the owner can stay on a version indefinitely; new agents have no preset model, and no remote flags were found. Recorded caveats: live catalogs from the repo's main branch (MCP registry on by default; skill catalog referenced by the default prompt) can change without a release but can be switched off or removed, and in-app notice is a release-notes link.

• App updater
• Settings defaults
• Agent defaults (empty model)
• MCP registry fetch

Instruction sources are limited per DID and per sender, file tools are confined to the agent file, and the agent cannot change locked or restricted fields; spend is treated as met under G11 (no payment capability). But messages to channel adapters (email, Telegram, etc.) bypass outbox middleware and have no per-recipient limit, and egress by MCP servers, WebSockets and containers is not covered by per-domain limits (per-domain limits for sys_fetch require owner-written middleware code). Two shortfalls.

• Adapter routing before middleware
• Outbox middleware
• Network traffic: owner controls
• Middleware guide

Any tool, including MCP tools and code methods, can be marked restricted; model calls create tasks resolved only by the owner or owner-authorised code, unauthorised code calling a restricted tool is blocked, and inner loops strip gated tools.

• Tools guide: restricted
• Code call gate
• Authorized code

A single status-bar control ('Stop all agents and disable mesh') runs an emergency teardown that closes the runtime gate, aborts executors, stops timers and inner loops and tears down mesh, MCP, adapters, sandboxes and containers; restart needs an owner action. There is no provider-side work. Desk grade; confirm hands-on.

• Status bar stop
• Emergency stop handler

No telemetry SDK and crash upload is off; the default-on flows (update check with a shared non-identifying id, provider checks to owner-chosen providers, catalog GETs with no content) are disclosed with off switches, and there is no hosted service, so no training, staff access or data terms apply.

• Network traffic
• Settings defaults
• Crash reporter

The per-agent Identity panel lists credentials with reveal and delete, and provider keys and subscriptions are managed in Settings; but MCP OAuth sign-out clears only the app-level copy while agent-sealed copies remain usable, daemon access grants have no UI and revoke only after the file is re-opened, and some credentials (WhatsApp session, runtime keys) are not listed.

• Security and identity: identity panel
• MCP OAuth sign-out
• Daemon grants

Deleting an agent in the sidebar is one confirmed action that removes the .adf file and its WAL/SHM files, with no provider-side copies; but the adapter session directory, container workspace, app-level MCP/provider credentials and any .bak copies survive, so full deletion needs several steps and completion is not confirmed.

• Delete dialog
• Delete handler
• Backup files