Status and Readiness

General Augment is the agent control plane for apps that need /v1/responses, project-scoped API keys, governed tools, memory, usage controls, and the hosted GCP-first runtime. It is the production path for app-developer backend integrations and Spark-style project agents.

This is the public product and engineering readiness statement for third-party developers. Customer-specific SLAs, DPAs, BAAs, invoices, retention schedules, and regulated attestations live in signed Enterprise terms or customer diligence packets. It is not a signed service-level agreement. DPA and BAA templates, legal terms, and customer-specific attestations require signed customer review.

Public surfaces

Surface	URL or path	Current posture
Developer docs	https://docs.generalaugment.com	Live public docs for app developers.
Dashboard	https://app.generalaugment.com	Live, with protected project setup surfaces.
API	https://api.generalaugment.com	Live hosted API for backend calls.
App readiness	GET /health/ready	Current hosted app-polling source of truth.
Operator health	GET /health/detailed	Operator/smoke-test provider and dependency view.
Public status page	https://status.generalaugment.com	Vercel-hosted page with a same-origin /api/status health summary.
Support	support@generalaugment.com	General Augment developer support path; formal SLAs are available through signed Enterprise terms.

Apps should poll GET /health/ready (https://api.generalaugment.com/health/ready) for request-serving readiness and keep response IDs, trace IDs, and idempotency keys in app logs for support. GET /v1/health is the v1-prefixed compatibility readiness path. The public status page is the human-facing view; the status smoke checks the status page, both API health paths, docs, and dashboard.

Integration-ready today

• POST /v1/responses for backend-originated app turns with project-scoped API keys.
• Portable model tiers: simple, balanced, and complex.
• Stable user scoping through the user field.
• Response IDs, trace IDs, token usage, latency, model metadata, and cost metadata when available.
• W3C traceparent and tracestate propagation.
• Installed CLI verification with explicit project_key_execution status: PASS when the configured project-scoped key calls /v1/responses, SKIP when only project-key existence was verified from broader admin auth.
• Semantic SSE event streaming.
• Memory store, search, profile, single-memory delete, and user-memory purge endpoints.
• Project API key creation, masked listing, updates, and revocation.
• Usage rollups, daily counters, plan limits, budget gates, and stable 402 / 429 error reasons.
• Tool registry, generated OpenAPI-backed tools, MCP-backed tools, tool policy, audit rows, and approval flows.
• Local mock testing for Responses and memory contract tests.

Commercial readiness

General Augment records technical metering: usage events, daily usage rollups, per-turn metadata, budget gates, usage-threshold webhooks, usage-credit reservations, settlement, refunds, cancellation releases, and optional Stripe meter export when configured.

The launch packaging in Pricing is the General Augment self-serve rate card for implementation and controlled launch packets. Hosted Stripe Checkout handoff for Build/Pro/Team, hosted credit top-up Checkout handoff, hosted Stripe Customer Portal handoff, webhook-backed checkout activation, cancellation downgrade, invoice history, payment-failure events, subscription-included credit grants, paid-top-up credit grants, billing exports, and auto top-up preflight history exist when Stripe is configured. Live-card collection is promoted after live production Price IDs, Stripe secrets, checkout/webhook smoke proof, purchase-order workflows, and billing policy checks are attached to the customer launch packet. Automatic off-session auto top-up charges stay disabled unless the project explicitly accepts them. This is not a complete customer billing lifecycle until live Stripe artifacts, signed terms, support process, refund handling, and customer-specific launch evidence are attached.

The V1 self-serve package is Free, Build, Pro, Team, and Enterprise. Free, Build, Pro, and Team plans have finite daily agent-turn, tool-call, and token gates in the backend. Operators can adjust known limits through validated runtime configuration, but invalid or unlimited public-plan overrides are ignored.

For production customers, commit the billing mechanism, included usage, overages, payment terms, support level, and any rate window in a signed agreement or explicit manual operator process before launch.

Security and compliance posture

The hosted launch baseline runs in Google Cloud us-central1 and uses managed encryption at rest. Project API keys are hashed before storage, and raw provider credentials or OAuth tokens are kept in Secret Manager or the General Augment credential vault.

Current enterprise options to understand before launch:

• Customer-selectable region pinning, EU-only residency, and multi-region active-active residency are Enterprise deployment options handled through a customer launch packet.
• Customer-owned model-provider key custody is available for governed model routing and is the production default for cost-bearing model capacity, but every launch that uses it needs project-specific provider smoke before General Augment claims the route is launch-ready. Customer-managed encryption keys, customer-controlled key destruction, and contractual key-custody guarantees are Enterprise deployment commitments captured in signed terms.
• SOC 2, ISO 27001, HIPAA, DPA, BAA, audit rights, contractual incident response, and customer-specific retention commitments are handled in customer diligence and signed Enterprise terms.
• HIPAA mode is a technical guardrail for health-data workflows; production regulated claims are made from the accepted customer agreement and launch packet.

See Security for the full region, deletion, training-use, credential, and DPA/BAA posture.

Deletion and retention

Customer-facing memory deletes and user-memory purges remove scoped memory rows from the primary database after the request commits. Admin user deletion removes the selected General Augment user row for the project and cascades database rows linked through foreign keys. Project archive is a status change, not a hard delete. Project owners and admins can record support-reviewed project deletion requests with export evidence; irreversible project deletion remains operator-reviewed.

For the current GCP launch baseline, Cloud SQL automated backups and point-in-time recovery keep seven retained backups and seven days of transaction logs. Deleted primary data can remain recoverable inside backups/PITR for up to that configured seven-day window. Broader purge, backup-destruction, or regulated deletion guarantees belong in signed retention terms.

Spark and third-party launch guardrails

Before promising a production Spark or third-party launch, capture or explicitly accept:

• Public status page: keep https://status.generalaugment.com green in status smoke before treating the page as launch evidence.
• Commercial mechanism, rate window, overages, support tier, and which customer-owned provider/API accounts pay model, channel, and tool costs.
• Burst capacity: current evidence supports controlled low-volume General Augment customers, including the 90 req/min controlled customer launch profile. Higher sustained burst commitments must prove the selected provider path. For customer-owned capacity, the burst artifact must show customer-provider attribution for every successful response and attach non-secret provider quota evidence. For platform-managed capacity, General Augment attaches successful recorded burst artifacts, autoscaling evidence, provider quota confirmation, and Vertex quota evidence records to the launch packet. Publish sustained capacity claims only when a matching capacity evidence artifact passes.
• Commercial/compliance package for DPA, BAA, SOC 2/ISO, residency, deletion, retention, incident response, and training-use language when those commitments are in scope.
• Optional provider verification for every provider included in the launch package.
• Named owner, shared blocker board, weekly partner sync, and sanitized repro process.
• App-developer onboarding proof: run genaug agent test <agent> --user <user> --json after each Candidate change and retain the exact release-pinned hosted evidence.
• Trace/support-bundle proof: verify returned trace IDs can be retrieved and match response ID, app user, model, usage, caller metadata, SOUL/skill evidence, and tool-call audit behavior. Controlled customer launch packets require explicit skill trace evidence from the multi-user behavior smoke, not only final-answer text.
• Memory behavior: use hosted Agent tests plus genaug user memory list/search to prove exact namespace grants, per-user isolation, recall, correction, and deletion. Final-answer text alone is not release evidence.
• CLI/SDK compatibility: compare installed genaug --version, SDK package versions, docs version copy, and API health/build metadata in the launch artifact. Controlled customers can use installed packages, repo-local packages, or local package artifacts according to their deployment environment.

Useful next reads: Developer Support, Roadmap and Intake, and API Stability.