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.
Privacy Foundation
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.
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.
Covers categories, sources, purposes, role split, human access, provider classes, training/model-use posture, and the first public retention/deletion/export/backups summary.
Owns the category-by-category retention bands, deletion workflows, export scope, backup and downstream posture, audit-record treatment, and operator-run lifecycle mechanics.
Owns the fuller subprocessor and AI-provider disclosure page, provider change process, retention-by-vendor detail, and shared-responsibility incident governance.
Section 1
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
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.
Users supply account details, prompts, files, drafts, approvals, feedback, settings, provider connections, and other workspace content directly inside the product.
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.
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.
The product and website generate logs, rate-limit data, analytics events, error telemetry, provider diagnostics, and performance signals as part of normal operations.
Authenticate users, operate workspaces, store customer content, connect third-party systems, and make the core application available.
Use model providers and workflow logic to prepare drafts, summarize context, classify information, stage actions, and help the customer decide what to do next.
Maintain review, approval, send, failure, and provenance records so external communications stay human-approved by default.
Monitor errors, prevent abuse, investigate incidents, measure usage, and use voluntary feedback plus operational analytics to improve reliability and usability.
Handle subscriptions, customer support, security investigations, compliance obligations, and communications about the service.
Section 3
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.
AgentAlly decides how to use this data for its own website, account, billing, support, security, and commercial operations.
AgentAlly generally handles this content on the customer's behalf to provide the requested workspace features, integrations, and approval-gated 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
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.
Hosts application data, authentication state, storage buckets, and many internal records including workflow, analytics, and audit tables.
Hosts the web application and, in production, runs Vercel Analytics and Speed Insights for website and product measurement.
Receives prompts, context, and related content for chat, drafting, summarization, and other AI-assisted product features through the Vercel AI SDK.
When the optional embedding key is enabled, receives text input for semantic embeddings used in memory and retrieval features.
Provides CRM, contact, conversation, task, and messaging functionality for connected customer workspaces, including approved sends.
Provides OAuth, Calendar, Drive, Gmail, and related connected-workspace functionality when the customer enables those integrations.
Handles checkout, subscription, and related billing workflows.
Supports mapping, geocoding, and territory-related product features.
Receives application error and performance telemetry, subject to AgentAlly's PII-redaction logic and monitoring settings.
May send waitlist or launch-related welcome emails when SMTP credentials are configured.
Section 5
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.
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
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.
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.
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.
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.
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.
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.
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.
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 identity and workspace administration
Retained while the account or workspace remains active, then as needed for security, account recovery, and contractual recordkeeping.
Only the portions reasonably tied to the user or workspace are suitable for ordinary export.
Account closure can remove active access and certain settings first; some account-state evidence may remain for legal, fraud, or security reasons.
Commercial and financial records
Retained according to the active commercial relationship and later finance, tax, refund, dispute, or legal obligations.
Limited billing or subscription detail may be provided, but processor-side payment records remain partly governed by the billing provider.
Not an ordinary immediate-delete category; closure may stop future billing while preserving required records.
Customer-visible business records
Usually follows the customer record or workspace lifecycle until deleted, migrated, or removed at the customer's direction.
Primary export target in usable formats because these are core business records customers actually need.
Record-level deletion, workspace deletion, or processor-directed deletion should target these records early, subject to downstream-source realities and linked audit evidence.
Visible drafts, message history, and send outcomes
Visible message records generally follow workspace lifecycle; staged drafts may be shorter-lived than completed or sent records.
Drafts, message history, and visible send outcomes are meaningful export targets where the product holds them.
Deleting a record or workspace should suppress future use in active surfaces first; linked provider-side copies may remain in connected messaging systems.
Ephemeral scoring, visible queue history, and accountability metadata
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.
Customer-visible recommendation or queue history may be exportable; hidden intermediate scores or unstable ranking inputs are not promised as ordinary exports.
Visible queue records may follow record or workspace deletion, while hidden accountability metadata may persist longer on a constrained path.
Run-ledger and approval accountability records
Retained as needed to preserve proof of generation, review, approval, send, failure, and dispute history.
Customer-visible approval history may be exportable, but hidden hashes, operator notes, or internal abuse-review artifacts are not generally part of ordinary exports.
Often handled through narrower deletion or redaction rules than ordinary workspace content, especially where approval evidence needs to remain trustworthy.
Hosted documents and generated files
Usually follows workspace lifecycle unless a file is copied from or remains present in an external source system.
High export priority because files and generated documents are customer-visible and already map to real product exports.
Deleting the hosted file removes active access first, then follows storage and backup purge timing.
Visible AI content and hidden retrieval artifacts
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.
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.
Customer-visible artifacts should follow ordinary deletion paths first, while derived indexes may purge later on a delayed operational path.
Connection secrets, sync metadata, and imported payloads
Retained while the integration remains connected and for a limited period after disconnect where needed for troubleshooting, fraud review, or sync reconciliation.
Imported business records may be exportable, but provider tokens, secrets, or raw connection diagnostics are not ordinary export targets.
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.
Product analytics and operational logging
Retained according to internal operational need, security need, and troubleshooting value rather than the same trigger used for customer-visible records.
Raw analytics and telemetry are not the primary customer export target.
May age out or be purged under internal telemetry processes, subject to incident, abuse, or legal preservation needs.
Support cases and troubleshooting artifacts
Retained while the case remains open and then as needed to document prior support, product issues, or misuse investigations.
Support correspondence tied to the requester may be retrievable, but temporary debug captures and internal operator notes are not generally ordinary export targets.
Can be narrowed or delayed when needed to preserve evidence of support, abuse, security review, or product defects.
Continuity and recovery copies
Retained until backup media expires, rotates, or is overwritten under the continuity program in force at the time.
Not an ordinary user export target.
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.
Section 7
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.
Section 8
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.
Section 9
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.
Questions or rights requests can be sent to ben@getagentally.com.
Section 10
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.
Until the final launch version is published, privacy questions and launch-review feedback can be sent to ben@getagentally.com.