An agent surface for AiMANAC.

Bombadil is the companion app for running an agent runtime alongside AiMANAC. You ask AiMANAC to do something agent-shaped — read a skill, remember a fact, run a flow — and the work lands on the Bombadil device. Today your backend passes a structured work order to the phone; the next AiMANAC update tightens that into a live session so results feel instant.

Bombadil holds an agent runtime — skills, memory, providers, sessions, flows. AiMANAC stays the main console; Bombadil handles the things you'd otherwise run from a desktop agent. The tool list is grouped into sixteen families with twenty-eight individual actions; each one is policy-gated, audited, and asks for re-checks before it writes anything sensitive.

Eight actions are Owner-only; the rest can run for any signed-in principal in v1. Owner-only coverage and “never log this field” rules are enforced in automated tests so the shipped app cannot silently widen access.

Today. When AiMANAC dispatches a Bombadil tool, the backend hands off a structured envelope and tells the caller "waiting on the device." That envelope is the work order. If Bombadil is installed and paired, it picks the order up and runs it. If it's not, you'll see the envelope but no result.

After the next AiMANAC update. The backend will hand the work directly to the Bombadil device over an open session and replay the result back to AiMANAC. Same tool calls, no envelope hand-off — the user experience changes from "the agent will get to it" to "the agent did it."

The envelope shape below matches the frozen v1 contract in bombadil-rs (docs/RELAY_ENVELOPE_V1.md): the payload lives under bombadilRelay, and tool is always the helm_bombadil_* name HELM dispatched — not a shortened alias. Customers can still read this as “AiMANAC queued work on the phone.”

v1.1+ (reserved): intentId and inputDigest may appear on the relay object once the bridge assigns correlation / digest audit — they are not required in v1.

Launcher. AiMANAC’s MCP cockpit includes an “Open Bombadil” row. If the app isn’t installed, AiMANAC shows an honest fallback sheet that explains relay vs. future live execution, trust expectations, and version pairing.

Trust. Registering a custom URL scheme does not prove who published the app. Only builds signed by the same Everplay team as AiMANAC are treated as integrated; the fallback sheet spells that out so a random store clone cannot impersonate the lane.

Version coupling. AiMANAC 312 and newer speak relay contract version: 1 with the matching Bombadil build. If the pair disagrees, execution stops instead of returning a guessed answer.

Audit hygiene. Dispatch logs store redacted request bodies — depth-limited JSON with an allowlist for fields that must never hit the database in clear text (API keys, tokens, and similar secrets).

1. Have AiMANAC ≥ 312 installed. Earlier builds do not speak the relay contract.
2. Wait for App Store registration. Bombadil is in early build; the public listing is still pending, so AiMANAC keeps a placeholder ID until Apple assigns the real one.
3. Install Bombadil when listed. Separate App Store SKU, planned $1 one-time.
4. Open AiMANAC → MCP cockpit → Bombadil row. The relay status prints right under the launcher so you see the contract before tapping.
5. Tap "Open Bombadil". First launch reads the shared trust-mesh keychain. From there, dispatches from AiMANAC return relay envelopes that the device executes.

On-device agent only. No bombadil-server image — deploy aimanac-server when you need HELM MCP and relay routing (/setup/llm/).

Bombadil is the on-device relay agent. Discord is where operators share relay envelope patterns, debug skill registration, and ask about the AiMANAC pairing contract.

Direct contact until the invite link lands: info@llmtech.net.

• AiMANAC baseRequired ≥ build 312 for the relay contract.
• SatcheliSibling MCP registry — different signal, same trust mesh.
• MCP SymposiumAdjacent surface — Bombadil tools register as MCP entries.
• Self-Deploy SpecThe backend you'll dispatch through.