---
name: applied-agent-platforms
description: 'Use when designing, building, or operating self-hosted agent platforms that let Hermes or similar agents control external systems: multi-tenant Hermes control planes, Android/cloud-device agents, paid-ads operators, and polished chat/onboarding surfaces. Covers architecture, provider/auth flows, dashboards, approvals, safety guardrails, mobile UI, and verification.'
version: 1.2.18
author: Hermes Agent
license: MIT
metadata:
  hermes:
    tags: [agent-platforms, hermes, multi-tenant, android, paid-ads, chat-ui, dashboards, approvals, provisioning]
    related_skills: [vps-app-deployment, subagent-driven-development, requesting-code-review, chat-interface-development, paid-ads-agent-platforms, hermes-tenant-control-plane, android-cloud-device-agent]
---

# Applied Agent Platforms

## Overview

Use this umbrella skill for productized agent systems where Hermes (or a Hermes-like agent) is not just answering questions but operating a real external environment: tenant containers, cloud Android phones, ad accounts, dashboards, approval queues, onboarding wizards, and chat-first product surfaces.

The common class is: **agent brain + deterministic adapters + visible cockpit + guarded side effects**. The old narrow skills absorbed here are preserved under `references/absorbed/` for full session-specific detail.

## When to Use

- Building Astral Hermes / Hermes Spawn style multi-tenant control planes.
- Building an agent that controls persistent Android/cloud-phone environments via ADB/Appium/provider APIs.
- Building a paid-ads operator with Meta/Google/TikTok APIs, local drafts, approvals, and spend-safety guardrails.
- Polishing production chat surfaces, voice input, SSE progress, mobile drawers, onboarding wizards, or productized assistant UX.
- Designing a new vertical agent platform with provisioning, auth, dashboard, audit logs, and guarded execution.

## Core Architecture Pattern

```text
User chat / dashboard
        ↓
Hermes orchestration layer
        ↓
Local app API + DB + audit log
        ↓
Deterministic adapter(s): Docker/SSH, ADB/Appium, Ads API, storage, provider OAuth
        ↓
External system with real side effects
```

Split responsibilities:

1. **Hermes owns orchestration** — natural language, planning, diagnosis, report writing, draft creation, and tool/adapter selection.
2. **The app owns durable state** — tenants, threads, provider auth status, drafts, approvals, jobs, reports, audit events.
3. **Adapters own side effects** — Docker/SSH, provider APIs, ADB, Marketing API, S3, billing, Telegram.
4. **Dashboard owns visibility** — queue state, logs, health, approvals, preview cards, smoke-test results.
5. **Humans approve risky actions** — spend, activation, delete, provider credential changes, and account-affecting mutations.

When deciding whether capabilities should be modules, standalone apps, or separately deployed workers, do not treat those as mutually exclusive categories. Decide **authority**, **user surface**, and **execution boundary** independently; use activation manifests for focused product editions rather than code forks. Audit legacy-to-module ports through real routes, persistence, approvals, dispatch, reconciliation, agent tools, tests, and historical artifacts before retiring the legacy authority. See `references/module-app-service-product-boundaries.md` for the decision framework, capability-port audit, campaign-spine pattern, edition model, and retirement gate.

Before proposing an “integration” around a legacy standalone app, explicitly distinguish **historical origin**, **current runtime authority**, and **proving-lab/focused-edition role**. Inspect migration code and target tables/routes/tools before assuming the standalone is still external or the port is complete. A brief or context pack is a pinned view derived from canonical state, not a replacement for the authority that produced it. See `references/ported-capability-lineage-and-authority.md` for the source-first audit, focused-edition pattern, parity classifications, and Creative/Vault example.

For a product that is fundamentally a **Hermes coordinator plus vertical business capabilities**, use a dual-control design: skills encode judgment, typed tools expose actions, modules own canonical state/enforcement, and rich Studios let humans inspect or operate the same commands. Prefer one coordinator invoking specialist reasoning/tools over a bureaucracy of persistent module agents; retain a thin durable state spine outside chat. Human REST routes, Hermes plugin tools, policies, schedulers, and handoffs should all call one actor-aware domain command layer. Do not mistake a skill full of curl examples for first-class Hermes tool integration, and do not accept a human-rich/agent-poor parity gap. When one customer account contains several independent businesses, keep one customer tenant stack but use one portfolio Hermes profile plus one isolated Hermes profile/home per business; share the versioned plugin and skills, not sessions, memory, cron, credentials, temporary workspace, or business data. Prefer the native Hermes plugin as the primary product path; keep MCP as an optional interoperability adapter over the same commands. See `references/hermes-native-dual-control-modules.md` for the layer model, profile isolation, plugin/MCP choice, parity audit, collaboration UX, safety boundary, and legacy cutover gate.

When agents need fresh knowledge of a fast-changing provider/tool landscape, build a continuous capability-intelligence service rather than embedding a volatile catalog in skills or one consumer app. Use deterministic collectors, a provenance-bearing structured registry, append-only deltas, a private command/API seam, native Hermes plugin tools, and a thin reasoning skill; keep MCP deferred until a real non-Hermes consumer exists. Separate shared provider facts from tenant-local credentials, authorization, health, and execution contracts. See `references/continuous-capability-intelligence-services.md` for evidence precedence, recommendation ordering, seed-import rules, parser pitfalls, real-loader testing, and acceptance checks.

## Labeled Subsections

### Multi-tenant Hermes control planes

Use for Astral Hermes and Hermes Spawn style apps. Preserve the profile/home-per-tenant mental model: each tenant has isolated `config.yaml`, `.env`, `auth.json`, skills, and data. Prefer Docker/container boundaries when productizing. Provider auth must be written in every shape Hermes runtime needs, especially OAuth credential-pool plus runtime provider shapes. Search existing helpers before rebuilding features; these repos often already contain disabled or half-wired code.

When several customer-facing products share the same hosted Hermes machinery, do not duplicate the shared lifecycle control plane per vertical. Keep Hermes Agent Engine (pure profile/config helpers), the private Spawn Platform API (lifecycle), each specialized product's central account/billing/routing service, and each isolated fixed-specialization tenant distinct. Product accounts may remain completely separate even when runtime infrastructure is shared. Provider modes are declared per product, cross-product data sharing is off by default, and specialized customers see branded health/recovery rather than Spawn/container vocabulary. Begin convergence with side-effect-free manifests, service auth, strict request contracts, and an idempotent operation ledger before extracting provisioners or migrating live tenants.

**Do not assume where product domain state lives.** Before designing customer/portfolio rows, choose explicitly between (a) one central product application/database connected to many runtime tenants and (b) a full per-customer vertical stack where the tenant contains the product UI/API, domain database/media, approvals/finance/metrics, Hermes brain, and local hosting-plane entitlement. In the second model, Avalon/central infrastructure keeps only account identity, billing/entitlements, tenant directory/routing, stack profiles, provisioning orders, and aggregate platform state. A single-customer SQLite modular monolith may already be the correct tenant appliance; adding cross-customer `portfolio_id` isolation would move it in the wrong direction. See `references/per-tenant-vertical-stack-redirection.md` for the topology gate, salvage audit, stack contract, and reversible first-instance migration.

When introducing Normal/Pro/Admin product tiers, keep **product account type** separate from tenant-local authorization role. A Normal owner may still be a local admin while server-derived capabilities remove portfolio scope and select a single business home. Preserve old tenants with versioned handoff contracts, defer fresh-tenant profile planning until signed account authority arrives, bootstrap only the topology the tier needs, and make upgrades additive rather than rebinding business history. See `references/account-tiers-and-agent-profile-topology.md` for migration defaults, strict v1/v2 handoffs, tier-dependent Hermes profiles/jobs, server-side scope enforcement, UI behavior, upgrade semantics, and the TDD matrix.

Before writing plans, diagrams, manifests, or public Viewer pages, restate and verify the identity hierarchy explicitly. Do **not** force one universal ordering between portfolio and tenant: first decide whether the product uses a central domain app plus runtime tenants or a full per-customer vertical stack. For a full-stack product such as Caduceus, use **platform → product → product-service identity → customer/account → product instance → full tenant stack → tenant-local portfolio/workspace → business/project**. A customer called the “first user,” “example,” “canary,” or migration target is not thereby a new product or specialization. Existing general-platform customers can migrate into a specialized product as ordinary accounts with that product's fixed profile and server-derived stack authority. If wording is ambiguous, inspect the current product registry and product database, state the proposed hierarchy back to the user, and wait for confirmation before publishing durable architecture. Do not treat a messaging platform’s rough voice transcript as authoritative when product names, hierarchy terms, or homophones are unclear: listen to/transcribe the actual audio, mark uncertain words, and accept a corrected recording before deriving architecture. If the user says “stop” or corrects the classification, halt that branch immediately; retract every wrong derivative (plans, ADRs, diagrams, public pages, tasks, skills, cron prompts, and temporary inventories) before resuming, then create one canonical corrected decision record. Preserve valid shared-platform work that does not depend on the mistaken classification. Run the durable consistency sweep in `references/architecture-redirection-consistency-sweep.md` so source docs, rendered trackers, scheduled prompts, skills, and implementation comments cannot drift apart. See `references/shared-spawn-platform-specialized-products.md` for manifests, boundaries, migration order, hostile-input contract hardening, pinned provider authority, durable idempotent ledgers, safe operator verifiers, and final acceptance gates. When a specialized product already has a live stateful tenant created outside the shared control plane, use `references/existing-specialized-tenant-adoption.md`: keep the product app/system of record distinct from its tenant brain, add an explicit non-destructive adoption operation, snapshot all state planes separately, and never weaken ordinary create safeguards to absorb pre-existing resources.

For provisioning and lifecycle work, advance through explicit proof gates: pure server-derived manifest → durable fake execution/recovery → one local disposable tenant → two isolated local disposable tenants with restore/rollback → reviewed production adapters → authorized canary. A local harness is privileged side-effecting code even when it writes only under `/tmp`: require an explicit temp child sandbox, reject symlinked sandbox ancestors, exact tenant + operation + resource ownership on every privileged action, physically tenant-local namespaces for tenant-local sessions/credentials, no raw synthetic secret persistence, reconciliation-before-retry, and health/PID/cmdline proof before signaling a restarted worker. Central projections must validate the entire canonical manifest rather than accepting a valid-looking fragment from a forged object. Backup restore must verify tenant-bound manifest/catalog/payload checksums before live replacement. If the gate says concurrent, use actual overlapping operations plus serialized shared-metadata read/modify/write and repeated stress runs; if it says both restore independently, destroy/restore A and B separately while preserving the neighbor's payload and route evidence. A green test stream is not accepted until the runner exits normally with no harness child processes. See `references/durable-multi-tenant-lifecycle-proofs.md` for the full manifest-authority, disposable-harness, crash-recovery, two-tenant isolation, backup/restore, operator-access, hung-runner, and zero-residual proof matrix.

For an architecture-resolution conversation, ask one consequential decision at a time and persist each accepted answer immediately. Recommended order: platform product role → fixed/composable tenant specialization → customer account/billing boundaries → central versus duplicated lifecycle ownership → platform visibility → provider policy → cross-product data sharing → vertical-specific topology/security → integration sequencing → first engineering program. State the tradeoff and recommended default before presenting choices; distinguish temporary owner-only shortcuts from launch-safe boundaries.

When tenants need host-level deployment, treat that as a deterministic adapter—not a reason to pierce the container boundary. Use a tenant-token-authenticated deploy broker with exact domain/app/path allowlists, safe artifact extraction, broker-owned proxy templates, durable status, and a dedicated host service account per tenant. Never run tenant app code as the shared host operator account. Long deploys must return a queued ID and expose status polling rather than holding an HTTP request open through package activation, DNS checks, and certificate issuance. DNS/TLS status is per-hostname: partial propagation should produce explicit ready/pending lists and a partial-live state.

When auditing a hosting plane against a **local-plus-external provider model**, distinguish the local broker from future/external provider adapters such as Vercel, Supabase, Railway, and customer VPS via scoped SSH. A Developer/infra module that only records deployment metadata is not a hosting plane until it can build/sign artifacts, submit through provider adapters, poll status, and reconcile results into durable infra records. External provider credentials belong in the product-side vault/capability broker, not tenant `.env` or chat, and provider access should be scoped to exact projects/teams/hosts/capabilities. See `references/local-plus-external-hosting-plane-audit.md` for the reusable audit checklist and reporting table.

For a coding/deployment agent, model **workspace target**, **execution target**, **deployment target**, **source remote**, and **data provider** separately. Prefer managed shared hosting first, managed dedicated as the primary upgrade, then GitHub/data/deployment adapters; defer BYO VPS until those contracts are stable. Owner access described as a “backdoor” must become a visible, auditable, admin-only execution target with target-specific role grants, an allowlisted workspace root, pinned host identity, and a vault/broker credential reference. Keep mutable repositories, build scratch, immutable releases, and persistent runtime volumes separate. When speed matters, use focused changed-boundary tests plus one real canary per phase—not broad reassurance loops, but also not schema-only claims. See `references/tenant-developer-workspaces-and-hosting-tiers.md` for target precedence, workspace layout, entitlement fields, admin SSH policy, two-container rationale, and phase acceptance gates.

Key preserved detail: `references/absorbed/hermes-tenant-control-plane/SKILL.md` plus its support references. For the concrete Spawn broker implementation and PM2/DNS/TLS pitfalls, use `hermes-spawn-control-plane` → `references/scoped-tenant-deploy-broker.md`.

### Shared runtimes, identities, and real trust boundaries

Treat persona names, session labels, agent rows, and scoped API keys as **logical identities**, not isolation, until the runtime proves otherwise.

- If one container stores several role keys in the same `.env`, and its agents have file or terminal access, every role can potentially read and use every key.
- Toolsets such as browser, terminal, and file are commonly profile- or tenant-wide. Enabling a browser for a “Registrar” does not make it Registrar-only merely because the prompt says so.
- Enforce authorization server-side with a capability matrix: role × project × module × action. A project-scoped check is not enough to prove a Social agent cannot call Ads or money routes.
- Inject only the active role's credential per invocation/session where possible; do not persist every role credential in a shared tenant home.
- Put browser automation, payments, account creation, and other high-risk hands behind deterministic adapters with allowlists, screenshots, budgets, and audit records. For materially different risk levels, prefer a separate restricted tenant/runtime.
- Verify boundaries adversarially: cross-module calls, cross-project target IDs, one agent signing another agent's contract, cumulative contract-cap bypass, and role escalation.

High autonomy should be enabled by stronger deterministic boundaries, not by trusting persona instructions. See `references/mid-plan-agent-platform-audit.md` for a practical reconstruction and verification workflow.

### Governed external SaaS capabilities

When a tenant needs a powerful third-party SaaS tool for enrichment, research, CRM, communications, commerce, ads, or finance, put a **product-side capability broker** between Hermes and the vendor. Prefer the vendor's documented API for normal production workflows; reserve broad MCP/plugin/CLI access for an isolated builder/admin worker that designs or validates vendor-native workflows. Publish proven workflows back as named, versioned, allowlisted capabilities instead of leaving raw vendor tools permanently exposed.

Use tenant-specific workspaces and credentials, inject secrets per invocation, and pin allowed routine/function/table/webhook/target IDs. Stage rollout as metadata/status → bounded reads → approved paid computation → draft outputs → controlled writes → separately approved activation. Persist async jobs, verify signed webhooks but retain polling reconciliation, honor provider rate-limit headers, and attribute estimated/actual credits or cost to tenant/project/workflow. Vendor enrichment enters the knowledge layer as provenance-bearing evidence—not unquestioned truth—and generated outreach remains a draft.

See `references/governed-external-saas-capability-brokers.md` for the risk ladder, audit schema, PII/evidence rules, async/retry discipline, verification checklist, and a Clay-derived example.

### Cloud Android device agents

Use for persistent mobile test/automation agents. Keep Hermes on the VPS/host and treat Android as the controlled target. Prove lifecycle, screenshots, shell, ADB connect, input primitives, UI hierarchy, app install/open, and persistence before adding vision loops. Never build spam/evasion/account farming; use owned test accounts and respect CAPTCHA/manual-login boundaries.

Key preserved detail: `references/absorbed/android-cloud-device-agent/SKILL.md`.

### Paid ads agent platforms

Use for ad-ops systems. Read-only first, local drafts second, approved paused writes third, active spend last. Mirror the ad-platform hierarchy locally, keep tokens out of logs/git, separate **Approve locally** from **Push to platform as PAUSED**, and maintain explicit spend/action guardrails.

Key preserved detail: `references/absorbed/paid-ads-agent-platforms/SKILL.md`.

### Realtime voice/avatar agents

For browser experiences that turn a prerecorded or static presenter into a realtime conversational avatar, separate provider conversation mode, media transport, decode readiness, compositing, microphone state, and truthful UI status. Do not treat a subscribed MediaStream, provider transcript, or `SESSION_STREAM_READY` event as proof that the user saw a moving frame. Keep the attached LiveKit source video full-size with `visibility:hidden` so adaptive streaming continues; a 1×1 or `display:none` source can leave the remote video track muted even while the provider successfully speaks. Stabilize React session effects with callback refs because provider tokens are generally single-use, and derive “speaking/listening” labels only from real SDK events. Require a bounded first-frame gate and one real-device canary before calling the experience live.

For this user's realtime pitch experiences, default to **conversation-first handoff**: begin provider token/session work at the same moment the user starts the experience, play a real video cover for about five seconds, then reveal the live persona as soon as a decoded frame exists. Do not make the visitor wait through a long fixed presentation before connection begins. If supplied media is longer but its complete edit matters, retime it to the requested cover duration rather than blindly truncating the identity-matching final pose; preserve audio and export the exact final decoded hold frame.

Provider-specific integration must follow the current SDK's native proof event. For Anam, keep the durable API key server-side, exchange it for a short-lived token bound to a stateful `personaId`, register listeners before `streamToVideoElement()`, and use `VIDEO_PLAY_STARTED` as the reveal gate. `SESSION_READY` alone is not first-frame proof. If the provider supplies a clean full-frame persona scene, render the native video directly instead of forcing a green-screen/WebGL architecture designed for another provider.

See `references/realtime-voice-avatar-webrtc.md` for mode selection (FULL, raw LITE, hosted connectors, and Anam stateful personas), token security, five-second parallel-loading handoffs, hidden-video/WebGL architecture, adaptive-stream CSS, duplicate-session prevention, microphone/autoplay handling, evidence interpretation, and cost-capped canaries.

### Chat, onboarding, and UX surfaces

Production agent platforms need polished chat UX, not just working endpoints. Mobile is the truth surface. Voice notes must move end-to-end from recorder → upload → transcription → same chat pipeline → response. Assistant messages default to full-width unbubbled; user/audio/error messages keep containment. Long-running replies should stream real progress via SSE. Onboarding should be Typeform-style: one screen, one decision, one primary CTA.

When the user asks for the **absolute minimum signup**, minimize collected information—not merely the number of screens. For a product that can use discoverable WebAuthn credentials, consider a zero-field passkey flow: one Create action, automatic account/tenant naming, truthful provisioning progress, then a short-lived one-time tenant handoff. Do not default to email magic links when email is unconfigured or when an identifier is unnecessary. Keep unsupported-WebAuthn recovery accessible but secondary, and never silently reintroduce email, password, username, tenant name, plan, or invite-code fields into the primary path. See `references/zero-field-passkey-tenant-onboarding.md` for the central/tenant boundary, gated production executor composition, asymmetric handoff, TDD matrix, and disposable acceptance lifecycle.

For conversational onboarding, define an exact minimum field allowlist and tell the agent to gather only those fields in the most elegant, direct, functional way possible, completing as soon as it judges them present. Do not force a turn count or let the model add “helpful” discovery questions. Keep the composer enabled and focused through Enter/tap sends and non-complete responses so mobile keyboards remain open; disable only duplicate submission. See `references/spatial-conversational-onboarding-and-provisioning-truth.md`.

A chat-first coordinator must remain naturally steerable while it works. Never disable the composer as the busy-state policy. Use a transport with real run cancellation/steering, preserve role alternation when an interruption settles, and keep rapid follow-ups attached to the same thread. Treat stopping the active run and serializing the next turn as separate controls: a per-thread start queue must be acquired before persisting follow-up input so two messages released by the same cancellation cannot start concurrently. Convert explicit reply directives and ordinary bracketed choices into one-click sends while preserving a visible free-text “Something else…” path. Approval chips should identify and open the exact review object, with legacy destination aliases handled explicitly. Background execution must remain visible in chat by durable run ID/status and must re-enter the thread on completion or failure; “no action needed” is acceptable only when verified work is running and a completion callback exists.

Use `references/interruptible-agent-chat-coordination.md` for the Runs API interruption pattern, history normalization, option/review actions, automatic coordinator continuation, concurrency hazards, and verification matrix.

For onboarding that visually behaves like a canvas—completed stages collapsing into connected breadcrumb nodes while a phone-width adaptive chat remains active—use `references/spatial-conversational-onboarding-and-provisioning-truth.md`. It covers desktop/mobile stage geometry, privacy-bounded transcript handling, signed short profiles, provider JSON-schema retry/repair, real route/TLS readiness, end-to-end canaries, and avoiding partial live deploys when static files are served directly from a mutable worktree.

When provisioning time should become useful product setup rather than a passive wait screen, use `references/reactive-project-seed-onboarding-handoff.md`. It covers a shared real canvas renderer, truthful proposed nodes, early passkey timing, optional structured Business Brief extraction, Meta/provider intent that remains distinct from authorization, project-bound tenant OAuth and redirect/secret boundaries, tier-aware Normal/Pro topology, Business-Coordinator/Creative identity, bounded ProjectSeed patches including cross-origin draft continuity, readable route slugs bound to immutable tenant identity, transfer selection based on whether a real authenticated backchannel exists, exact-origin v3 form POST when it does not, idempotent canonical import with provenance, project-scoped Coordinator/profile readiness, privileged route-helper gates, mobile single-chat ownership, separate rollout proof gates, and visually continuous hydration into the live tenant.

Key preserved detail: `references/absorbed/chat-interface-development/SKILL.md`.

### Approval-to-execution dispatch

Model proposal, approval, dispatch, running, implementation completion, deployment, and public activation as separate durable states. Never infer execution from an approved review, a planned persona/module row, an audit message, source comments, or API copy that promises release. Trace the submission endpoint through review-decision hooks into a real idempotent dispatcher, worker adapter, repository/worktree, progress stream, and completion evidence. Verify the supposed worker's actual filesystem and authority: terminal or delegation in an isolated empty tenant does not provide access to the product repository or deployment host. Verify “scheduled follow-up” claims against both the application queue and the agent runtime scheduler. Keep provider synchronization, product-development dispatch, tenant-stack provisioning, and public activation as distinct execution planes.

Preflight executor authentication and workspace authority before claiming a durable run. If a preferred executor fails before mutation, preserve the same run identity and allow only a typed, audited fallback; the fallback is incomplete until a tested `failed|blocked → queued` retry transition exists. Never create another work order/run to route around a launch failure. Treat a worker-produced commit/tests as implementation evidence, not deployment evidence.

Use `references/approval-to-execution-dispatch-verification.md` for the investigation sequence, minimum start evidence, safe dispatcher contract, retry/fallback state transitions, and precise reporting language.

### Agent workspace → canonical UI projection

When an out-of-process Hermes/coding worker changes a repository, do not assume the platform's canvas or dashboard will reflect the filesystem. Separate **execution evidence** (run/log/commit/tests), **artifact truth** (products, surfaces, repositories, services, explicit removals), and **activation truth** (verified public deployment). A successful worker should emit a bounded versioned artifact manifest with stable project-scoped keys; validate and idempotently reconcile it into canonical domain tables, then let the UI derive its nodes from those tables. Mark code-only results `built`, never `live`; preserve explicit removals as tombstones and filter them from the projection rather than guessing deletion from absence.

Process-local emitters do not cross worker/server boundaries. Back the browser's SSE with a durable outbox/event bus, or use bounded canonical-state polling as a correctness backstop. Existing successful pre-manifest runs should be recovered through a database backup, independent commit/test/build proof, and a one-time manifest passed through the same reconciler—not decorative hand-inserted canvas rows. See `references/agent-workspace-canonical-ui-projection.md` for the manifest shape, reconciliation rules, cross-process freshness options, recovery procedure, and verification matrix.

### Financial-authority agent platforms

Use when agents can spend money, pay vendors/contractors, operate bank accounts, use cards, or touch crypto/treasury. Treat the agent as a **software/electronic agent under human-officer authority**, not as the LLC's legal signer, employee, beneficial owner, bank user, or payroll worker. Keep bank/KYC/tax records anchored to verified humans or legal entities, and implement an authority ladder: read-only → draft-only → approval queue → capped card spend → approved-vendor bill pay → tightly capped bank/ACH movement → multisig/capped crypto. Do not share human bank credentials with the agent or automate a banking UI without the provider's written/API permission; use provider roles, approval policies, cards, and limits. New payees, payment-instruction changes, contractor classification, payroll/tax filings, crypto addresses, international transfers, sanctions/AML flags, and threshold breaches require human approval.

Key preserved detail: `references/autonomous-financial-authority.md`. For the July 2026 provider landscape, hybrid bank/card/stablecoin architecture, Payment Governor pattern, and pilot limits, see `references/agent-financial-stack-july-2026.md`.

### Founder-led go-to-market and packaging

For a persistent agent operating platform, treat the business/workspace as the natural billing unit: subscription covers the durable stack and orchestration, while expensive production is metered and customer ad/vendor spend remains customer-direct by default. Start with existing businesses and a small paid design-partner cohort, deliver one measurable operating loop, and turn the evidence into case studies before broad self-service. A creative technical founder who over-serves prospects should diagnose freely but implement only inside a paid container; use a sales producer to enforce qualification, follow-up, and boundaries before giving a salesperson equity or perpetual revenue share. Do not publish exact prices from architecture reasoning alone—test private bands against real stack cost, support time, outcomes, and willingness to pay. See `references/founder-led-go-to-market-for-agent-platforms.md` for founder-role design, the anti-free-work constitution, alternative revenue models, documentary marketing, collaborator sequencing, and scale gates.

## Safety and Verification Checklist

- [ ] External side effects are behind deterministic adapters with logged inputs/outputs.
- [ ] Risky mutations require explicit approval and exact target identity.
- [ ] Auth/credential writes are verified from the runtime path, not just config files.
- [ ] Dashboard or logs show queued/running/completed/failed work.
- [ ] Mobile/chat UX has visible async states within ~100ms.
- [ ] Build/tests/smokes run before deploy or user handoff.
- [ ] User-facing copy hides infrastructure words unless in admin/debug context.

## Common Pitfalls

1. **Agent-only state.** If progress exists only in a chat transcript, the platform cannot recover or audit it. Persist tasks, approvals, and reports.
2. **Dashboard as afterthought.** Operators need a cockpit for queues, health, previews, and audit trails even when chat is the primary control surface.
3. **Skipping read-only proof.** Always prove account/API/device access before creating drafts or mutations.
4. **Conflating local approval with platform execution.** Approval queues must distinguish approved local drafts from pushed external objects.
5. **Silent async UI.** If the agent/tool takes seconds, stream progress or show factual stalled-state captions.
6. **Credentials in logs.** Tokens, Google accounts, provider OAuth, screenshots, and ad account data are sensitive.
7. **Promoting a customer into a product.** A named customer, portfolio, migration target, or first real user remains an instance inside its product unless the user explicitly defines a new customer-facing product with its own account/billing/provider/profile boundary. Never infer a manifest or service identity from a customer name.
8. **Publishing before hierarchy confirmation.** When product/platform/customer language is noisy or voice-transcribed, confirm the hierarchy before creating ADRs, diagrams, public pages, migration tasks, or runtime identities. If corrected, retract every incorrect derivative and replace it with one canonical decision record.
9. **Filesystem success with an empty canvas.** A worker commit and green tests update execution evidence, not canonical product/infra/surface truth. Require a validated artifact manifest and idempotent reconciliation; never add a cosmetic UI-only node or call code-only output live.
10. **Process-local “live” updates.** A child worker's in-memory event emission is invisible to a separate web-server process. Use a durable cross-process event path or bounded canonical-state polling.
11. **Research presented as delivery.** Once authentication, entitlement, and one architecture are boundedly validated, move to a running vertical slice. If the user asked to build or deploy, do not spend the remaining iteration budget expanding provider comparisons or an implementation plan while no executable app exists.
12. **Status labels ahead of evidence.** Never show or report “speaking,” “listening,” “live,” or “deployed working” from an attempted command, subscribed track, or optimistic state assignment. Require the provider event appropriate to the claim, decoded media dimensions for visual claims, and a public canary for deployment claims.
13. **Treating the origin app as the current authority.** When a standalone capability was ported into a larger product, do not design an external integration merely because both repositories still exist. Establish origin, runtime authority, proving-lab role, and exact parity gaps from source before drawing topology. Likewise, do not mistake an existing module name for proof of complete parity.