ADF

In Studio the owner saves the agent as one .adf file (Share, then Save copy, or drag it out) and restores it on another machine by opening or dragging in that file. Provider keys, channel and MCP credentials can be stored encrypted in the file, so the copy runs with no further setup. Shared copies deliberately leave out the owner's signing identity, which moves only when the owner migrates their own agent.

• Settings: per-agent providers and credentials
• Security and identity

The single `.adf` file carries config, primary document and mind.md, files and code, loop history, inbox/outbox, timers, tasks, logs, audit snapshots, the sealed Ed25519 identity key and sealed credentials, so everything that defines the agent leaves with it. Installed MCP packages, container images and app-level provider keys belong to the runtime and are not included.

• ADF spec §16 Portability
• ADF spec §8.2 Identity Store

The MIT-licensed runtime runs as the Electron Studio, a headless daemon or a CLI, and accepts any OpenAI-compatible endpoint such as Ollama or LM Studio, so no Rawl server is required.

• LICENSE
• ADF spec §5.16 Provider Overrides
• docs/daemon/cli.md

Peers can verify continuity without Rawl: the agent's did:key comes from an Ed25519 key that travels sealed inside the file, so when the same owner imports their mnemonic on a new machine the agent keeps its DID and signing key. A file opened by a different owner must be re-keyed to a new DID.

• ADF spec §8.1 Identity Model
• docs/design/ADF_IDENTITY_SPEC_v0.1.md

No license check or remote enablement flag was found in the source. The packaged app checks GitHub Releases for updates but downloads only when the user clicks, and unpackaged builds never check.

• src/main/services/app-updater.service.ts

Tools, triggers, timers, messaging, memory and lambdas are executed by the runtime and stored in the file, and no provider-native tools are used. Swapping to another provider, including a local OpenAI-compatible model with tool calling, keeps the same capability set.

• ADF spec §1.2 Spec Stores, Runtime Executes
• src/main/providers/provider-factory.ts

The `.adf` file is a SQLite 3 database with a published schema and a per-column data dictionary, readable with sqlite3 or any SQLite client.

• ADF spec §3 Storage Format

The runtime writes each new system prompt and every dynamic instruction into `adf_loop` as `[Context: ...]` entries. The `bare_prompt` flag removes all runtime-authored prompt text.

• ADF spec §1.5 No Secrets in Context
• src/main/runtime/agent-executor.ts

All agent state is in the local file. Rawl runs no hosted service, and the only Rawl-controlled endpoints the app contacts are GitHub-hosted update and registry files, which carry no owner data.

• ADF spec §16 Portability
• src/main/services/mcp-registry-fetch.service.ts

LLM-loop tool calls and results are kept in `adf_loop`, archived to `adf_audit` on compaction, and leave with the file. Lambda, timer and API activity outside the loop is kept only in `adf_logs`, a ring buffer capped at 10,000 rows by default, and message and file deletions are not recorded by default, so the history is incomplete.

• ADF spec §13 Memory, Audit, Tasks, and Logs
• src/shared/types/adf-v02.types.ts (AUDIT_DEFAULTS)

Skills, lambdas, middleware and API handlers are stored as TypeScript/JavaScript and Markdown source in `adf_files`, and the runtime is open source.

• ADF spec §9 Code Execution and Lambdas

No advertising, sponsorship or ranking channel was found. The curated MCP and agent registries fetched from the repo are catalogs shown to the owner in the UI, not model context.

• src/main/services/mcp-registry-fetch.service.ts
• src/main/services/agent-registry.service.ts

Each loop entry, including tool calls, is written to `adf_loop` as it happens, and loop clears and compactions archive rows in the same transaction as the delete. Actions still proceed when recording fails: a failed loop write is buffered for retry while the turn continues, and hot-path lambda actions are recorded only in the capped log table.

• src/main/adf/adf-workspace.ts
• src/main/runtime/agent-session.ts

Edits to or deletions from `adf_loop`, `adf_audit` or `adf_logs` cannot be detected, because rows carry no hashes, chaining or signatures, and a tamper-evident event log is deferred to a design document. Signed ALF messages let a counterparty check a message's content but reveal neither deletions nor changes to other actions.

• ADF spec §3.2 Protected Schema
• docs/design/sealed-epochs.md

The agent cannot alter its own record: `db_execute` rejects any statement that touches `adf_` tables, and no tool mutates `adf_audit`. The exception is host compute, which needs both an agent flag and an owner-only setting and gives direct access to the `.adf` file.

• src/main/tools/built-in/db-execute.tool.ts
• ADF spec §13.3 Audit
• docs/guides/compute.md

Loop, inbox, outbox, task and log tables are plain SQLite. `adf_audit` blobs are brotli-compressed JSON, readable with sqlite3 plus any brotli decoder.

• ADF spec §3.3 Field Reference

Each ALF message carries a globally unique, signed id recorded as `message_id` in both the sender's `adf_outbox` and the receiver's `adf_inbox`, so the two sides' records of an exchange can be matched. Message deletions are not recorded by default (see T4).

• ALF_SPEC_v0.1.md
• ADF spec §11.2 Inbox and Outbox Statuses

The runtime is MIT-licensed and releases are built in public GitHub Actions from package-lock.json with `npm ci`, then signed. Reproducible builds are not claimed or documented.

• LICENSE
• .github/workflows/release.yml
• RELEASING.md

Agent config is the JSON in `adf_config`, but the running agent also depends on app-level runtime settings outside the file (host access, provider keys, MCP environment). The executor may also carry in-memory config additions that are never persisted.

• ADF spec §15 Spec Boundary
• src/main/runtime/config-freshness.ts

ALF messages are signed by default (security level 1) with the agent's Ed25519 key, which travels sealed in the file, so recipients can verify the sender DID before and after migration. Messages sent through channel adapters such as Telegram or email cannot be verified this way.

• ADF spec §8.5 Message Security
• src/main/crypto/message-crypto.ts

The action record carries no integrity data, so no tool, open or otherwise, can confirm it is unaltered. A verifiable event log is proposed only in a deferred design document.

• docs/design/sealed-epochs.md

All agent state is one SQLite file, so the owner can copy it at any two points and compare the copies with open tools such as `sha256sum` or SQLite's `sqldiff`. No built-in state digest is provided, so the comparison is a manual step.

• ADF spec §16 Portability
• ADF spec §3 Storage Format

Instructions are stored in `adf_config` and owner-editable, and the runtime base prompt can be dropped with `include_base_prompt: false` or `bare_prompt: true`.

• ADF spec §5.1 Top-Level Shape

Memory is stored as `mind.md` and other files in `adf_files`, plus loop and local tables, all of which the owner can edit or delete in Studio or with SQLite.

• docs/guides/memory-management.md
• ADF spec §4 Virtual Filesystem and Metadata

Lambdas, skills and middleware are editable source files inside the agent, and the runtime is MIT-licensed.

• ADF spec §9 Code Execution and Lambdas

The owner can enable, hide or restrict each tool, add any MCP server, and set locked fields that the agent cannot change.

• ADF spec §8.7 Restricted Tools and Methods
• ADF spec §5.17 Locked Fields

Supported providers are Anthropic, OpenAI, OpenRouter, ChatGPT/Grok subscriptions and any OpenAI-compatible endpoint, including local Ollama, LM Studio, vLLM and llama.cpp. Tools remain runtime-side, provided the model supports tool calling.

• docs/guides/settings.md
• src/main/providers/provider-factory.ts

No license key, paid tier or remote feature flag was found in the source.

• LICENSE

Owner-configured outbox and fetch middleware runs in the runtime pipeline before any message is sent or HTTP request is made and can reject it, so any recipient, domain or channel policy the owner writes is enforced below the model. The agent is hard-denied from changing the middleware configuration, middleware must come from owner-authorized files by default, and sandbox code has no direct network access. WebSocket and shell tools (both off by default) and owner-installed MCP servers sit outside this pipeline.

• Custom middleware
• Authorized code execution
• Security architecture

Tools marked `restricted` require owner approval before running from the LLM loop. Approvals are tracked as `adf_tasks` rows, and only the owner or authorized code can resolve them.

• ADF spec §8.7 Restricted Tools and Methods
• src/main/runtime/approval-hub.ts

`abort` immediately cancels the current turn. Setting state to `off` tears down the LLM request, triggers, MCP servers, adapters and sandboxes, and CLI `stop` does this after a 5-second grace period.

• ADF spec §6.1 Agent States
• docs/daemon/cli.md

No analytics or telemetry SDK was found, and content goes only to owner-configured providers and peers. The packaged app checks GitHub Releases hourly with no opt-out, and it fetches the MCP registry from GitHub. No network-inspection verification was performed.

• src/main/services/app-updater.service.ts
• src/main/services/mcp-registry-fetch.service.ts

MCP, channel-adapter and agent secrets are stored in `adf_identity`, AES-256-GCM-sealed to owner and runtime keys, and they travel with the file and can be inspected and deleted in the Identity panel. App-level provider keys and subscription OAuth sessions stay in local OS-keychain storage and do not travel with the file.

• ADF spec §8.2 Identity Store
• docs/guides/security-and-identity.md
• src/main/providers/subscription-token-store.ts

Deleting an agent in Studio stops it and unlinks the `.adf` file and its WAL files, which destroys the private key. Rawl holds no copy, though stale `.bak.*` backups and compute workspaces may remain on the owner's disk.

• src/main/ipc/index.ts (deleteAdfFile)
• src/main/adf/adf-database.ts