# Agent Portability Requirements *What an agent needs from Your Memory and from the system that works with it* **Status:** Proposal for discussion, after PAA v1.0. Not accepted architecture, an implementation plan, or an adopted standard. Everything marked new, and the framing below, is proposed. Each reviewed dimension has four parts: what it is, what is covered today (in the PAA repository and in the Agent Contract), the options, and what PAA should require versus what an implementation chooses. **Date:** 2026-10-27 · **Author:** Dave W, BrainDrive ## In short PAA already says Your Memory is the platform and holds everything that makes your AI yours. But today several things that pass PAA's own "irreplaceable" test live elsewhere or nowhere: Auth keeps identities and permissions in its own store, secrets are excluded from Memory and must be set up again after any change of home, and connections, schedules and task progress have no defined home. That leaves pieces of the owner's AI tied to particular components, which is a form of lock-in, and it grows as owners connect dozens of accounts. **The proposal:** expand Your Memory so everything irreplaceable lives there: agent definitions and their work, identities, permissions and approval rules, connection records, schedules and task progress, in a protected part that only Auth can change on the owner's decision; and credentials and keys in an encrypted, never-disclosed part opened only through Auth, with the owner holding the key. Components then hold nothing irreplaceable, so any of them can be swapped without losing anything or reconnecting every account. **What changes in PAA** (proposed, after v1.0): memory-spec's "no secrets in Memory" becomes "secrets only in the encrypted never-disclosed part"; auth-spec's data portability table changes, since identity and policy records live in Your Memory and credentials are no longer always "set up again on the new system"; US-3 AC-3.5 is reworded to match; and the Docs-accepted Shared App Contract v2 is folded into PAA as the Agent Contract, with "app" renamed "agent", "host" renamed "implementation", and its C-044 amended for the never-disclosed part. Most per-agent rules already exist in that contract; the rest of this document shows, dimension by dimension, what is already covered and what is new. **How strict this is** (agreed on the 2026-10-27 dev call): PAA states the pure requirement, and an implementation may fall short of it if it declares the gap and the trade-off, the way a crutch is declared. No implementation, BrainDrive included, is expected to meet the Auth and connections part today; every step toward it is less lock-in. ## Purpose and scope **A note on wording.** Wherever older thinking would reach for "the app" (the thing that holds your data, your agents and your connections, and that you would otherwise be locked into), in PAA that is Your Memory. So where something is kept, who owns it, or what survives a change is always stated as Your Memory. "The system" means only the working whole, as D57 defines it: Your Memory, the Agent Loop, Auth and the Gateway. A component **attached** to Your Memory is a part of the system working with it (the Agent Loop, Gateway, Auth, a scheduler or an adapter); clients and models stay outside the system and connect through the Gateway API and Model API. **So portability is not an agent moving from one system to another.** Four cases cover it: - **A component is attached or swapped** (Agent Loop, Gateway, Auth, a scheduler, an adapter), or a client or model is changed. Your Memory is untouched; the new part works with the same memory. - **An agent comes in:** installed, shared by someone else, or translated in from a non-PAA product through an adapter. - **A copy goes out** only when the owner shares one, into someone else's Memory. Nothing of the owner's leaves otherwise. - **Your Memory gets a new home** on new hardware or a new host. It is the same memory; only where it is stored changes (PAA already treats storage as swappable), and the system re-forms around it. Its bytes and custody move; its identity and meaning do not. **No component holds anything irreplaceable** (proposed). PAA's own test (memory-spec): if you deleted it and restarted, would something irreplaceable be lost? If so, it is Memory. Task progress, agent identities, connection records, permissions, approval rules, schedules and the audit log all pass that test. Today PAA keeps identities and policies in Auth's store with its own export, excludes secrets from Memory, and lists session tokens and regenerable derived data as not Memory. The proposal keeps those last two out, and brings identities, policies, connection records and secrets into Your Memory. **Outside tools reach Your Memory only through the system** (agreed on the 2026-10-27 dev call). Your Memory is read and written only by the components attached to it. An outside harness or app (Claude Code, Codex, Cursor, ChatGPT) reaches it through the Gateway, for example through an MCP Apps interface on the Gateway, and Auth decides what each one may see; that is how Your Memory is shared without a second copy. Pointing a harness straight at the folder still works, because the files are in open formats, but it is not the pure path: it adds lock-in to whatever that harness provides. Other stores the owner uses, such as knowledge bases, a CRM or email, are memory but not Your Memory. They are reached as external tools through adapters, and only what is in Your Memory is guaranteed to travel with the owner. Where a widely used standard fits (MCP, MCP Apps, an open plugin format), it is adopted behind an adapter the owner controls, so the system can diverge later without lock-in (D201). **Each item in Your Memory knows how far it may go**, as a person knows what they would share and what they must never share. Three owner-facing levels, with per-item rules underneath (shared with whom, for what, revocable), and derived data (indexes, embeddings, caches) inheriting the level of its source: - **Shareable:** an agent's capabilities, instructions and skills, eligible to go out as copies. Eligible is not automatically safe; the owner still chooses. - **Private:** the owner's work, journal, conversations and documents. Shared only selectively, by the owner's choice. - **Never disclosed:** credentials, identity keys, connection tokens. They are presented to the outside services they belong to, but never disclosed to models, shared copies, exports of shareable content, or logs. **Two special parts of Your Memory carry the safeguards** (proposed): - **The protected part** holds identities, permissions, approval rules and connection records. Generic memory tools cannot reach it. Policy and identity records change only through Auth's privileged operations, on an owner decision; administrative changes need owner presence, which requires an owner session distinct from an agent acting for the owner (the D190 agents step). Auth guards these rules but does not own them, so swapping Auth means a new guardian enforcing the same rules, once that Auth is trusted (see Open questions). Operational coordination records (scheduler and runtime leases, receipts) are written by the components that own them, in their own area, not in the protected part. - **The never-disclosed part** holds secrets. It is encrypted separately, never kept in git-tracked storage, and never touched by generic memory tools, export of shareable content, search or indexing. Components do not read raw secrets: Auth authorizes each use, and a broker performs it or hands over a short-lived, scoped credential (Agent Contract C-043), for any credential-consuming adapter, model providers included. The owner holds the master key (a passphrase, hardware key, OS keychain or signer); it is not stored as a file in Memory. The part goes wherever Your Memory goes and is never included in anything shared. **The Agent Contract.** The PAA Shared App Contract v2 (the Agent Contract, with the companion Portable App Specification and Host Conformance Specification) was accepted in BrainDrive's internal docs (2026-09-04) as a PAA candidate contract; it will be published when it is proposed for PAA. Its own approval note says it is "a mature foundation candidate, not ratified PAA authority", and it is not in the PAA repository. Its "app" is a composition over PAA, not a fifth component (C-003); its "host" is a deployment or product implementing the PAA components and APIs, not a component. Decided 2026-10-27: when it goes into PAA, "app" is renamed "agent" (experts-as-plugins replaced the apps runtime), and "host" is renamed "implementation". "Host" never appears in the PAA repository, while "implementation" is PAA's existing word for the same thing (US-3 AC-3.2: "a different conforming implementation"), and "host" carries the app-era picture of agents as guests in someone's product. The Host Conformance Specification becomes the Implementation Conformance Specification and host claims become implementation claims; the contract's "implementation profile" (an implementation's concrete values) keeps its name and is defined once. An implementation is the product or codebase that makes conformance claims; the system is the running whole (D57). The rename is a versioned semantic change, not a find-and-replace: "agent" must still cover Memory-only, capability-only and surface compositions, and the `PAA-APP-*` requirement IDs, including the `PAA-APP-H-*` implementation IDs, are kept as aliases. Below it is called the Agent Contract and cited by requirement ID. Each dimension's Covered today paragraph lists what PAA and the Agent Contract already require, and PAA should require lists only what is new. One conflict: C-044 keeps secret values outside Your Memory, which the never-disclosed part amends. **Identity vocabulary.** Several identities are easy to blur; this document keeps them apart: | Term | What it names | Changes when | |---|---|---| | **Definition ID** | The agent as published, across versions (the Agent Contract's stable app identity, §5) | Never; a new version keeps it | | **Publisher ID** | Who published the definition (§5) | The publisher changes | | **Installation ID** | This agent in this owner's Memory | It is installed, received as a share, or reinstalled | | **Actor ID** | The identity Auth checks and the audit log records when the agent acts | Its keys rotate (the actor stays the same) | | **Session ID** | One running conversation or task | Every session | | **Owner** | Who controls the installation; plus whoever it acts for, if different | Ownership is transferred deliberately | A shared copy keeps the definition and publisher IDs, so provenance and updates still work, and gets a new installation ID, a new actor ID and no grants. An agent works when it can perform its intended functions with the system it has, while preserving its required boundaries. It need not produce identical answers: models, tools and environments vary. Anything an agent needs and cannot get is reported before the agent relies on it, never dropped silently; PAA already applies that rule to memory import (US-3, AC-3.2), and the dimensions below extend it to a single agent. A dimension is required only when the agent's intended use depends on it; not every agent needs schedules, other agents, a specialized interface, or a resumable run. ## The twelve dimensions These are dimensions of what an agent needs, not PAA components; PAA keeps its four components. ### 1. Agent definition *(reviewed 2026-10-26)* **What it is.** What makes the agent that agent: its purpose, instructions, skills, configuration, workflows, and how those pieces refer to each other. For an expert, this is its behavior folder (its AGENT.md, skills and starter templates), the part that is shared without the owner's own work. Whatever is attached to Your Memory must be able to load and interpret it, and when it comes into a new owner's Memory, anything it refers to (files, tools, models, services, other agents) must resolve there or have an explicit replacement. Skill text can coordinate workflows; a workflow need not be a separate executable program. **Covered today: mostly covered.** In the PAA repository: instructions, skills, personality and way of working are plain files in Your Memory, not code, and Your Memory must be inspectable and exportable, so they stay with the owner whichever components are attached. Any conforming Agent Loop can run them, because "the product's behavior comes from Your Memory, not from Agent Loop customization." PAA deliberately does not define the packaging (D49: entry-point files and skill layout are product conventions). In the Agent Contract: an agent identifies every element it supplies, requires or omits (C-009); its declaration (§6) carries identity, resources, tools, context, data, presentation, compatibility, trust and lifecycle, and never grants authority (C-012); references resolve to versioned resources with integrity (C-013); a missing required capability blocks activation with a typed result, and a missing optional one selects only a declared degraded mode (C-015, C-016), so unresolved references are reported, never silently dropped. The declaration is the manifest the options below keep proposing. **Gaps:** PAA says nothing about separating one agent's definition from the owner's other files, or about checking that references resolve when an agent comes into a Memory. **Options.** - **Agent Skills** (SKILL.md folders): a widely adopted plain-file format for skills and prose workflows that fits PAA naturally. Hosts load skills differently, and its compatibility field is descriptive only. - **The agent plugin package** (manifest plus skills, later connections and UI): bundles the whole definition in one shareable folder and works in ChatGPT and Claude today. It defines packaging, not behavior elsewhere; the research treats vendor plugin formats as distribution adapters, not a universal standard. - **Oracle Agent Spec:** a structured format for agents and multi-step flows with loaders for other runtimes. Heavier; needed only if workflows must run as strict steps. - **A small manifest of our own:** lists the agent's parts and what each needs (tools, models), so what is missing can be reported. New but small work, likely needed regardless. **PAA vs implementation.** - **PAA should require:** everything under Covered today, plus: a definition can be shared on its own, as a copy, without the owner's personal work; and package formats are outside formats, so bringing an agent in or sharing one out goes through an owned adapter (a new application of the adapter principle, D201, which today covers model providers, client formats and tool sources). PAA never adopts the plugin standard itself. - **Implementation choice:** the package format, the entry-point file name, skill layout, and prose vs structured workflows. - **BrainDrive's choice (leaning; open plugin and MCP Apps standards adopted behind an adapter, agreed 2026-10-27):** the agent plugin package wrapping Agent Skills folders, plus a small "what this agent needs" manifest, behind an adapter so another format can be swapped in later. ### 2. Model access *(reviewed 2026-10-26)* **What it is.** The AI model the agent thinks with, and what the agent needs from it: not a specific model, but a model that can do what the work requires (read images, use tools, handle the necessary context) with the settings the work depends on. Changing providers or models is compatible with portability when the intended functions and boundaries still hold; identical outputs are not required. **Covered today: well covered, one gap.** In the PAA repository: "swap the model" is one of PAA's six lock-in tests. The owner's model choice and active provider profile are preferences in Your Memory, read on every message, so a change takes effect on the next message without a restart (D193). Provider adapters contain each provider's format, so a new provider format is a new adapter. A chosen model that lacks an ability the request needs reports `capability_unsupported` naming the ability; nothing is faked and no model is substituted (D197). In the Agent Contract: the declaration's compatibility field states required host capabilities and dependencies (§6), so an agent can declare the model abilities it needs; a missing required model capability is a typed `dependency_unavailable` result before activation (C-015, §16); and swapping a model or provider never requires rewriting the agent's meaning or data (C-008). **Gaps:** in the PAA repository, abilities are checked per request, after the fact; an agent cannot declare up front what it needs from a model, so a mismatch for an incoming agent, or after a model swap, shows up only when it fails in use. The declaration and C-015 cover the check when an agent comes in, but nothing re-checks when the owner changes model. **Options.** - **LiteLLM:** library or gateway translating 100+ provider APIs. A translator only; it does not qualify a model for the agent's tasks. - **Vercel AI SDK:** TypeScript provider adapters with per-model capability tables. Same limit. - **OpenRouter** (already in BrainDrive): one key, 400+ models, capability metadata per model. A hosted outside dependency, behind its own adapter. - **Declared requirements in the agent's manifest:** the agent lists the model abilities it needs, checked when it comes in. Small new work, using the same manifest as dimension 1. None of these carries provider-held state (hosted threads, uploaded files, caches); PAA already avoids that dependency by keeping conversations in Your Memory. **PAA vs implementation.** - **PAA should require:** everything under Covered today, plus: when the owner changes model, the agent's declared abilities are re-checked and a mismatch is reported then, not only when a request fails. - **Implementation choice:** which provider adapters ship, the default model, and how abilities are described. - **BrainDrive's choice:** BrainDrive Models, OpenRouter and Ollama behind its OpenAI-compatible adapter (current). New: check an expert's declared abilities against the selected model at install and on model change. ### 3. Tools *(reviewed 2026-10-26)* **What it is.** What the agent can actually do beyond thinking and talking: search, read a statement, send an email, build a website. The components attached to Your Memory need working tool implementations with compatible inputs, outputs and behavior, plus their service connections and dependencies; tool names or descriptions alone are insufficient. When a tool delegates to another agent, that agent's requirements count too, or the dependent capability is reported as unavailable. **Covered today: well covered for using tools; installation deliberately left open.** In the PAA repository: tools are outside the system: each describes itself, Auth decides who may use it, and the Agent Loop runs it, so adding a tool never changes the architecture. Every outside tool protocol, MCP included, goes through a tool-source adapter (D201), so definitions look the same whatever the protocol. Owners configure `tool_sources` and the system asks each source what it offers; untrusted tools run isolated. In the Agent Contract: every tool declares source, identity, version, effects (read, write, external, consequential, destructive), required authority, idempotency, timeout and retry behavior, and typed failures (§13); required tools are negotiated before activation, so naming required tools and reporting missing ones is covered (C-015); the Agent Loop runs them generically (C-045); and a tool failure never corrupts Your Memory (C-047). **Gaps:** installing a tool is the environment's job, not the architecture's, so PAA confirms a tool is present and working but does not say how an incoming agent's tools get installed or how its expectations are matched. **Options.** - **MCP:** the leading tool-connection standard. It does not install the server, move its state, or match its permissions to the agent; the server itself must refuse an unauthorized write regardless of host wording. - **OpenAPI / JSON Schema:** precise descriptions of a service's inputs and outputs. They describe the tool, not implement it. - **A2A:** lets separately running agents hand work to each other, covering tools that are other agents. Young; pin versions. - **Packaged local tools** (in a container or inside the plugin): the tool's code travels with the agent. Overlaps dimension 4. - **The manifest:** lists each tool the agent needs, with version and source, so what is missing is reported. Same manifest as dimensions 1 and 2. **PAA vs implementation.** - **PAA should require:** everything under Covered today, plus: an agent never proceeds as if a missing tool were present. Nothing else here is genuinely new beyond carrying C-015 and §13 from app to agent; how a missing tool gets installed stays open. - **Implementation choice:** supported tool protocols, default tools, and how tools are installed. - **BrainDrive's choice:** MCP behind the tool-source adapter (current, plus the PR #350 refresh fix); an expert's plugin lists the MCP tools it needs. How BrainDrive installs a missing tool is open until the connections step. ### 4. Execution environment *(reviewed 2026-10-26)* **What it is.** What the agent's own code and tools need from the machine: runtime, scripts, libraries, files, compute, sometimes a GPU. An instructions-only skill needs none of this; a skill that runs a script needs the right runtime and libraries wherever it runs. The attached environment must be able to check these needs before execution, and local paths and environment-specific references must resolve. Scripts inside skills are also where the security risk concentrates. **Covered today: covered for the system, not for an agent's own needs.** In the PAA repository: the PAA system must run anywhere, fully offline included, and the deployment spec names a way out of every dependency. Containers are one supported way to run it, never required (D173). Untrusted tools run isolated. In the Agent Contract: the declaration discloses executable content (§6); no agent-supplied code runs before trust and owner-authorization decisions (C-020); and the exact code versions activated are bound to what was evaluated (C-021). Dependencies are part of the compatibility statement (§6), but machine requirements such as runtimes and libraries are not spelled out. **Gaps:** nothing describes what a particular agent's scripts and tools need from the machine, or checks it before they run. **Options.** - **OCI containers** (Docker, Podman): mature, ships a tool with everything it needs. Heavy for small scripts; packages code, not a running task; does not enforce permissions by itself. - **WASI (WebAssembly):** small sandboxed tools that get only the access granted. Cannot run arbitrary native Python libraries or GPU code without extra work. - **Dev Containers:** declares a development setup; its setup commands run code, so they need a trust decision. Not for production. - **Declared requirements in the manifest:** each script and tool lists the runtime and versions it needs; the environment checks before running. Small new work. - **Instructions-only agents:** many experts need no executable code, so nothing to carry. **PAA vs implementation.** - **PAA should require:** everything under Covered today, plus: an agent that carries executable code declares what it needs from the machine, the environment checks before running and reports a mismatch, and an agent's code never runs with more access than it declared. - **Implementation choice:** how agent code is packaged and sandboxed (containers, WASI, plain scripts) and which runtimes ship. - **BrainDrive's choice:** the first experts are instructions and skills only, with no executable scripts. When experts gain scripts, they run sandboxed (container or WASI, to be decided), with their needs declared in the plugin manifest. ### 5. Memory and accumulated work *(reviewed 2026-10-26)* **What it is.** Everything the agent has learned and produced for the owner: goals, plans, journal, preferences, conversation history and documents. For an expert, its "Your Files". Information must stay usable, with enough context and source information to interpret it. Usable source material moves when derived indexes cannot; an index that remains usable and compatible need not be rebuilt. **Covered today: PAA's strongest area.** In the PAA repository: Your Memory is the platform: it depends on nothing and everything depends on it. US-3 lets the owner re-house their memory: export everything in open formats, with indexes optional because they can be rebuilt, which implies original material is kept whenever a derived index cannot move (AC-3.1); import into another conforming system loses nothing and anything unsupported is reported, never dropped silently (AC-3.2); passwords, sessions and keys are not portable memory (AC-3.5, to be reworded for the never-disclosed part). In the Agent Contract: each durable data class declares meaning, provenance, retention, export, migration, sharing and deletion (§14); owner data lives in Your Memory and stays usable without the original agent or client (C-049, C-050); removing capability, revoking authority and deleting data are separate operations (C-053); no remote account or billing signal can lock the owner out (C-053A); migrations are deterministic, never model-driven (C-052); and sharing an output is an explicit, bounded, provenance-preserving action that grants no implied access (C-056 to C-058), so agent-scoped data, provenance and selective sharing of outputs are largely covered. **Gaps:** US-3 moves the whole memory, not one agent's work, and does not cover sharing an agent without it; provenance (where a fact came from) is not required to travel; importing from non-PAA systems (for example ChatGPT memory) needs a translator. **Options.** - **PAA export as-is** (plain files plus conversations): works today, human-readable; moves everything at once. - **ALF (Agent Life Format):** a proposed standard for carrying memory, persona and attachments between products; a candidate for the import translator. Release-candidate maturity; its lossless claim is untested; excludes running work. - **Letta Agent File:** a concrete format for saving an agent with its memory. Support is uneven; Letta's newer product removed it. - **Mem0 / Graphiti:** memory systems, not migration formats; Mem0 extracts memories, so originals must be kept separately. - **Agent-scoped folders:** each agent's work in its own folder in Your Memory, making sharing or removing one agent a folder operation. A convention; BrainDrive already organizes much of its memory per page. **PAA vs implementation.** - **PAA should require:** everything under Covered today, plus: the work tied to an agent is identifiable on its own, so the agent can be shared without it, removed with or without it, or its work shared selectively, with where each piece of content came from kept as far as it is recorded. - **Implementation choice:** folder layout, how work is tied to an agent, any interchange format (such as ALF), and which import translators to offer. - **BrainDrive's choice:** each expert's work lives in its own folder under Your Memory, matching today's per-page folders and the files vs capabilities split on the expert page; sharing an expert ships the capabilities folder only. ALF or ChatGPT import translators are later options, behind an adapter. ### 6. Work in progress *(reviewed 2026-10-26)* **What it is.** A task the agent is partway through: its objective, the steps done, intermediate results, pending steps and pending approvals. The hard part is outside actions already taken. If the agent has sent an email, paid an invoice or submitted a form, whatever component next runs the task must not repeat it, and a step whose outcome is unknown (it crashed mid-payment) must be checked before carrying on. This applies only when the task must resume; starting fresh with the same agent needs none of it. **Covered today: covered for conversations, not for tasks.** In the PAA repository: conversations can be listed and resumed from any client, and tool calls and results are saved in history, so they survive export. If the Agent Loop fails after a reply has started, the incoming message, partial reply and tool events are kept with an explicit error outcome and the turn is never reported as complete. In the Agent Contract: each agent defines its durable progress state, resume behavior and completion conditions (A-024); durable state never lives only in runtime state (C-049); every tool declares an idempotency key or that it cannot be repeated, plus how ambiguous completion is reconciled (§13); a possibly duplicated consequential action is reconciled or idempotency-protected before retry (C-048); `ambiguous_completion` is an error category, and failed or ambiguous work is never reported as success (C-061). For agents that run multi-step tasks, the requirements that task progress lives in Your Memory in a readable form, that every outside action with consequences leaves a receipt, and that a restarted agent or newly attached runtime never repeats an action it cannot confirm was not done (an unknown outcome waits for reconciliation or the owner) are all in the Agent Contract (A-024, C-048, C-049, §13). **Gaps:** in the PAA repository, the Agent Loop works one turn at a time. There is no multi-step task that runs across turns, no record of outside actions already taken, and no rule against repeating one. PAA has not needed this, because today an agent acts only when the owner messages it. **Options.** - **Durable runtimes (Temporal, LangGraph, DBOS, Restate):** mature ways to keep a long task's progress through crashes and restarts. Each keeps progress in its own format, so a task resumes within one runtime but not across them, which puts irreplaceable state in a component unless progress is also kept in Your Memory. Restate's license needs review. - **Progress kept as files in Your Memory** (objective, steps done with receipts, pending approvals, results): readable by any Agent Loop or runtime attached to Your Memory, so swapping the runtime loses nothing. It restarts a task from a record rather than continuing mid-step. - **Action receipts with unique IDs:** let any attached component tell done from not done, so an email is never sent twice. They work only where the outside service accepts unique request keys; otherwise a human check is needed. - **Finish or cancel before swapping the runtime:** no in-flight handover at all. Enough for agents that act only when asked. **PAA vs implementation.** - **PAA should require:** everything under Covered today, for agents that run multi-step tasks. Nothing here is genuinely new beyond carrying A-024, C-048, C-049 and §13 from app to agent. - **Implementation choice:** which durable runtime, if any; the format of progress records and receipts; and which tasks can restart safely. - **BrainDrive's choice:** v1 experts act only when the owner messages them, so this is finish or cancel before swapping, plus conversation resume, which already works. When experts start taking outside actions (building websites, paying bills), progress and receipts go in Your Memory first; a durable runtime is chosen only if needed. ### 7. Identity and ownership *(reviewed 2026-10-27)* **What it is.** Three separate questions: which agent this is (stable identities, so the agent stays recognisably the same whichever components are attached, and a copy can be told from the original; see the identity vocabulary in Purpose); who owns it (who controls, changes and can switch it off); and who it acts for, usually the owner but possibly a family member or business. The agent is not its owner, and neither is the account it uses. A copied or shared agent inherits none of the original owner's authority: it arrives with no access, and its new owner grants their own permissions. **Covered today: the identity model is there; agent identity is deliberately deferred.** In the PAA repository: Auth gives every actor an identity and defines actor types (owner, interactive and background agents, external agents, services, economic actors); a new type gets no permissions until the owner grants them. The `auth_context` travels from Gateway to Agent Loop and is used for every tool check and audit record, so the audit log records which actor acted (already true for actors), and an external agent never substitutes the owner identity. Passwords, sessions and keys are not portable memory (AC-3.5), and Auth keeps identity records in its own store with its own export; the Purpose framing moves them into Your Memory. In the Agent Contract: the definition ID and publisher ID are required elements (§5); they name the published agent and its source, not an Auth actor, an owner relationship or a key. Authority derives partly from the agent's identity (§12). Reinstalling is a new trust and authority event, with no silent return of credentials, grants or consent (C-026); it says nothing about shared copies. **Gaps:** decided gap (GAP-PAA-24, D190): in v1 the AI in a conversation acts under the owner's identity; distinct identities for agents acting for the owner are deferred to the agents step, when PAA adds external tool calls or external agents. This component is that deferred agents step. **Options.** - **Plain agent ID plus owner field** in the agent definition and Auth's identity records: simple, local, fits PAA's actor model; proves nothing to outside parties. - **Nostr keypairs:** the key is the identity, self-generated with no registry or issuer. The owner can sign a statement linking the agent's key to theirs, checkable offline without relays. Remote signing (NIP-46) keeps keys out of the runtime, encrypted key export (NIP-49) suits re-housing Memory, NIP-05 gives a readable name, and the key type matches Bitcoin/Lightning for future economic actors. Limits: no standard key rotation or recovery; delegated signing (NIP-26) is marked unrecommended, so the owner-to-agent link needs a defined convention; few outside services verify Nostr identities, and it proves who the agent is, not what it may access. - **DID / Verifiable Credentials (W3C):** identifiers and signed claims outside parties can check. DID methods vary widely in resolution and recovery, and a credential does not itself grant permission. - **SPIFFE:** short-lived workload identities for managed server fleets; overkill for personal agents. - **OIDC:** authenticates the owner; does not authorize the agent's actions. **PAA vs implementation.** - **PAA should require** (the D190 follow-through, when the agents step lands): everything under Covered today, plus: every installed agent has its own installation ID and actor ID, separate from its owner and from the accounts it uses, recorded in the protected part of Your Memory and enforced by Auth; exactly one recorded owner, plus who it acts for if different; the audit log records which agent actor acted; an agent can never change its own identity or ownership; swapping Auth or any other component keeps the same actor ID, with any identity key held in the never-disclosed part; and a shared copy keeps the definition and publisher IDs but gets a new installation ID, a new actor ID and zero grants, never the original's keys. - **Implementation choice:** the ID format (plain, Nostr, DID), whether to offer outside verification, and how runtime identity rotates. - **BrainDrive's choice:** v1 experts act under the owner's identity (D190), since they touch only the owner's own memory. Each expert gets a stable ID in its definition now; separate Auth identities come when experts make outside calls. Nostr and DID/VC remain options until something outside needs to verify an expert. ### 8. Account connections *(reviewed 2026-10-27)* **What it is.** The outside accounts an agent uses to do its job: Gmail, a bank feed, a domain registrar. Owners will eventually have dozens. If swapping a component or re-housing Memory means signing in to each again, re-consent becomes the switching cost that keeps people where they are, which is lock-in. Providers bind an OAuth token to the registered app (client) it was issued to, so the question is whose app the provider sees. If it is a component vendor's, every connection belongs to that vendor and breaks when the component is swapped. If it is the owner's, the connection is part of Your Memory and swapping components does not touch it. **Covered today: secrets rules, but no connection records.** In the PAA repository: secrets never go in Your Memory or anything git tracks; they live in environment variables, an untracked config file, or a secret store, so a memory export cannot leak a credential (security-spec, memory-spec). Adapter config holds secret references, never secrets; tool definitions cannot carry credentials or endpoints. `auth_context` carries neither credentials nor permissions. Auth's tiers include scoped tokens and OAuth 2.1 for external actors, all inbound. In the Agent Contract: an agent may receive only a scoped, time-limited, purpose-bound delegated capability, never the underlying provider or account secret (C-043), and reinstalling never silently restores credentials (C-026). **Conflict:** C-044 keeps secret values outside Your Memory; the never-disclosed part amends it. **Gaps:** nothing records which outside connections exist, who owns them, or which agents need or may use them, so a newly attached component cannot pick them up or report what is missing, and nothing prevents a connection belonging to a component vendor rather than the owner. **Options.** - **Connection records in the protected part of Your Memory, tokens in the never-disclosed part, Auth as guardian:** a connection is the same question Auth already answers, pointed outward; Auth decides and enforces but stores nothing. - **Owner-run vault or connection broker behind an adapter** (for example self-hosted Nango, license under review): reached through an adapter (D201), it is the owner-controlled OAuth client, so every other component swaps freely. - **Owner-registered OAuth apps:** the owner's own client credentials sit with the tokens, so any connection adapter the owner attaches can use them. Setup friction; provider verification rules for sensitive scopes (such as Gmail) need checking before relying on it. - **GBrain (checked 2026-10-27; [gbrain.io/tools](https://gbrain.io/tools), [open-source repo](https://github.com/garrytan/gbrain), MIT), two designs side by side:** - *Hosted ("connect an account once for every AI you use"):* GBrain holds every account's keys on its servers, encrypted with a platform-managed master key, so the vendor can decrypt them. The AI never sees a token: GBrain checks permission and a daily limit, makes the call, returns the result and logs it. One MCP address serves Claude and ChatGPT. Whose OAuth client the services see, and whether its export carries connections, are not documented. This is the vendor-held pattern that fails "connections are owner property", even though it meets "components never read raw tokens" in spirit. - *Self-hosted:* the owner creates their own Google OAuth client; tokens stay in a local file (mode 0600) and `gbrain creds export` produces a passphrase-encrypted bundle for another machine, so switching AI clients costs no re-consent. Working evidence for owner-registered apps; it lacks a protected record store, and it was not confirmed that the agent can never read the token file. - **Tokens bound to their app registration:** keeping a token is not enough; it works only with the OAuth client it was issued to, so the client registration is kept with the token in the never-disclosed part. - **OAuth 2.1 with RFC 9700 and MCP authorization:** the flows themselves; reconnection is the fallback where a provider allows nothing else. **PAA vs implementation.** - **PAA should require** (an outbound extension of Auth): everything under Covered today, plus: connections are owner property in Your Memory, never a component vendor's. Connection records (service, owner, scopes, which agents may use it, a reference to its secret, the audit trail) live in the protected part; tokens and the client registration they depend on live in the never-disclosed part, outside tracked storage (extending today's secrets rule). Components never read raw tokens: Auth authorizes each use and a broker performs it or issues a short-lived, scoped credential (C-043). Swapping a component that does not hold the OAuth client relationship costs no re-consent; where a provider binds a token to a client, audience or device that changes, reconnection is needed and is reported, with what is broken until then, as a typed `dependency_unavailable` result (Agent Contract §16) rather than the model-specific D197 code. Nothing is used silently and every connection is revocable. A copy or share carries the connections an agent needs, never the records or secrets. - **Implementation choice:** how the never-disclosed part is encrypted and stored, what holds the owner's key (passphrase, hardware key, OS keychain, signer), OAuth flows, and who holds the OAuth client relationship: one owner-controlled connection adapter or broker (recommended, so only swapping that piece can force re-consent), owner-registered apps, or per-adapter clients. - **BrainDrive's choice:** v1 experts' only outside connection is the model provider (BrainDrive Models or the owner's own key), which already uses secret references. When experts need Gmail, a bank and so on, connection records go in the protected part of Your Memory and tokens in the never-disclosed part, through one owner-controlled connection adapter, so BrainDrive never owns the connection. ### 9. Permissions and approvals *(reviewed 2026-10-27)* **What it is.** What the agent may do and what it must ask about first: for example, read bank transactions and draft invoices, ask before sending one, never spend more than $50 a day. The limits live in Your Memory and whatever Auth is attached must enforce them. If it cannot enforce a limit, the agent loses that ability rather than gaining it. A rule written only into the agent's instructions does not count, because a model can ignore a prompt. **Covered today: one of PAA's strongest areas, except per-agent limits.** In the PAA repository: Auth checks every request and every tool call before it runs; an approval rule in a prompt "is a suggestion the model might ignore". The portable policy format (`policy.json`) carries allow and deny rules with conditions such as `time_window`, `max_per_day` and `requires_approval`, and an unknown condition makes a rule unsupported and non-granting. The approval lifecycle is defined: a stable request ID and expiry, one terminal decision (approved, denied, cancelled, expired), idempotent replay that cannot run the tool twice, and resolution only by an approval-authorized identity. The owner can do everything by default and anyone else starts with nothing; approval prompts are a product choice, but owner-set approval rules must be enforced. Auth configuration, including approval rules, is in `auth_export`, held in Auth's own store; the Purpose framing moves it into the protected part of Your Memory. In the Agent Contract: enforcement independent of prompts (C-038); least authority (C-039); a material authority expansion needs a new owner decision (C-040); consequential actions follow the owner's approval policy and the approved description must match what runs (C-041); paused, removed or replaced sessions keep no stale authority (C-042); and authority derives partly from the agent's identity (§12), so per-agent authority and owner decisions on expansion are covered there. **Gaps:** in the PAA repository, no per-agent limits, since every v1 AI acts under the owner's identity (D190); no spending limits (`max_per_day` counts actions, not money, and economic actors are named but their limits undefined); and no way for a shared agent to state the permissions it needs so the new owner can grant them in one step. **Options.** - **PAA's `policy.json`:** already defined, portable and fail-closed; a narrow condition set with no money limits. - **OPA, Cedar, OpenFGA (Apache-2.0):** mature policy engines for general rules, fine-grained permissions and relationship-based access. Each has its own policy language, so moving between them needs translation, which is an adapter, not a standard. - **AuthZEN (OpenID):** a standard API for asking a policy engine whether an actor may act; standardizes the question, not the policies, so it fits behind Auth's adapter. - **Agent Skills `allowed-tools`:** a skill lists the tools it uses. Experimental and descriptive: a request, not a grant. **PAA vs implementation.** - **PAA should require:** everything under Covered today, plus, with agent identities: permissions can be set per agent; a shared or copied agent carries the permissions it needs, never the grants, for the new owner to approve; grants live in the protected part of Your Memory and change only through Auth on an owner decision (owner presence for administrative changes), so swapping Auth keeps them and an agent can never change its own permissions; anything an attached Auth cannot enforce is reported and left off, never widened. Also new: spending limits for agents that can spend money, enforced against reservations and settled amounts so concurrent or pending spends cannot exceed them (design in Open questions). - **Implementation choice:** the policy engine behind Auth (OPA, Cedar, OpenFGA or a simple built-in), how approval prompts look, and default strictness. GBrain's hosted tools show a simple owner-facing form worth borrowing: a per-agent, per-service ladder (Off, Read, Draft, Manage, Full), a daily limit per tool, an optional end date on each grant, a one-press off switch, and one log that records refusals as well as successes. - **BrainDrive's choice:** v1 experts act as the owner with no approval prompts, matching PAA's defaults. Each expert's definition lists the permissions it needs, so per-agent grants are ready when agent identities arrive. Approvals switch on, in software, the first time an expert can take an outside action such as sending email or spending money. ### 10. Schedules and triggers *(reviewed 2026-10-27)* **What it is.** What makes the agent act without being messaged: schedules ("every Monday at 8am, review my budget") and events ("when an invoice email arrives, file it"). The rules live in Your Memory; a scheduler or event receiver is a component that acts on them. Three things matter: each run takes effect at most once, so nothing runs twice when a scheduler is swapped or a second one is attached; each schedule says what happens to runs missed while no scheduler was running (catch up or skip); and outside services that send events point at the owner's address, not at a particular component. **Covered today: the plumbing is there, but no schedule format or single-runner rule.** In the PAA repository: a message, a webhook and a scheduled job all arrive through the Gateway in one request shape, labelled `message`, `webhook` or `schedule`, and even scheduled runs create a conversation the owner can review. PAA's design notes already put schedules in Memory: "Add schedule definitions (memory) and a cron tool. No new component." Background agents are a defined actor type with their own identity, arriving with the agents step (dimension 7). In the Agent Contract: standing or scheduled authority for a consequential action names the agent, capability, scope, trigger, maximum impact, expiry, notification behavior and revocation path, and cannot silently authorize a new consequential effect (C-041A), so recurring authorization is covered. **Gaps:** no defined schedule format; no rule that only one attached scheduler fires a schedule; no missed-run rule; and no record of which outside services send events where. **Options.** - **iCalendar recurrence (RFC 5545 RRULE):** the established standard for recurring times with time zones and end dates; every calendar app understands it. Schedules only. - **Cron expressions:** simple and universal; no time zones or end dates in the format, and dialects vary. - **CloudEvents (CNCF):** a standard envelope so events from any source look alike; describes the event, not what to do about it. - **AsyncAPI:** documents which events a service sends and receives; not a scheduler. - **Durable runtime schedules (Temporal and similar):** reliable timers with pause and catch-up controls, kept in the runtime's own format (the dimension 6 limit). - **OS schedulers (launchd, systemd timers):** what fires the job on the owner's machine; an implementation detail. **PAA vs implementation.** - **PAA should require:** everything under Covered today, plus: schedule and event rules live in Your Memory in an open format (fits PAA's existing design); each scheduled run takes effect at most once, however many schedulers are attached or swapped (through leases, deduplication and crash reconciliation; the mechanism is an implementation choice); each schedule declares its missed-run rule; event subscriptions at outside services point at the owner's address (the owner's Gateway or domain) and are recorded with the connections (dimension 8); and a copy or share arrives with its schedules switched off until the new owner turns them on. - **Implementation choice:** the scheduler (cron tool, OS timers, a durable runtime), how at-most-once runs are enforced (leases, fencing, deduplication), the event receiver, and the formats; RRULE and CloudEvents are suggested defaults, not requirements. - **BrainDrive's choice:** v1 experts have no schedules or event triggers; they act only when messaged. When they arrive (a weekly budget check-in, say), definitions go in the expert's folder as RRULE, switched off on copy, fired by one scheduler holding a lease. ### 11. Interaction channels *(reviewed 2026-10-27)* **What it is.** The ways people and other agents reach the agent: a chat app, a phone app or CLI, messaging (Telegram, email, SMS, voice), a specialized screen the agent depends on (the expert page with its sidebar, a form, a chart), and other agents handing it work. Channels are clients connecting to the system through the Gateway API; adding or swapping one changes nothing about the agent or Your Memory. The questions are what the agent needs from a channel and what happens when a channel cannot provide it. An approval a channel cannot show waits or expires; it never proceeds by default. **Covered today: very well for chat.** In the PAA repository: clients are outside the system (D57): web apps, CLIs, mobile apps, bots and voice assistants all connect through the Gateway API, and "any client that speaks the Gateway API works, including ones that don't exist yet"; outside client formats go through client adapters (D201). Conversations live in Your Memory and any client can resume any conversation; the Gateway is interface-agnostic (D59). Approvals are stream events (`approval-request`, `approval-result`), and an unanswered request expires without running the tool. In the Agent Contract: presentation is declared separately from execution (C-010) as Conversational, Agent-Supplied Surface, Capability-Only, or a combination, with required client capabilities. In a conversational agent, the agent supplies instructions, data rules, actions, progress and completion; the client supplies the generic conversation UI, streaming, history, errors, approvals and document display (C-017, A-023). An agent's own screen is an external client using the Gateway API, with no access to component internals or credentials, and the owner's data stays usable without it (C-018, A-027, A-028). A conversational claim must be proven through a terminal or equivalent generic second client (A-026). An agent with several presentations keeps one identity, data meaning and set of authority boundaries across them (C-019). The owner can resume from another compatible client without hidden client state (AJ-5). **Gaps:** in the PAA repository, channel bindings (a Telegram bot, an email address) are recorded nowhere, and agent-to-agent handoff arrives with external agents in the agents step. **Options.** - **Gateway API plus client adapters (current PAA):** any chat-style client today; text, files and approvals. - **MCP Apps:** a tool ships its own interactive UI, rendered by hosts that support it. Newer extension; host support varies. - **AG-UI:** an open protocol for streaming agent state and UI events to a front end. Young; a transport, not a screen description. - **A2A:** agents handing work to other agents (also dimension 3). Young; pin versions. - **UI hints in the declaration:** the agent describes a preferred layout; clients that understand it use it and others fall back to chat. A small convention, carried as an optional extension (C-014). **PAA vs implementation.** - **PAA should require:** everything under Covered today (channels are clients attached through the Gateway; conversations from every channel are kept in Your Memory; presentation is declared, an agent's own screen is an external client, and a second generic client proves conversational portability), plus: an approval a channel cannot show waits or expires and never auto-approves; and channel bindings (bot tokens, addresses) are connections under dimension 8, with records in the protected part and secrets in the never-disclosed part. - **Implementation choice:** which clients and channels ship, how screens are described (MCP Apps, AG-UI or declaration hints), and how approvals look. - **BrainDrive's choice:** experts are Conversational and chat-first, so any client works, with the terminal as the second-client proof. The expert page layout (sidebar, files, capabilities) is optional UI hints in the plugin declaration; BrainDrive's web client uses them and other clients fall back to chat. Telegram, email and other channels come later as clients through client adapters. ### 12. Installation and compatibility information *(reviewed 2026-10-27)* **What it is.** What lets an agent come into Your Memory safely and tell the owner, before it is active, what it is, what it needs and what will not work. Bringing an agent in (installing, receiving a share, translating one from another product) and updating it are the moments this matters. A partial setup is reported as partial, never treated as fully working. **Covered today: not in the PAA repository, but most of this component is in the Agent Contract.** In the PAA repository: PAA confirms tools are present and working but leaves installation to the environment, and packaging is a product convention (D49). In the Agent Contract: the declaration (§6) carries identity, contract version, resources, tools, context, data, presentation, compatibility, trust, lifecycle and evidence. Before first activation and before a material update, the owner can see source and provenance, outcome, presentation, executable content and its effects, requested context, permissions, credentials and destinations, data handling, dependencies and degraded modes, and known limitations (H-007, AJ-1). Required fields, version ranges, references and integrity are validated without running agent content (H-006); a missing required capability blocks activation with a typed result, and a missing optional one selects only a declared degraded mode without widening authority (C-015, C-016); every compatibility dimension has a declared range (C-062); unknown required extensions are incompatible, and unknown optional ones are ignored and preserved (C-014). Lifecycle has observable states from discovered and inspected through available, active, paused, completed, disabled, updating, failed and removed, with illegal transitions rejected (§9, C-023) and each material transition recorded (C-024). Trust lanes are owner-authored, built-in, reviewed first-party and third-party, with no first-party exemption from authority or data boundaries (§8, C-020 to C-022). An update is assessed for compatibility, data migration, customization conflicts and authority expansion before activation, with a safe recovery path (C-063, C-064); removal stops authority but keeps owner data (C-025, AJ-7); reinstalling is a new trust event (C-026). **Gaps:** in the PAA repository, installation and packaging are not defined. **Options.** - **The Agent Contract's declaration with a BrainDrive encoding:** the contract standardizes meaning, not one wire format; an implementation profile supplies the encoding (§6). - **Agent plugin package / Agent Skills:** the likely encoding (dimension 1); maps onto the declaration fields. - **OCI image metadata, SPDX or CycloneDX:** inventories of components and licenses for agents that carry code. - **OASF (AGNTCY):** capability metadata for discovery; does not prove a capability works. **PAA vs implementation.** - **PAA should require:** everything under Covered today (the Agent Contract's declaration, inspection, validation, negotiation, lifecycle, trust-lane and update rules, carried into PAA with "app" renamed "agent"), plus, new in this framing: the same checks run when a component is swapped (a new Agent Loop, Auth or model is checked against every active agent's declared needs, and affected agents are reported); and an agent translated in from a non-PAA product arrives in the owner-authored or third-party lane, never as built-in. - **Implementation choice:** the declaration encoding, package format, acquisition flow and how inspection looks. - **BrainDrive's choice:** the agent plugin package, wrapping Agent Skills folders, as the encoding of the declaration (following the open plugin standard, agreed 2026-10-27), with the inspection screen before first activation and on material updates. First-party experts follow the reviewed first-party lane, with no exemption. ## Requirements across every case These apply whichever case is happening: a component attached or swapped, an agent coming in, a copy going out, or Your Memory re-housed. ### A. Integrity and provenance *(reviewed 2026-10-27)* The owner can check where an agent and its parts came from and whether they were altered, and where each piece of content in Your Memory came from. **Already in the Agent Contract:** four trust lanes (owner-authored, built-in, reviewed first-party, third-party) with no first-party exemption (§8, C-022); nothing agent-supplied runs before trust and owner-authorization decisions (C-020); the activated version is bound to the exact resources, tools, client content and migrations evaluated (C-021); every item is treated by its trust class, not its display name (C-066); and shared outputs keep their provenance (C-056). **Options:** Sigstore, in-toto and SLSA for signing and build attestations; SPDX or CycloneDX for component and license inventories; W3C PROV for content lineage; Nostr or DID signatures for an owner- or publisher-signed declaration (dimension 7). Authentic bytes can still carry malicious instructions, and public transparency logs must not receive private data by default. **New:** a copy going out carries its provenance and the sharer's signature where offered; an agent translated in from another product records its source as the import, never as built-in. **BrainDrive's choice:** first-party experts follow the reviewed first-party lane; the signing mechanism is chosen with the plugin encoding. ### B. Data handling *(reviewed 2026-10-27)* Every item in Your Memory carries a sharing level (shareable, private, never disclosed) with per-item rules underneath, and derived data inherits the level of its source (see Purpose). **Already in the Agent Contract:** every durable data class declares meaning, provenance, retention, export, migration, sharing and deletion (§14); removing capability, revoking authority, keeping data, deleting data and keeping owner-held exports are separate operations (C-053); sharing is a separate owner-authorized action, never implied by installation or common ownership (C-057), and the receiver gets only what was selected (C-058); context, persistence, logging and external transmission are minimized to the declared purpose (C-068); and errors, logs and evidence never expose credentials, hidden instructions, raw private content or private paths (C-060). **New:** the sharing levels as the owner-facing model; third-party information in the owner's Memory follows the rights it came with; and a copy going out is checked against the levels before it leaves, with anything private or never-disclosed excluded and reported. ### C. Safe changes *(reviewed 2026-10-27)* Replaces "safe handover". Nothing hands over between systems, because Your Memory stays the same memory; what needs care is swapping a component, attaching a second one of the same kind, or re-housing Memory while work is running. **Already in the Agent Contract:** paused, disabled, removed or replaced sessions keep no reusable stale authority and freshness-bound actions reject replay (C-042); a possibly duplicated consequential action is reconciled or idempotency-protected before retry (C-048); lifecycle transitions are validated and recorded (C-023, C-024); and an update keeps a safe recovery path (C-064). **New:** each scheduled run and each task step with outside effects takes effect at most once, however many schedulers or runtimes are attached or swapped (dimensions 6 and 10; leases, fencing and deduplication are implementation choices); outside services send events to the owner's address, so swapping a component never needs them re-pointed; a component being retired finishes, pauses or gives up its leases before its replacement takes over; and when Your Memory gets a new home, the never-disclosed part goes with it under the owner's key. ### D. Verification *(reviewed 2026-10-27)* After any change, the owner can see what works, what is missing and what was not checked. **Already in the Agent Contract:** a minimum evidence set covering declaration validation, trust, activation and resume, tools and revocation, owner-data export and removal, errors and ambiguous completion, and end-to-end owner journeys (§19); evidence tied to an immutable candidate (C-071) and to exact requirement IDs (C-072); no self-certification of a mature claim (C-071A); the terminal second-client proof (C-073); and the reviewer journey (AJ-8). Checks are evidence for the intended use; they cannot guarantee every future behavior. **New:** after a component swap, a short check of every active agent's declared needs against the new component (dimension 12), with a report of affected agents. ## Open questions To settle in this discussion. 1. **Trusting a replacement Auth.** How is a new Auth trusted before it reads the protected part, and how does the owner recover if the old Auth is gone or compromised? 2. **Owner presence.** Under D190 the AI acts as the owner, so "owner presence" for administrative changes needs a distinct owner session or step-up check; what form, and when? 3. **Protected-part data rules.** Schema and versioning, atomic updates, rollback, conflicts across devices, backup and deletion. 4. **Secret custody.** The broker interface, rotation, revocation, audit redaction, disaster recovery, and what happens if the owner loses the master key. For owner-registered apps, provider rules bite: GBrain's repo notes that Google revokes refresh tokens after 7 days for OAuth apps left in Testing mode, so owner-registered apps need a path out of Testing and a refresh-health warning (GBrain warns after 5 days without a successful refresh). 5. **Spending limits.** Reservations and settlement, refunds, pending transactions, currency conversion, and preventing a tool from spending outside the limit check. 6. **Derived data.** How mixed-source items are classified, how a level is lowered, and how deletion reaches indexes and caches. 7. **The app-to-agent and host-to-implementation renames.** The exact versioned change to the Agent Contract and its companion specifications, and their ID aliases. ## Next step Discuss here. Agreed items become a requirement table (ID, statement, current source, existing, amended or new, dependencies) proposed for PAA after v1.0. The standards and open-source projects named under Options were researched against their primary sources; ask in the thread for any source.