Skip to main content

Privacy Foundation

Privacy Policy that matches the real data flows.

This launch-ready privacy foundation is written as a truthful operating disclosure for AgentAlly. It explains what data categories exist, where they come from, why they are used, when AgentAlly acts in a controller or processor role, which providers touch data, and where retention, deletion, export, and human-access limits still need explicit launch confirmation.

Draft for Counsel ReviewProduct-Truth First

Launch foundation draft for counsel and product review. Contracting-entity details, rights-intake mechanics, queue-cancel behavior, backup windows, and some provider-specific lifecycle disclosures still need final confirmation before public launch.

Last Updated
April 19, 2026
Effective Date
Pending final launch publication
G2 Boundary Note

What this shift owns and what it defers

This document

G2: Privacy Policy and data-governance baseline

Covers categories, sources, purposes, role split, human access, provider classes, training/model-use posture, and the first public retention/deletion/export/backups summary.

Integrated into this draft

G5: Lifecycle semantics

Owns the category-by-category retention bands, deletion workflows, export scope, backup and downstream posture, audit-record treatment, and operator-run lifecycle mechanics.

Deferred follow-on

G6: Vendor registry and incident posture

Owns the fuller subprocessor and AI-provider disclosure page, provider change process, retention-by-vendor detail, and shared-responsibility incident governance.

Section 1

Scope and What This Policy Covers

This Privacy Policy describes how AgentAlly handles personal data across its website, application, approval-gated workflows, integrations, APIs, and support or operational activities. It is written as a truthful operating disclosure for launch, not as generic SaaS filler.

This draft applies to website visitors, prospective customers, customers, workspace administrators, authorized users, and individuals whose information customers choose to place into the service, subject to the controller-versus-processor distinction explained below.

This draft is intentionally paired with later governance work. G2 defines the baseline posture. G5 will add category-based lifecycle mechanics. G6 will add the fuller vendor, AI-provider, and incident-governance pack.

Section 2

Categories of Data, Sources of Data, and Why AgentAlly Uses It

AgentAlly processes multiple data categories rather than one undifferentiated bucket. The category-by-category logic matters because the source, role, access, retention, and deletion posture can differ across account data, customer workflow content, analytics, and audit evidence.

In practice, data reaches AgentAlly directly from users, through customer-enabled integrations and imports, through end-customer interactions routed into the customer workspace, and automatically through normal website and product operation.

AgentAlly uses this data to provide the service, connect external systems, draft and summarize work, support approval-gated workflows, operate billing and support, secure the service, and measure operational performance. Any broader use must be stated specifically rather than implied through vague "improve our services" language.

Source Summary

Directly from users and workspace admins

Users supply account details, prompts, files, drafts, approvals, feedback, settings, provider connections, and other workspace content directly inside the product.

Source Summary

From customer-enabled integrations and imports

AgentAlly receives data from GoHighLevel, Google services, CSV imports, portal-intake payloads, forwarded email leads, and other connected or imported sources chosen by the customer.

Source Summary

From end-customer interactions and customer-provided records

Customers may direct AgentAlly to process lead or client records, intake-form submissions, inbox context, communication history, and other end-customer information in their workspace.

Source Summary

Automatically from website and product use

The product and website generate logs, rate-limit data, analytics events, error telemetry, provider diagnostics, and performance signals as part of normal operations.

Purpose Summary

Provide the service

Authenticate users, operate workspaces, store customer content, connect third-party systems, and make the core application available.

Purpose Summary

Draft, summarize, rank, and recommend

Use model providers and workflow logic to prepare drafts, summarize context, classify information, stage actions, and help the customer decide what to do next.

Purpose Summary

Support approval-gated workflows

Maintain review, approval, send, failure, and provenance records so external communications stay human-approved by default.

Purpose Summary

Operate, secure, and improve the product

Monitor errors, prevent abuse, investigate incidents, measure usage, and use voluntary feedback plus operational analytics to improve reliability and usability.

Purpose Summary

Manage commercial, support, and legal operations

Handle subscriptions, customer support, security investigations, compliance obligations, and communications about the service.

Account, profile, and workspace administration data

Examples
  • names, email addresses, login identifiers, profile fields, role assignments, workspace settings, and provider connection state
Typical Sources
  • users, workspace admins, onboarding flows, and authentication providers
Primary Purposes
  • create and secure accounts
  • manage workspace membership and permissions
  • support onboarding and provider connection flows
Role note: Usually handled in AgentAlly's controller or business role because it supports account creation, access control, and core service administration.

Billing, subscription, and account-state data

Examples
  • plan selections, subscription status, checkout state, provider customer identifiers, and payment-related account records
Typical Sources
  • customers, workspace admins, and billing providers such as Polar
Primary Purposes
  • process subscriptions and account changes
  • support billing operations, cancellations, refunds, and account recovery
  • maintain financial and contractual records
Role note: Handled in AgentAlly's controller or business role because it relates to AgentAlly's own commercial relationship with the customer.

Lead, client, contact, transaction, and customer operational records

Examples
  • CRM records, lead data, contact details, opportunity stages, transaction context, notes, and qualification details
Typical Sources
  • customers and authorized users
  • GoHighLevel, CSV imports, portal-intake payloads, forwarded lead emails, forms, and customer-enabled workflows
Primary Purposes
  • provide customer-directed CRM and workflow functionality
  • rank work, summarize context, prepare drafts, and sync with connected systems
  • maintain operating history for the customer workspace
Role note: Often processed in AgentAlly's processor or service-provider role when AgentAlly handles this data on the customer's behalf, subject to limited controller-side use for security, support, and service operations.

Communication content and communication metadata

Examples
  • draft emails, SMS content, inbox context, call or message notes, recipients, message subjects, send outcomes, and related metadata
Typical Sources
  • users, customer-uploaded content, connected inbox or CRM systems, and generated workflow drafts
Primary Purposes
  • prepare and stage communications
  • support approval-gated sending through connected providers
  • maintain send, failure, and follow-up history
Role note: Message content is often processed on the customer's behalf, but approval evidence, abuse prevention, and delivery diagnostics may also be kept for AgentAlly's own legal, security, and support purposes.

Prepared actions, approvals, provenance, and audit records

Examples
  • approval decisions, audit-log entries, compliance timestamps, content hashes, routing metadata, run history, and provenance records
Typical Sources
  • product workflows, user actions, internal logging, and compliance or trust controls
Primary Purposes
  • support approval-gated workflows
  • show what happened and when
  • investigate disputes, misuse, or system issues
Role note: This category can sit in a mixed role posture because it reflects both customer workflow history and AgentAlly's own compliance, security, and service-operation obligations.

Queue, recommendation, and prioritization state

Examples
  • ephemeral ranking inputs, recommendation scores, customer-visible queue items, recommendation history where surfaced, and operator accountability metadata for why an item was shown
Typical Sources
  • product ranking logic, workflow state, connected-system updates, and user or operator actions
Primary Purposes
  • surface the next best work inside the canonical queue
  • retain visible recommendation history where the product exposes it
  • preserve enough accountability evidence to explain why a recommendation was generated or suppressed
Role note: Ephemeral queue or scoring state can be shorter-lived than customer-visible queue history or accountability evidence. Customer-visible queue records generally follow workspace lifecycle, while hidden scoring or internal accountability records may stay governed separately.

Uploaded files, generated documents, templates, and extracted content

Examples
  • vault files, PDFs, DOCX files, spreadsheets, images, templates, generated documents, extracted text, and related metadata
Typical Sources
  • users, customer uploads, generated outputs, Google Drive sync, and document workflows
Primary Purposes
  • store and organize files
  • generate exportable documents
  • extract content and connect documents to contacts, properties, or workflows
Role note: Usually processed on the customer's behalf, with limited internal access for support, security, and service maintenance.

Integration, import, and provider-connection data

Examples
  • OAuth tokens, refresh metadata, provider status, scopes, synced calendar data, Drive metadata, Gmail summaries, portal source metadata, and import payloads
Typical Sources
  • customer-enabled integrations such as GoHighLevel and Google
  • portal-intake providers, forwarded leads, and import files
Primary Purposes
  • connect external systems
  • sync data and status into the workspace
  • power customer-requested workflows across providers
Role note: Usually processed on the customer's behalf for connected-workspace features, with a limited controller-side overlay for connection health, fraud prevention, and operational diagnostics.

Stored prompts, outputs, embeddings, and retrieval context

Examples
  • saved prompts, generated outputs, summarization context, embeddings, retrieval indexes, and other derived AI-assistance artifacts where stored
Typical Sources
  • user prompts, generated workflows, retrieval pipelines, and optional embedding-enabled memory features
Primary Purposes
  • support drafting, summarization, semantic retrieval, and continuity features
  • keep certain generated outputs available in visible product surfaces
  • preserve derived context needed to rehydrate workspace features while the workspace remains active
Role note: This category mixes customer operational content with derived system artifacts. Customer-visible prompts or outputs generally follow workspace lifecycle, while hidden indexes or derived artifacts may be regenerated, deleted later, or retained only so long as the underlying feature remains active.

Usage, device, analytics, logging, and telemetry data

Examples
  • analytics events, feature-usage metrics, prompt-token metrics, error logs, device or browser signals, IP-derived rate-limit keys, and push subscription or device-token records
Typical Sources
  • automatic collection through website and product use
  • performance, monitoring, and security tooling
Primary Purposes
  • operate, secure, and debug the product
  • measure adoption and feature performance
  • prevent abuse, monitor incidents, and improve reliability
Role note: Usually handled in AgentAlly's controller or business role because it supports product operations, security, and performance measurement.

Support, feedback, and troubleshooting data

Examples
  • support requests, feedback submissions, bug reports, ratings, migration-assistance context, troubleshooting notes, temporary debug captures, and operator investigation notes
Typical Sources
  • users, workspace admins, and support interactions
Primary Purposes
  • respond to support requests
  • debug and maintain the service
  • use voluntary feedback to improve product quality
Role note: Usually handled in AgentAlly's controller or business role because it supports AgentAlly's own support and service-improvement operations.

Backups, disaster-recovery copies, and restore media

Examples
  • database backups, storage snapshots, disaster-recovery copies, and temporary restore artifacts created for continuity or incident recovery
Typical Sources
  • backup systems, storage replication, disaster-recovery workflows, and incident-response or restore operations
Primary Purposes
  • support restoration after outages, corruption, or security events
  • maintain business continuity and recoverability
  • allow delayed purge after active-system deletion while backup media ages out or is overwritten
Role note: Backups are not an ordinary customer-facing workspace feature and do not follow the same immediate deletion path as active product records. They are retained for continuity and recovery until they expire or are overwritten under the backup program in force at the time.

Website, waitlist, marketing, and public-form data

Examples
  • waitlist signups, referral codes, marketing-form submissions, public contact details, traffic analytics, and public-site performance data
Typical Sources
  • website visitors, waitlist forms, landing pages, and marketing campaigns
Primary Purposes
  • respond to inquiries and manage waitlist flows
  • measure website traffic and performance
  • communicate about launch, onboarding, and commercial activity
Role note: Handled in AgentAlly's controller or business role because it relates to AgentAlly's own website, marketing, and commercial operations.

Section 3

When AgentAlly Acts as a Controller or Business Versus a Processor or Service Provider

AgentAlly has a mixed role posture. It may act as a controller or business for its own website, account, billing, support, security, abuse prevention, and product analytics activities. It may also act as a processor or service provider when it handles customer-uploaded or customer-directed lead, client, communication, workflow, and file content on the customer's behalf.

The same workflow can create both roles at once. For example, customer-directed message content may be processed on the customer's behalf, while approval evidence, failure diagnostics, and security logs may also be processed for AgentAlly's own legal, operational, and abuse-prevention needs.

Where AgentAlly acts as a processor or service provider, the customer remains responsible for having the rights and authority to supply the underlying data and to instruct AgentAlly to process it.

Controller or business

Website visitors, waitlist signups, account setup, billing, support, and product operations

AgentAlly decides how to use this data for its own website, account, billing, support, security, and commercial operations.

Processor or service provider

Customer-uploaded files, CRM records, lead and client data, workspace drafts, and customer-directed communications

AgentAlly generally handles this content on the customer's behalf to provide the requested workspace features, integrations, and approval-gated workflows.

Mixed role

Approval evidence, audit trails, abuse prevention, and service diagnostics tied to customer workflows

The underlying workflow may be customer-directed, but AgentAlly may also keep certain logs or evidence for its own legal, security, support, and operational responsibilities.

Section 4

Third Parties, Subprocessors, and AI or Model Providers

AgentAlly depends on third-party providers for infrastructure, hosting, billing, monitoring, maps, AI, and customer-enabled integrations. These providers may process data only to the extent needed for the feature or operational function involved.

Provider usage can be feature-specific. Not every workspace uses every integration or provider. For example, Google only receives data when a customer enables Google features, and OpenAI embedding calls are environment-dependent rather than always-on.

This Privacy Policy includes a meaningful public summary now. A fuller subprocessor and AI-provider disclosure page belongs in G6 so vendor-specific retention, regional, and change-management details can stay current without rewriting the whole Privacy Policy.

Supabase

Core platform dependency
Infrastructure, database, auth, and storage

Hosts application data, authentication state, storage buckets, and many internal records including workflow, analytics, and audit tables.

Vercel

Core platform dependency
Hosting, runtime, analytics, and performance tooling

Hosts the web application and, in production, runs Vercel Analytics and Speed Insights for website and product measurement.

Anthropic

Core AI workflow dependency
AI and model provider

Receives prompts, context, and related content for chat, drafting, summarization, and other AI-assisted product features through the Vercel AI SDK.

OpenAI

Feature-specific and environment-dependent
AI and embeddings provider

When the optional embedding key is enabled, receives text input for semantic embeddings used in memory and retrieval features.

GoHighLevel

Customer-enabled integration
Customer-enabled CRM and messaging integration

Provides CRM, contact, conversation, task, and messaging functionality for connected customer workspaces, including approved sends.

Google

Customer-enabled integration
Customer-enabled productivity integration

Provides OAuth, Calendar, Drive, Gmail, and related connected-workspace functionality when the customer enables those integrations.

Polar

Commercial operations
Billing provider

Handles checkout, subscription, and related billing workflows.

Mapbox

Feature-specific
Maps and location services

Supports mapping, geocoding, and territory-related product features.

Sentry

Operational diagnostics
Error monitoring and diagnostics

Receives application error and performance telemetry, subject to AgentAlly's PII-redaction logic and monitoring settings.

Hostinger SMTP / mail.agentally.ai

Environment-dependent marketing and operations support
Transactional email infrastructure

May send waitlist or launch-related welcome emails when SMTP credentials are configured.

Section 5

Training, Model Use, and Human Review

Product Confirmation Required

AgentAlly currently relies on third-party model providers rather than a customer-content-trained in-house model stack. By default, AgentAlly does not describe customer or end-customer content as training data for AgentAlly's own models.

AgentAlly does route prompts, context, drafts, and other relevant content to third-party AI providers to deliver requested features. If AgentAlly uses provider settings or contracts that permit provider retention, abuse review, or model-improvement use beyond ordinary API processing, that posture must be stated expressly in launch disclosures rather than buried in generic service-provider language.

AgentAlly may use voluntary feedback, ratings, bug reports, operational analytics, and troubleshooting information to improve the product. That is different from treating general customer operational content as blanket training material.

Human review can occur when necessary for support, debugging, abuse prevention, security, legal compliance, or service maintenance. Human review is not the same thing as AgentAlly reviewing every AI output before a customer sees it; the product law remains AI assists and humans approve external communications.

Review Note

Before publication, confirm the exact provider-by-provider posture on API data retention, safety review, and model training so this section stays explicit and accurate.

Section 6

Retention, Deletion, Export, and Lifecycle Governance

Product and Security Review Required

AgentAlly retains data according to category, business need, legal obligation, security need, and customer workflow context. It does not have a truthful one-size-fits-all retention period for every data type, and this draft intentionally avoids unsupported numeric TTL promises.

The central lifecycle split is between customer operational data and audit, provenance, billing, security, or dispute-preservation records. Customer-visible workspace records should usually be the first deletion and export priority, while evidence-of-operation records may require a longer or more constrained lifecycle because they show what the system prepared, what a human approved, and what happened next.

Deleting data from the product interface, disconnecting an integration, or closing an account is not necessarily the same as immediate permanent deletion from every live system, queue, cache, analytics record, log, backup, or provider environment. Active-surface removal, production purge, backup expiration, and downstream processor deletion can happen on different timelines.

Current repo truth supports some feature-specific export and deletion paths, such as account deletion plus certain knowledge and vault exports. It does not support promising a universal self-serve export or immediate full-system purge across all categories, hidden artifacts, and downstream systems today, so certain requests still require manual or operator-run handling.

Review Note

Before publication, confirm queue-cancel behavior for pending prepared actions or scheduled sends, the exact handling of stored prompts or embeddings, backup overwrite timing, and which approval or run-ledger artifacts must remain immutable for audit, dispute, or abuse-review purposes.

Lifecycle Split

Operational customer data

Lead, contact, client, transaction, communication, queue-history, file, and visible prompt or output records are the primary customer-facing business records. These categories should usually be the first export and deletion priority when a record, workspace, or processor-directed request is handled.

Lifecycle Split

Audit, provenance, and accountability records

Approval logs, run-ledger entries, content hashes, send outcomes, security review notes, billing evidence, and dispute-preservation records exist to show what the system generated, what users approved, and what the platform or downstream systems did. These records may stay governed longer or be deleted on a narrower path than ordinary workspace content.

  • Retention is category-based and purpose-based, not one monolithic timer.
  • Operational customer data and audit or provenance data are different lifecycle classes and should not be governed as though they are the same bucket.
  • Operational customer content, approval evidence, security logs, billing records, and public-site marketing data may have different retention periods and different deletion constraints.
  • UI deletion or account closure does not equal immediate deletion from all queues, logs, backups, provider systems, or asynchronous stores.
  • Backups and disaster-recovery copies may remain for a limited period after active records are removed, and downstream processors may delete on a different timetable.
  • Feature-specific export paths exist today, but a complete self-serve export or delete matrix is not yet a truthful launch claim.
Operational customer data

Customer-visible workspace records and hosted business content.

Retention: Generally follows the active customer or workspace lifecycle and is prioritized for export and deletion handling when the workspace remains entitled to request that action.

Export: Highest export priority in common usable formats where the product already exposes the record or file.

Deletion: May be removed from active surfaces first, then purged from live systems on a delayed basis subject to backups, downstream processors, and holds.

Evidence of operation, approvals, and provenance

Run-ledger, approval history, accountability evidence, and send or workflow traceability.

Retention: May persist longer than ordinary drafts because it preserves evidence of what the system prepared, what a human approved, and what happened next.

Export: Customer-visible approval or send history may be exportable, but hidden internal accountability artifacts are not promised as part of ordinary exports.

Deletion: Often handled through constrained deletion or redaction paths rather than immediate erasure, especially where audit, dispute, or abuse-review needs remain active.

Support, debug, and security telemetry

Operational logs, support artifacts, diagnostics, and abuse-prevention data.

Retention: Often shorter-lived in raw form than billing or audit evidence, but may be retained or preserved when needed for incident response, debugging, or security investigation.

Export: Not an ordinary customer export target, especially for raw security logs, abuse-monitoring signals, or transient diagnostics.

Deletion: May age out under internal log or support processes, with legal, fraud, or security holds able to pause normal deletion.

Financial, legal, and account-state data

Account identity, subscription state, billing records, and legal or dispute-related records.

Retention: May persist beyond workspace-content deletion when needed for billing, tax, contractual, legal, fraud, or recordkeeping reasons.

Export: Limited to records reasonably tied to the requester and the applicable commercial relationship; not every processor-side ledger is promised in a self-serve bundle.

Deletion: Deletion can be denied, delayed, or narrowed where retention is required for finance, tax, legal compliance, disputes, or fraud prevention.

Account, profile, and workspace administration data

Financial / legal / account-state
Data Class

Account identity and workspace administration

Retention Trigger

Retained while the account or workspace remains active, then as needed for security, account recovery, and contractual recordkeeping.

Export Scope

Only the portions reasonably tied to the user or workspace are suitable for ordinary export.

Deletion Path

Account closure can remove active access and certain settings first; some account-state evidence may remain for legal, fraud, or security reasons.

Notes: Supports authentication, permissions, and workspace administration rather than customer-facing CRM history.

Billing, subscription, and account-state data

Financial / legal / account-state
Data Class

Commercial and financial records

Retention Trigger

Retained according to the active commercial relationship and later finance, tax, refund, dispute, or legal obligations.

Export Scope

Limited billing or subscription detail may be provided, but processor-side payment records remain partly governed by the billing provider.

Deletion Path

Not an ordinary immediate-delete category; closure may stop future billing while preserving required records.

Notes: Billing records can persist longer than workspace content because refund, tax, and dispute obligations outlast ordinary use.

Lead, client, contact, transaction, and customer operational records

Operational customer data
Data Class

Customer-visible business records

Retention Trigger

Usually follows the customer record or workspace lifecycle until deleted, migrated, or removed at the customer's direction.

Export Scope

Primary export target in usable formats because these are core business records customers actually need.

Deletion Path

Record-level deletion, workspace deletion, or processor-directed deletion should target these records early, subject to downstream-source realities and linked audit evidence.

Notes: If records originated in a connected CRM or source system, deletion inside AgentAlly does not necessarily delete the source-system copy.

Communication content and communication metadata

Operational customer data
Data Class

Visible drafts, message history, and send outcomes

Retention Trigger

Visible message records generally follow workspace lifecycle; staged drafts may be shorter-lived than completed or sent records.

Export Scope

Drafts, message history, and visible send outcomes are meaningful export targets where the product holds them.

Deletion Path

Deleting a record or workspace should suppress future use in active surfaces first; linked provider-side copies may remain in connected messaging systems.

Notes: Prepared or queued communications should not continue operating after the deletion path says they should be canceled or suppressed.

Queue, recommendation, and prioritization state

Operational customer data plus provenance overlay
Data Class

Ephemeral scoring, visible queue history, and accountability metadata

Retention Trigger

Ephemeral scoring or ranking inputs can be short-lived, while visible queue items or accountability evidence may remain as long as needed to explain product behavior.

Export Scope

Customer-visible recommendation or queue history may be exportable; hidden intermediate scores or unstable ranking inputs are not promised as ordinary exports.

Deletion Path

Visible queue records may follow record or workspace deletion, while hidden accountability metadata may persist longer on a constrained path.

Notes: This category must stay split internally between ephemeral ranking state and longer-lived accountability or exposed history.

Prepared actions, approvals, provenance, and audit records

Evidence of operation / approvals / provenance
Data Class

Run-ledger and approval accountability records

Retention Trigger

Retained as needed to preserve proof of generation, review, approval, send, failure, and dispute history.

Export Scope

Customer-visible approval history may be exportable, but hidden hashes, operator notes, or internal abuse-review artifacts are not generally part of ordinary exports.

Deletion Path

Often handled through narrower deletion or redaction rules than ordinary workspace content, especially where approval evidence needs to remain trustworthy.

Notes: Approval and provenance evidence should not be silently collapsed into normal draft-deletion logic.

Uploaded files, generated documents, templates, and extracted content

Operational customer data
Data Class

Hosted documents and generated files

Retention Trigger

Usually follows workspace lifecycle unless a file is copied from or remains present in an external source system.

Export Scope

High export priority because files and generated documents are customer-visible and already map to real product exports.

Deletion Path

Deleting the hosted file removes active access first, then follows storage and backup purge timing.

Notes: Vault export exists in repo truth, but deletion still needs to account for storage, extraction, and backup lag.

Stored prompts, outputs, embeddings, and retrieval context

Operational customer data plus derived system artifacts
Data Class

Visible AI content and hidden retrieval artifacts

Retention Trigger

Visible prompts or outputs generally follow workspace lifecycle; embeddings or derived indexes may persist only while the feature remains active or until a later purge job removes them.

Export Scope

Visible prompts or outputs may be exportable where stored in ordinary surfaces; embeddings, intermediate vectors, or unstable retrieval artifacts are not promised in ordinary exports.

Deletion Path

Customer-visible artifacts should follow ordinary deletion paths first, while derived indexes may purge later on a delayed operational path.

Notes: Exact storage and purge timing for embeddings or derived retrieval context still needs product and security confirmation.

Integration, import, and provider-connection data

Operational customer data plus account-state
Data Class

Connection secrets, sync metadata, and imported payloads

Retention Trigger

Retained while the integration remains connected and for a limited period after disconnect where needed for troubleshooting, fraud review, or sync reconciliation.

Export Scope

Imported business records may be exportable, but provider tokens, secrets, or raw connection diagnostics are not ordinary export targets.

Deletion Path

Disconnecting an integration can revoke active access and remove stored tokens first, while imported records and external source copies may remain subject to separate deletion paths.

Notes: External systems such as Google or GoHighLevel keep their own copies and deletion rules.

Usage, device, analytics, logging, and telemetry data

Support / debug / security telemetry
Data Class

Product analytics and operational logging

Retention Trigger

Retained according to internal operational need, security need, and troubleshooting value rather than the same trigger used for customer-visible records.

Export Scope

Raw analytics and telemetry are not the primary customer export target.

Deletion Path

May age out or be purged under internal telemetry processes, subject to incident, abuse, or legal preservation needs.

Notes: Do not promise user-facing export of every hidden event, token metric, or monitoring artifact.

Support, feedback, and troubleshooting data

Support / debug / security telemetry
Data Class

Support cases and troubleshooting artifacts

Retention Trigger

Retained while the case remains open and then as needed to document prior support, product issues, or misuse investigations.

Export Scope

Support correspondence tied to the requester may be retrievable, but temporary debug captures and internal operator notes are not generally ordinary export targets.

Deletion Path

Can be narrowed or delayed when needed to preserve evidence of support, abuse, security review, or product defects.

Notes: Voluntary feedback stays distinct from general customer operational content.

Backups, disaster-recovery copies, and restore media

Support / debug / security telemetry with continuity exceptions
Data Class

Continuity and recovery copies

Retention Trigger

Retained until backup media expires, rotates, or is overwritten under the continuity program in force at the time.

Export Scope

Not an ordinary user export target.

Deletion Path

Active-system deletion does not immediately purge backup copies; backup deletion is delayed until the relevant media expires or is overwritten unless a special restore or legal hold changes the path.

Notes: This is the clearest place where delayed purge needs to be stated directly.
Deletion Paths
  • Record-level deletion: a customer-visible record may disappear from active product surfaces before live-system purge, backup expiry, and downstream processor deletion complete.
  • Workspace or account closure deletion: repo truth supports account deletion, but that does not promise instant purge of every workspace-linked record, queue artifact, audit trail, billing record, or backup copy.
  • Processor or service-provider requests: when AgentAlly processes customer-directed end-customer data on the customer's behalf, the customer may need to sponsor or direct the deletion request.
  • Legal, security, fraud, abuse, billing, and dispute holds: these can pause, narrow, or document deletion instead of allowing ordinary purge to proceed immediately.
  • Pending actions and queued work: pending prepared actions, scheduled sends, and queued recommendations should be canceled or suppressed when the governing record or workspace is deleted, but the exact implementation path still requires launch confirmation.
Export Scope
  • Primary export priority is customer-visible business data: lead or contact records, visible communications, hosted files, generated documents, and customer-facing workspace history where the product already stores it.
  • Repo truth supports export utilities for contacts, deals, conversations, knowledge items, vault files, and some internal analytics surfaces, but not a universal one-click export for every category.
  • Approval or send history may be included where the product exposes it, while hidden run-ledger hashes, abuse-review notes, raw security logs, intermediate ranking scores, embeddings, and unstable system artifacts are outside ordinary export scope.
  • Exports may depend on the requester's role, the workspace permission model, and whether AgentAlly is acting as controller or processor for the data involved.
  • Deleting data in AgentAlly does not delete records that remain in customer-enabled source systems or downstream providers such as connected CRMs, inboxes, or storage services.
Backup, Downstream, and Operator Flow
  • Backups and disaster-recovery copies can retain deleted data for a limited period until the relevant media is overwritten, rotated, or expires under the backup program then in force.
  • Downstream processors and customer-enabled integrations may delete on their own operational timeline, so AgentAlly-side deletion and provider-side deletion do not always finish at the same moment.
  • Records imported from or synced with customer-enabled systems may remain in those source systems even after the AgentAlly copy is deleted.
  • Billing, tax, legal, fraud, abuse, security, and dispute obligations can justify keeping a narrower set of records beyond ordinary workspace deletion.
  • Launch-era deletion, export, and rights requests can be routed through ben@getagentally.com when self-serve tooling does not cover the category involved.
  • An operator should verify the requester, determine whether AgentAlly is acting as controller or processor for the records involved, and identify the correct deletion or export path.
  • The operator should document which records were removed from active systems, which categories remain subject to backup lag, downstream processors, or legal or security holds, and what completion date was communicated.
  • If the request involves customer-directed end-customer data, the operator should confirm customer authorization before acting and preserve the audit trail of that instruction.

Section 7

Access, Correction, Export, and Deletion Requests

Depending on the relationship and applicable law, individuals may request access to, correction of, export of, or deletion of certain personal data. The practical path can differ based on role.

If AgentAlly acts as a controller or business for the data involved, AgentAlly may address the request directly subject to verification, legal constraints, and operational limits. If AgentAlly acts as a processor or service provider for customer-directed data, the customer may need to make or sponsor the request because AgentAlly is handling that content on the customer's behalf.

Requests may be limited where retention is required for security, fraud prevention, billing, legal compliance, dispute handling, or preservation of approval, audit, and system-integrity records. Some logs and approval evidence are not normal self-serve deletion targets.

  • AgentAlly can address some requests directly when it acts as controller or business for the data involved.
  • For customer-directed workspace content, the customer may need to act because AgentAlly may be processing that data on the customer's behalf.
  • Requests may be limited by verification needs, legal obligations, security requirements, dispute handling, or preservation of approval, audit, and system-integrity records.
  • Correction, export, and deletion mechanics should be narrowed to what the product actually supports today rather than overpromised, and some launch-era requests may still be executed manually by support or operations.

Section 8

Workspace Admin, Internal Admin, Operator, and Support Access

Workspace administrators may be able to manage users, billing settings, and integrations and may have visibility into workspace-level records associated with the teams or businesses they administer.

Authorized AgentAlly personnel may access limited customer or user data when reasonably necessary to provide support, troubleshoot issues, investigate abuse or security events, maintain the service, process billing matters, or comply with legal obligations.

Current repo truth includes internal admin surfaces for analytics exports, audit-log review, provider diagnostics, rate-limit monitoring, and user-account detail views. The truthful launch posture is that internal access exists, is role-limited, and should remain narrow and need-based.

  • Workspace admins may have workspace-level visibility and control depending on the feature and permission model.
  • Authorized AgentAlly personnel may access limited records for support, debugging, billing, security, abuse prevention, or legal compliance.
  • Internal admin tooling exists for audit review, analytics export, provider diagnostics, and user-account troubleshooting.
  • The truthful posture is narrow, need-based access rather than a blanket "only you can see your data" promise.

Section 9

Cookies, Tracking, Security, Children, and Sensitive Data

AgentAlly uses browser and device technologies needed to run the website and application, including session or local storage for auth continuity, onboarding recovery, settings, and provider-flow state. Repo truth also supports production use of Vercel Analytics, Vercel Speed Insights, and Sentry for analytics, performance, and error monitoring. No broader marketing-pixel stack was confirmed in repo truth during this draft.

AgentAlly uses reasonable administrative, technical, and organizational safeguards designed to protect data, such as authenticated access controls, encrypted connections, row-level security controls, rate limiting, logging, provider-token protection, and security monitoring. No service can promise absolute security.

The service is designed for business use in real estate and is not intended for children under 18. Customers should avoid storing highly sensitive personal information in the service unless it is necessary, lawful, and appropriately governed, because the product is not presented here as a special-category or health-data platform.

Tracking and Analytics
  • Production repo truth shows Vercel Analytics and Speed Insights in the app shell.
  • Sentry is initialized for error and performance monitoring with PII-redaction logic.
  • The product also uses browser or device storage for auth continuity, onboarding recovery, and settings-related flows.
  • No Meta Pixel, Google Analytics tag, or broader ad-tech stack was confirmed in repo truth during this draft, but that should be re-reviewed before launch if marketing tooling changes.
Security Summary
  • Supabase auth and row-level security are part of the core data-isolation posture.
  • Encrypted connections, rate limiting, provider-token protection, and audit logging exist across core sensitive flows.
  • Error monitoring, diagnostics, and security reviews exist, but the policy should avoid absolute-security promises.
  • Security and incident-response detail belongs in the fuller G6 governance pack.

Section 10

Policy Changes and Contact

AgentAlly may update this Privacy Policy as the product, vendor stack, legal posture, or operating model changes. Material changes should be reflected through the website, product, email, or another reasonable notice method before the updated policy becomes operative, except where earlier changes are required for legal, security, or abuse-prevention reasons.

Questions, rights requests, and privacy-related concerns can be sent to ben@getagentally.com. Before final launch, AgentAlly should confirm whether a separate rights-intake workflow, mailing address, or privacy alias will supplement this contact path.

Open Questions

Product and counsel seams still marked on purpose

  • Confirm the final contracting entity, notice address, and whether a dedicated privacy alias or rights-request workflow will exist before launch.
  • Confirm the exact provider-by-provider posture for AI data retention, abuse review, and training across Anthropic and any optional OpenAI usage.
  • Confirm the exact workspace-admin visibility model for prompts, drafts, approvals, audit records, and message content.
  • Confirm which rights and export workflows will be self-serve at launch versus handled manually, and how manual completion is tracked for customers.
  • Confirm what happens to pending prepared actions, scheduled sends, queued recommendations, and linked approval artifacts when a record or workspace is deleted.
  • Confirm backup windows and downstream deletion timing before publishing any numeric deletion commitments.
  • Confirm which stored prompts, generated outputs, embeddings, and derived retrieval artifacts are persisted versus regenerated and what purge path governs each class.
  • Recheck the tracking stack before launch if any additional analytics, pixels, or ad-tech tooling is added beyond Vercel Analytics, Speed Insights, and Sentry.
Validation

Privacy-truth checks baked into the draft

  • The draft distinguishes account, billing, customer workflow, queue state, prompt or embedding artifacts, file, telemetry, support, backup, and marketing data instead of collapsing everything into one bucket.
  • Operational customer data is separated from audit, provenance, billing, security, and dispute-preservation data early in the lifecycle section.
  • Controller or business versus processor or service-provider posture is explained with concrete scenarios rather than generic legal shorthand.
  • Anthropic, OpenAI, GoHighLevel, Google, Supabase, Vercel, Polar, Mapbox, and Sentry appear as meaningful provider disclosures where the repo supports them.
  • Training and model-use language is explicit and does not silently convert customer content into blanket training data.
  • Admin, operator, and support access is disclosed as narrow but real rather than denied outright.
  • Retention logic stays category-based and does not bluff unsupported exact TTLs.
  • Retention, deletion, export, and backup posture avoids impossible promises about immediate full-system purge or universal self-serve export.
  • Export scope stays focused on customer-visible business records rather than every hidden score, embedding, security log, or internal artifact.
  • Backups, downstream processors, source-system copies, and legal, security, fraud, billing, or dispute exceptions are disclosed rather than hidden.
  • Tracking and monitoring disclosures match the repo's current use of Vercel Analytics, Speed Insights, Sentry, and browser or device storage.
  • Open product and counsel seams are marked clearly instead of guessed at.

Questions, launch review, or privacy requests

Until the final launch version is published, privacy questions and launch-review feedback can be sent to ben@getagentally.com.

AI-assisted draft prepared for launch counsel review on April 17, 2026. This page is a launch foundation draft and is not effective until AgentAlly publishes the final Privacy Policy with confirmed entity details, provider posture, and operational rights workflows.