Help · FAQ · V1.1 · 2026-10-18

AirMemo FAQ

Version 1.1 · 2026-10-18. The questions teams actually ask while evaluating AirMemo, answered from the published pages and the live endpoints. This is the docs FAQ; the short marketing version is at airmemo.com/faq. Every answer states what runs today, anything not offered is marked as such, and what is deliberately not answered is collected under "Known gaps" at the end.

What AirMemo is

Q1. What is AirMemo, in one paragraph?

AirMemo is governed memory for AI coding agents: it delivers your organization's in-force decisions — the current answer on a project, a released policy, a corrected fact — into the session context of the agents your engineers already run, and proves each delivery. It is the layer that decides what an agent is told next; it is not a chatbot, not a model, and not a store of source code. The moving parts: the cloud (api.airmemo.com — queue, governance, audit, receipts), the hook (a small binary that rides each agent's lifecycle events), the MCP server (the same five tools over MCP for any client), and the console (org admin).

Q2. Is this a memory tool — a RAG index over our code?

No. AirMemo is push, not pull: it does not ingest your repository, conversations, or terminal output. It delivers author-written memos and nothing else, at session start or prompt submit — delivery is a queue, not retrieval over your files.

Q3. Who is this for — does it count non-engineers?

Everyone in the org who uses an agent, not just engineers: a seat is one approved hook installation per employee, any agent function, any platform — engineers, marketing, finance, sales, and executives all count, and the ceiling and the bill always match the whole fleet. It is priced per agent per month, not per memo.

Getting started

Both paths are live. Self-serve: sign up at the console (/app), create the organization, mint a bootstrap token, and run the free tier (up to 5 agents); sign-up is enabled on the hosted service — verified live 2026-10-18 (GET https://api.airmemo.com/portal/signup/status → {"enabled":true}). Front desk: for a pilot workspace, SSO, procurement, or self-hosting, start at /talk.

Q5. How do I install the hook — and can we download it today?

Not from a public URL — there is no public download today. The one-line installer and the release artifacts are held until the public release (docs/install-flip-checklist.md §0): the repository they come from is private, and a self-serve organization cannot install the hook yet. If you already have the binary (design-partner builds), an owner mints a one-time enrollment key (Org admin → Rollout → Enrollment key) and machines enroll with airmemo-hook enroll --org <slug> --org-key <key> --platform <name>; fleet tooling uses managed-install (one non-interactive command per machine, idempotent, deterministic exit codes). Platforms: claude, codex, copilot, gemini, cursor, windsurf, opencode. Until you have the binary, use MCP (Q6): the same five tools, no install.

§1.2, §1.6;

Q6. How do I connect an MCP client — and can an agent read the docs without an account?

Point any MCP client at https://api.airmemo.com/mcp with an org API token as the bearer; no install, five tools (whoami, search_context, get_decisions, get_memo, propose_context). Per-client snippets ship for Claude Code, Codex CLI, Cursor, VS Code (Copilot), and Gemini CLI; Windsurf and OpenCode are wired by the installer. A separate anonymous docs arm at /mcp/docs serves list_docs, search_docs, and get_doc over the public corpus — no token, no sign-up.

Q7. What does the installer do to a machine — and can the hook block an agent?

install merges into the platform's config (pre-existing customer hooks are preserved byte-identically), pins the binary by SHA-256 — the hook never self-updates, and a changed hash makes install refuse without --force — needs no administrator rights (user-space config), and uninstall removes exactly what it added. The hook is fail-open by design: when anything goes wrong on the poll path it exits 0 and the agent turn proceeds; a memo may be skipped, but the tool is never blocked. One deliberate exception, opt-in: force-continuation (off by default) lets urgent memos continue a turn.

Q8. What does an administrator approve?

Three things, and none is silent: (1) an organization API token — created by an owner or admin with scopes (memos:read, optionally memos:create, memos:revoke, audit:read), org-scoped and audit-logged on every call; (2) a device enrollment for org-wide delivery — new devices land pending and consume nothing until an owner or admin approves them (Org admin → Devices), and revoking frees the seat; (3) agent proposals — propose_context files a draft that an owner or admin must approve before any memo is enqueued.

Q9. Do I need a token for MCP access — what is the credential model?

Yes: a short-lived, revocable org API token, scope-checked and audit-logged on every call; the raw token is shown once and only its SHA-256 is stored. There is no OAuth flow in v1 — the bearer token is the credential, and no third-party identity provider is required for an integration to work.

Configuration and operation

Q10. How is the hook configured — and can a memo interrupt a running agent?

Resolution order is flags > environment > config file > defaults, and airmemo-hook config prints the effective configuration (secrets redacted). Defaults worth knowing: poll every 10 seconds, 5-second HTTP timeout, 7-day local cache, learn events off. Force-continuation is off by default; when on, only urgent memos can continue a turn — leave it off unless you want a memo to spend model tokens without a human asking, and scope who can send urgent.

Q11. What are the rate limits?

Defaults: 30 pushes per minute for device traffic and 60 events per minute for integrations, enforced by one shared policy engine across the device API, integrations, and portal. Policies are rows (org, scope, who, action, limit) and the most specific match wins; a limit of 0 on an override row is a hard block (0 on a code default means no cap). Every violation is audit-logged (rate.limited), and a per-author concurrency cap can answer 429 max_concurrent_exceeded.

Q12. How does an org-wide ("broadcast") send get approved?

A comms-role author sending org-wide enters pending and is not enqueued until an owner or admin approves it in the portal; reject means revoked. A matching broadcast policy row is a grant that bypasses the approval step (rate limits still apply). There is no auto-escalation: if nobody approves, the memo lapses to expired and the author sends it again.

(Governance at a glance).

Q13. How do we roll out to a fleet (MDM / managed machines)?

One command per machine from the console's Rollout tab — the org enrollment key is embedded, rotation happens in the same tab, and re-runs are idempotent with zero prompts. Exit codes are deterministic: 0 ok, 3 bad key, 4 unreachable, 5 unsupported platform, 6 hash-change conflict, and 7 device pending approval ("park this machine and re-run after approval" — not a failure). airmemo-hook installer-mdm emits managed templates for MDM tooling.

Troubleshooting

Q14. "My memo didn't arrive" — where do I look first?

Run airmemo-hook doctor, then walk the decision tree: identity present; memo targeted at this platform/agent (a mismatch stays queued for the right target — not lost); expires_at in the future; not already injected (duplicate guard); if org-wide, was it approved; revoked?; device online within the expiry window. The stderr inject: line names skips, and a hook that ran but printed {} is the no-op contract, not an error.

Q15. Enrollment and auth failures — the common ones and their fixes.

not enrolled → run enroll; already enrolled; refusing to overwrite identity → delete the config file to re-enroll (identities are never silently clobbered); 401/403-class failures (unknown_device, bad_signature, clock_skew, …) are never retried, never injected — run doctor, and keep the system clock within the 5-minute HMAC window; device_pending is a wait, not a fault — after approval the hook picks it up on its own, with no re-enroll and no restart.

Q16. How do I prove a memo was delivered?

Receipts. Each injection posts a receipt to /v1/receipts — which memo reached which agent, when, and a proof hash of what was delivered. Locally, airmemo-hook receipts shows the journal (injected: true, receipt_sent: true means fully delivered; receipt_sent: false retries on the next poll's offline drain). In the console, delivery rows and the append-only audit trail are the record. The honest edge: receipt verification is limited where the input is not recomputable server-side — see the security page.

Security, privacy, and compliance

Q17. What actually leaves a developer machine — and do you track usage?

A request from the AI client to https://api.airmemo.com/mcp (or the hook's poll to the configured base URL) over HTTPS, carrying the org token. The hook dials exactly the configured base_url — health, enrollment, queue, receipts, deliveries; learn events are off by default. Telemetry is opt-in and off by default, and receipts — not analytics — are the record of what was delivered. Secret scanning runs at author time and again at delivery, and matched values are never stored.

Q18. What do you store, what do you never store, and how long is it kept?

Stored: the org's memos (author-signed text) with scope, priority, expiry, and approval state, plus delivery receipts with their proof hash. Never stored: source code, prompts, chat history, credentials. A memo is live until the expiry set when it is authored (7 days where the author sets none), after which the memo expires and its queued copy is deleted (memos are not archived); receipts and audit events are insert-only, and the tier's audit window (Q26) bounds how far back the console can read — not storage. Rows leave storage through erasure: export-before-delete manifests, and offboarding hard-deletes them within 30 days.

Q19. Where is our data processed — is there an EU option?

Default is a single region: US. A region setting exists and an "EU" claim can be recorded, but it is not a storage guarantee yet — cloud processing is split across US East (Postgres) and US West (compute), and EU data-residency processing is not offered today. The machine-readable posture is https://api.airmemo.com/status.json; the human trust page at https://api.airmemo.com/trust renders the same posture as HTML and does not serve JSON.

https://api.airmemo.com/status.json (2026-10-18).

Q20. Do you have a SOC 2 report?

Not yet — and it is not claimed. There is no report yet, and we will publish it when it exists.

Q21. SSO, SCIM, MFA — what ships today, and what is not offered (SAML)?

SSO (OIDC), SCIM 2.0 inbound provisioning, and MFA ship today, at every tier. SSO never grants privilege by itself (JIT members are members; the roles are owner, admin, member, comms), and SCIM deprovisions to member. SAML is not offered yet, and fine-grained RBAC beyond the four-role enum does not exist.

Q22. Can we self-host it — including air-gapped — and what does it cost?

Yes. The self-host kit ships (compose, Helm, Terraform; one image runs the API and the worker), licensed by an offline signed license file with no phone home; without a license it runs in community mode with ceilings. Restricted-egress deployments are documented and everything outbound is off by default — no telemetry, no license server, no update check. Self-hosting is priced at 1.5-2× the seat rate; you run the infrastructure.

Q23. Is the hook safe to deploy fleet-wide — and is any of this open source?

Deployment: a single static binary, no shell execution, user-space, hash-pinned, merge-safe install and exact uninstall; fail-open, so it can never block an agent session (Q7). Open source: the hooks are MIT-licensed; source publication follows the public release, and the public flip is event-triggered, not scheduled. Today the repository and the installer URL are private — see Q5 for the install path that works now.

(Install);

A public DPA covers controller/processor terms, the sub-processor list, retention, deletion, and breach notification; the Privacy Policy states what is collected, why, and for how long (front-desk intake data: 90 days). Requests are handled through the same org-scoped channel as the rest of the service — there is no separate compliance portal.

/requester-kit.md §7.

Billing, plans, and limits

Q25. How is a seat counted — and what happens when people leave?

A seat is one enrolled, non-revoked device (an approved hook installation): the whole fleet counts, and the subscription quantity is that count at billing time, so the bill matches the fleet. Seats cannot be moved below enrolled agents (the console refuses with 422 seats_below_enrolled), and a revoked device frees its seat. Enterprise floors follow the price row the org bought: 60 seats on the standard row, 1 on the under-60 pilot row (Q29); the 422 enterprise_floor names that row's own minimum. Console identities are not the meter — a licensed self-host install's ceiling is the smaller of its licensed seats and the agent cap, and unused logins do not bill.

Q26. What are the hard limits per plan?

Free: 5 agents · 4,000-character memos · 7-day audit visibility. Team: 25 · 8,000 · 30 days. Business: 100 · 20,000 · 90 days. Enterprise: unlimited agents · 20,000 · 365 days. Enforcement is technical and automatic: exceeding the agent ceiling is refused at enrollment with 429 agent_quota_exceeded, and a lapsed org's capacity clamps: immediately on cancellation, on day 15 for a failed payment.

Q27. What happens if a payment fails, or we cancel mid-term?

Payment failure: full access for 14 days, then read-only from day 15 — reads keep working, writes answer 403 org_readonly, and nothing is deleted. Cancellation: capacity clamps immediately — a canceled enterprise org drops to the business ceiling (100 agents, 90-day audit) — and write access runs 90 days, then read-only; data is kept. Refused billing webhooks leave audit rows, so refusals are visible.

Q28. Refunds and chargebacks.

Refunds are handled manually — there is no code path that issues a refund, by design — and the Terms carry the refund and dispute remedies (§6, §7). Plan conversions are handled as price changes, not credits.

/pricing (plan changes).

Q29. Can enterprise buy by invoice or ACH — and what does it cost?

Yes: Enterprise is $29 per seat per month ($348 per seat per year) for 60+ seats, sold annually by invoice with ACH; volume pricing applies at large fleets, and teams under 60 seats can run an annual enterprise pilot at $9 per seat per month. There is no usage-based billing and no per-memo price anywhere — every active price is a licensed recurring seat price.

Support, status, and contributing

Q30. Is the status page real?

It is a live ledger, not a static page: /status renders from service probes, and the same posture is published machine-readably at https://api.airmemo.com/status.json (live 2026-10-18: ok, no incidents). If you want to cite availability, cite the ledger.

Q31. How do we reach a human — and is there an SLA?

Front desk: /talk (pilot requests, SSO, procurement, self-hosting) and the support terms in the Terms of Service (§10). What is deliberately not shipped: a human service layer — no onboarding calls, no account managers (exception paths are automated only). There is no published uptime SLA today.

Q32. Can we contribute — or run the stack locally?

External contributions are not open yet: the repository is private (the hooks are MIT; see Q23). You can run the stack locally: pnpm --filter @airmemo/cloud db:dev for a fresh database and make test for the suites (the repo root exposes only validate:contracts and gen:cloud; root pnpm test and pnpm db:dev both return ERR_PNPM_NO_SCRIPT), make hook:build for the Go hook, and the hook's whole delivery path can be smoke-tested offline against the fake cloud ( The MCP docs include a runnable third-party client example.

Self-serve account actions

Q33. Do I need a card to start — and what does free include?

No card. Sign-up creates the organization and there is no payment call in the signup handler. Free includes 5 agents, 4,000-character memos, and 7-day audit visibility (Q26); the sixth device is refused at enrollment with 429 agent_quota_exceeded rather than billed silently.

Q34. How do I upgrade — and when does the charge land?

In the console: Billing → choose the plan → checkout. A seat-count change mid-cycle is sent to Stripe with create_prorations, so the prorated difference lands on the next invoice instead of charging the same day. Upgrades (free → team, team → business) are allowed; a downgrade is refused with 409 downgrade_not_allowed and the message to cancel first, because a plan switch is a new subscription, not a quantity edit. Enterprise at 60+ seats routes to invoice terms rather than card checkout (Q29).

Q35. How do we invite teammates — and what does each role do?

An owner or admin invites by email from the console (POST /portal/invites); the invitee sets a password and joins the org. Roles are owner, admin, member, and comms. SSO JIT and SCIM both land people as member, never as an admin (Q21). Seats count enrolled devices, not logins (Q25), so adding a teammate costs nothing until their machine enrolls.

(JIT role);

Q36. How do I export or delete the organization?

Both are owner-only and both live in the console. Export (POST /portal/org/export) returns a bundle of the org's memos, receipts, audit events, members, and settings. Deletion (POST /portal/org/erasure) requires a typed confirmation and returns the export archive before it runs the erasure, so the copy exists before the rows go. Offboarding hard-deletes within 30 days (Q18).

Known gaps

Two things this FAQ deliberately does not answer, with where to ask:

Mid-term seat reductions. What removing seats mid-term does to the next invoice is not stated on any public surface yet; ask the front desk (Q31).
Uptime SLA. None is published — the status ledger (Q30) is the availability record.