AGI
Legal

Privacy policy.

What we collect, what we do not, and how that changes depending on which mode you run. AGI does not use customer conversation content to train AGI-owned models. We do not sell your data. Website users can use AGI managed cloud. The Free plan runs on a model AGI chooses, within a small usage allowance, and paid plans with more capacity are opening in stages, so an upgrade needs an access code or a place on the upgrade waitlist. The CLI supports Local and BYOK; VS Code BYOK is coming soon. Managed cloud is open by default, not invite-only. Last updated: 2026-10-15. Managed Cloud is in public alpha. Previous versions

Definitions

  • Personal dataAny information relating to an identified or identifiable person.
  • ProcessingAnything done with personal data: collecting, storing, using, disclosing, deleting it.
  • ControllerThe party that decides why and how personal data is processed.
  • ProcessorThe party that processes personal data on a controller’s instruction.
  • LocalRunning AGI entirely on your own device. Nothing about the conversation reaches us.
  • BYOKBring your own key: routing a request through your own account with a model provider.
  • Managed CloudThe hosted, metered service AGI Automation LLC operates, currently in public alpha.
  • SubprocessorA third party we or our processor engage to help process personal data, listed at /subprocessors.

00 · The mode decides the answer

Most privacy policies have one answer. This product has three, because Local, BYOK and Managed Cloud are separate trust boundaries and your data goes to genuinely different places in each. Read this table first; the rest of the page is detail.

  • LocalWhere your prompts go: from the CLI to Ollama or LM Studio on loopback. Nothing is transmitted to us and nothing is silently routed to BYOK or Managed Cloud. The download page shows which CLI releases are published.
    What we hold: nothing about the local model request. The current Desktop and web apps use Managed Cloud; they do not expose Local inference.
  • BYOKWhere your prompts go: from your client straight to the provider you targeted, on your own API key. We are not in that request path. BYOK is part of the CLI. The VS Code extension is coming soon. Desktop and web are cloud-only and have no user-key path, so work on those surfaces is Managed Cloud.
    What we hold: not the provider key or prompt traffic. The CLI stores the key in the operating system credential store, or in owner-only files on Linux or when the keyring is turned off, and calls the provider directly.
  • Managed CloudWhere your prompts go: through our gateway to the provider serving the model you selected. On the Free plan’s default model, AGI chooses the provider, as section 01 sets out. Managed Cloud is in public alpha.
    What we hold: conversations, files, projects, memories, schedules and settings, so they sync across your devices. This is the only mode where we act as your processor. See the DPA.

01 · What we collect

  • AccountExamples: email, account ID, authentication metadata held by our identity provider. Sign-up also asks for your age; it is checked in your browser and is not stored, sent to our servers or sent to our identity provider.
    Why, and how it is protected: authentication, and optional marketing email only if you choose “Email me product news, tips and offers.” separately. We do not store your password ourselves.
  • BillingExamples: Stripe customer ID, plan, invoice metadata. Card details go to Stripe directly and we never see or store them.
    Why, and how it is protected: subscription management.
  • Conversations (Managed Cloud)Examples: threads, messages, tool calls, and references to attached files.
    Why, and how it is protected: cross-device sync. Two layers of access control: every route resolves the authenticated user and scopes the query to them, and Postgres row-level security policies are forced on the user-scoped tables behind the sync paths that bind the request identity per connection. It is defence in depth, not one absolute switch.
  • Files you upload or generateExamples: attachments, generated images, and other stored media.
    Why, and how it is protected: stored in Cloudflare R2 and catalogued in Neon. The product gives clients an authenticated same-origin file route that requires both the owning account and its active Personal or organisation workspace to match. Missing, deleted, foreign, and inactive-workspace files all return the same not-found response, and those responses are private and not stored by browser caches. New uploads and generated files, videos included, are written to a private bucket and are served to you through that signed-in, workspace-scoped route. Profile pictures are the exception: they are stored in a public R2 bucket, the product returns their address to you and to the members of your workspace, and anyone who has that address can open the picture without signing in. Files stored before uploads and generated files moved to the private bucket may remain in the public bucket, and anyone who obtains the underlying storage URL of one can open it without signing in. A data export you request can include these files in its archive, which you download through a short-lived signed link, and anyone who has that link can open the archive without signing in until the link expires.
    Location and camera details in pictures: before a picture you attach in the AGI web, desktop or mobile app leaves your device, AGI removes the location, camera and time details stored inside it, keeping only what is needed to show it the right way up and in the right colours. A picture that cannot be read well enough to do this is not sent. The file name is kept as you gave it.
  • Voice and audioExamples: microphone audio, captured only while you are dictating into the composer or holding a Voice Mode conversation, and the text that comes back from it.
    Why, and how it is protected: turning speech into text, and holding a spoken conversation. Nothing is captured until you start one of the two. Dictation sends the recording to OpenAI’s transcription endpoint; Voice Mode opens a realtime session with OpenAI and your microphone audio streams from your browser to that session for as long as it runs. We do not store the audio. The dictation route passes the bytes on and keeps none, and a voice session record holds that session’s settings and a pointer into the transcript, with no audio in it. The text transcript is kept as ordinary conversation content and follows the conversation rows above. There is no voiceprint, speaker identification or other biometric identifier anywhere in this product, and nothing here infers who is speaking. What OpenAI does with audio it receives is its own published practice, named on /subprocessors, not a promise we can make for it.
  • What the assistant's tools recordExamples: when the assistant searches the web, fetches a page, runs code or calls a connector, the tool call and what came back are kept in the conversation. Each connector call is also logged with the connector, the tool, the time and whether it worked, never the arguments and never the result. A screenshot is taken only when you choose to capture one in the feedback form: your browser asks which screen, window or tab to share, one still picture is captured, and it is attached to your feedback.
    Why, and how it is protected: doing the task you asked for. A web search sends your query to Perplexity. A sandbox run sends the code and the files it works on to E2B, and only where sandbox execution is switched on. Both are named on /subprocessors. Tool calls follow the conversation’s retention in section 05. The web app cannot watch your screen or your other tabs on its own. Browser control and computer use belong to the Chrome extension, which is not released; what it captures, including screenshots of the tab that cannot be redacted, is set out on /agent-permissions.
  • Conversations (Local)Examples: CLI sessions sent to Ollama or LM Studio on loopback. Not silently routed to BYOK or Managed Cloud.
    Why, and how it is protected: AGI Cloud is not in the model request path.
  • BYOK keysExamples: provider credentials saved by the CLI in the operating system credential store, or in owner-only files on Linux or when the keyring is turned off.
    Why, and how it is protected: the CLI reads the key locally and sends requests directly to the selected provider; AGI Cloud does not receive it.
  • TelemetryExamples: Browser error and performance reports via Sentry use the telemetry consent in Settings; Google Analytics page views use the analytics choice in the cookie banner. Both browser gates fail closed. Server and edge operational error reporting can run when Sentry is configured and does not use the browser setting.
    Why, and how it is protected: operational visibility. Request bodies, query strings, cookies, headers and prompt- or content-named fields are removed. Free-text diagnostic messages may remain after secrets are masked. Consented browser reports retain a stable user id so a crash can be tied to a session; server and edge reports do not.
  • Logs and security eventsExamples: server logs with bearer tokens redacted, plus an append-only security audit log of account-lifecycle and administrative events.
    Why, and how it is protected: debugging, abuse prevention, and incident investigation.
  • Referral program checksExamples: when you join through a referral link, a one-way hash of the network you signed up from, and a comparison of your app installations, your card’s Stripe fingerprint and a normalized form of your email address with those of the person who referred you. Card fingerprints are read from Stripe when a reward falls due and are not stored by us.
    Why, and how it is protected: stopping self-referral and reward abuse. A match withholds the reward and records why. The network hash stays with the referral record and is deleted with your account.
  • Things you send us on purposeExamples: feedback (your subject, message, and optionally a diagnostic log we scrub for secrets before storing), content reports (the category, your note, and a short excerpt of the message you are reporting), and support conversations.
    Why, and how it is protected: answering you and fixing what you reported. A support escalation emails the transcript and the contact address you gave to our support inbox.
  • Records you create by using the productExamples: your search history, and the memories the assistant keeps about you when you enable them.
    Why, and how it is protected: making search and the assistant useful across sessions. Both are yours to clear: search history has a clear action, and memory is off unless you turn it on.
  • Profile details you choose to addExamples: display name, avatar, and optional fields such as a phone number, stored with your settings.
    Why, and how it is protected: personalising the product. Optional means optional: nothing here is required to use an account.
  • Enterprise contact listExamples: your email address, if you ask us to discuss contract-scoped Enterprise access or additional Enterprise capabilities with you.
    Why, and how it is protected: only what you consented to, recorded per purpose before the address is stored. You can be asked about product updates separately and decline that without leaving the list.
  • Devices and downloadsExamples: push tokens for the mobile apps. For a desktop download: a hashed IP, the user-agent, the referring page and a coarse country in the download record, and separately, your unhashed IP address in our server logs.
    Why, and how it is protected: delivering notifications you asked for, and understanding which builds are being downloaded. Two honest caveats. The hash in the download record uses a fixed salt, so it is pseudonymous rather than anonymous: anyone holding both the hash and a candidate address can confirm a match. And the download endpoint separately writes the raw IP to application logs for abuse detection, which the hashing does not cover. Both are improvements we owe you rather than controls we are claiming.
  • Directory-provisioned identities (Enterprise)Examples: when your employer connects a directory, the name, email and directory identifier it sends us for each user it provisions.
    Why, and how it is protected: creating and deactivating accounts on your organisation’s instruction. Your employer decides what is sent; we act on it.

Why this table grew. A review compared it against every write path in the product and found the six categories above missing: the things you send us on purpose (feedback with its diagnostic logs, content reports and support transcripts), search history and memories, profile fields, the early-access list, device tokens and download records, and directory-provisioned identities. All of it was already being collected; this page had not kept up. If you add a collection point and do not add a row here, that is the defect this paragraph exists to prevent.

Hosted AI providers we may route requests to (Managed Cloud): Anthropic, OpenAI, Google, xAI, DeepSeek, Perplexity and Moonshot directly; Qwen and Zhipu through OpenRouter, which therefore also handles those requests, unless AGI holds its own key for that provider, in which case the request goes to it directly. MiniMax models receive nothing from Managed Cloud and are reachable only with your own key. Which one depends on the model you select, with one exception. On the Free plan, a chat on the default model goes to a provider AGI chooses, not one you pick: Alibaba Cloud Model Studio, on AGI’s own key at its international endpoint in Singapore, or OpenAI. At Alibaba the model that answers can be a Qwen model or another developer’s model that Alibaba hosts; at OpenAI it is one of OpenAI’s own models. Which one answers depends on what is available for that turn, and the reply shows the model that answered. A turn that needs tools, web search or code execution is answered by OpenAI. Alibaba’s published privacy notice says it never uses your data for model training; we rely on that statement and cannot verify it. OpenRouter is additionally the failover for every other chat model in the catalogue, so if a direct route fails, prompt content for a model from any provider can pass through it. We would rather say that than let the two named families imply a narrower answer. The full current list with regions is at /subprocessors. BYOK routes from your client directly to the provider; Local contacts none of them.

If you never opened an account and your data is in here anyway

The rest of this notice is written to the person holding the account. This part is written to everyone else. Text typed or pasted into a chat, files uploaded to it, and whatever a connector fetches when an account holder points the agent at a mailbox, calendar, drive or CRM routinely carries personal data about people who never signed up: a colleague on the thread, a guest on the invite, a name in the spreadsheet. So do the identities an employer’s directory provisions for people who may never sign in. We do not ask those people for anything and we do not contact them; nothing in the product does.

What happens to it. It is kept as part of the record it arrived in and gets that record’s treatment: the storage described in the table above and the clock in section 05, nothing separate. In Local it never reaches us. In BYOK it goes from the account holder’s client to their provider, not to us.

On what basis. In Managed Cloud we hold it as the account holder’s processor and act on their instruction under the DPA; they are the controller, and bringing your data in was their decision, not ours. Our own processing rests on our contract with them rather than on any consent from you, and the terms make them confirm they were entitled to give it to us, including having given any notice or obtained any consent your law required first. That duty is theirs and we cannot discharge it for them.

What you can do about it. File an access, correction, erasure or grievance request at /privacy/requests without signing in: the form asks for a contact address, not an account. Two limits, said here rather than discovered later: we can only act on a record we can locate, so the request needs enough detail to find it; and where the data sits inside a customer’s account we hold it on that customer’s instruction, so we will usually have to route your request to them rather than act on it ourselves.

02 · What we do not collect

Training data

AGI does not train AGI-owned models on customer prompts, responses, or files. In Managed Cloud, we send prompts and attached content to the provider serving the model you select and receive its response; on the Free plan’s default model that provider is chosen by AGI, as section 01 sets out. Some models are reached through OpenRouter or through an inference gateway instead of directly, and /subprocessors names each of those and the condition under which it carries a request. Those third parties handle that content under their applicable terms and data-use policies; this statement about AGI-owned models is not a promise on their behalf. In BYOK mode, provider handling is governed by your own provider account and terms. For Experiential Labs promotional routes, its Free organization setting captures prompts and responses for up to 30 days and its published policy permits using captured content to develop, evaluate and improve its services and hosted models. Its no-training routing setting restricts upstream providers, not this platform capture. Selecting one of those routes sends your content under that provider policy; use another model for content you cannot share on those terms.

Provider traffic in BYOK mode

When you BYOK against Anthropic, OpenAI, Google or another provider, the request goes from your client to the provider. We do not see, log, or store that traffic.

Local-mode anything

Local mode uses on-device or local model routes and does not silently send chats, files, or developer sessions to BYOK providers or Managed Cloud.

Advertising and cross-context profiles

We run no advertising, set no advertising cookies, and do not sell or share personal data for cross-context behavioural advertising.

03 · How we use it, and on what basis

One row per purpose, rather than a sentence listing four bases and leaving you to work out which applies to what. Where a row says legitimate interests, it also says why we think ours do not override yours. That balancing test is the part a bare list omits.

  • Creating and running your accountData used: email, account identifier, authentication metadata, settings.
    Basis: performance of a contract. You asked us to run an account; it cannot exist without these.
  • Running the assistant (Managed Cloud)Data used: conversations, files, projects, memories, schedules.
    Basis: performance of a contract. This is the service itself. Local and BYOK do not produce this data for us at all.
  • Taking paymentData used: billing identifiers, plan, invoice metadata. Card numbers go to Stripe and never reach us.
    Basis: performance of a contract, and legal obligation for the records tax and accounting law requires us to keep.
  • Answering youData used: support conversations, feedback, content reports.
    Basis: performance of a contract when you are a customer; legitimate interests otherwise. You initiated the contact, and we cannot reply without keeping what you sent.
  • Keeping the service secure and availableData used: server logs, server and edge operational error reports, the security audit log, rate-limiting state, account status.
    Basis: legitimate interests. Every user has an interest in the service not being taken over or abused, the data is operational rather than content, and you cannot opt out of it without also opting out of being protected by it.
  • Preventing referral abuseData used: the referral program checks described above.
    Basis: legitimate interests. Referral rewards are meant for genuine new customers, and the checks compare signals you already give us or Stripe already holds instead of adding new tracking.
  • Understanding which builds are downloadedData used: download records: hashed IP, user-agent, referrer, coarse country, plus the raw IP in server logs, as section 01 says.
    Basis: legitimate interests. Narrow, and the honest caveats about the fixed salt and the raw log entry are in section 01 rather than buried here.
  • Crash and error reportingData used: consented browser error reports with a stable user id. Sensitive request fields are removed and free-text diagnostics are masked for secret-shaped values.
    Basis: your consent. Off unless you turn it on in settings. Server and edge operational error reporting falls under Keeping the service secure and available above and does not attach a stable user id.
  • Product analyticsData used: aggregated page views on this site, and product usage events from the AGI apps on web, desktop, mobile, Chrome, VS Code and the command line, recorded against your account: that a response was stopped or regenerated, that a suggested edit was accepted or dismissed, and similar product steps, with fixed labels such as your plan or the model provider. They never carry your messages, code, files or file names.
    Basis: your consent. Nothing loads or is recorded until you give it, and the gate fails closed: if your choice cannot be read, analytics stays off. Analytics consent given before this disclosure (notice revision product-analytics-v1) covered page views only, so the app events need you to allow analytics again. Change it any time from Settings in any AGI app or on the data rights page; a workspace administrator can also turn it off for every member.
  • Telling you when something opensData used: the email you gave the early-access list.
    Basis: your consent, recorded per purpose against the revision of this notice you were shown, before the address is stored.
  • Marketing emailData used: your account email.
    Purpose: Email me product news, tips and offers.
    Basis: your consent, asked in a separate unticked box at sign-up or when you first accept the terms after signing in, if no decision is on record for this purpose. You can also choose in Settings, Privacy, or withdraw on the data rights page. Your decision is recorded against the revision of the privacy notice you were shown. No marketing email is sent by the product yet.
  • Complying with the lawData used: whatever a valid legal process compels, narrowed to the minimum.
    Basis: legal obligation.

India works differently and has its own page. Under the Digital Personal Data Protection Act, 2023 consent is the default ground rather than one of several, so the analysis is not the same as the table above. It is at /privacy/india, and it governs for data principals in India where the two differ.

04 · Sharing

We share data only with the subprocessors listed at /subprocessors, and only as necessary to run the service. We do not sell data. We may disclose data if compelled by valid legal process; we narrow such disclosures to the minimum required. If AGI is involved in a merger or sale of assets, personal data may transfer as part of it, and this policy continues to apply until the acquirer publishes its own.

Government requests. What legal process we require, when we tell the account holder, and where a request must be sent are on the government requests page.

Links you share yourself. A share link to a conversation, or a published artifact, is public by design: anyone who has the link can open it without signing in, unless you limited it to your workspace. A conversation link lasts 1, 7 or 30 days, as you choose, and you can revoke it sooner. A published artifact stays up until you unpublish it. Before a conversation is shared, secrets we can recognise are removed from the copy, and the shared page shows an attached file by name only. Both kinds of page tell search engines not to index them and not to follow their links. That is a request a search engine can ignore, and it does not stop a person who has the link from copying or reposting what it shows. Do not share anything you would not publish.

Who at AGI can see your content

In Managed Cloud we store your conversations and files, so the honest answer is not “nobody”. Access to your content by people at AGI is limited to those who need it to operate or support the service, and to the cases in the table below. The text filter described in the acceptable use policy is automatic. When it refuses or flags a request, it logs the rule that matched and a one-way fingerprint of the text, not the text. Suspending or banning an account is done by a person, not by an automatic check.

  • What you ask us to look intoFeedback and any screenshot or log you attach to it, a support ticket, a chat you escalate to a person in support, and a privacy request. Staff read these to answer you.
  • Abuse and safety reportsA report someone files, with the excerpt they chose, and the shared conversation or published artifact it is about. Staff look published material up by the public link anyone already holds.
  • Workspace content, for supportOnly under a support access grant that names the workspace, what may be read, a ticket and a reason, and that expires within eight hours. The grant and every read under it are written to a log the workspace can read. The full mechanism, and its limits, are on /security.
  • Security and the lawWhere it is necessary to investigate abuse, a security incident or a fault, or where valid legal process compels it.

Google user data

This covers every Google connector, including Gmail, Google Calendar, Google Drive and Google Contacts. Connectors are coming soon and cannot be connected yet; this section says how Google data is handled once they can. AGI’s use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements, and to the Google Workspace API User Data and Developer Policy.

  • AccessOnly after you connect a Google account, and only when you ask for it in a chat or in a routine you set up. A routine that starts on new mail receives the sender, recipients, subject, labels and a snippet of up to 500 characters of each new inbox message. Nothing syncs or indexes your Google account in the background.
  • UseOnly to provide the feature you asked for, such as reading and drafting mail, sending a message you approve, reading and creating calendar events, searching and reading your Drive files and looking up contacts.
  • AI trainingWe do not use Google user data to develop, improve or train generalized AI or machine learning models. Once a chat or routine can reach Google data, we send it only to AI providers whose terms bar training on it. If the model you picked cannot run that way, we tell you and send nothing.
  • MemoryWe do not save memories from a chat that holds Google data. That chat, the memories drawn from it and files imported from Google reach your other chats only when those chats are also kept to AI providers that do not train on them.
  • TransferWe do not sell it, and we do not transfer it to advertisers, data brokers or information resellers or use it for advertising or credit decisions. It goes only to the subprocessors that run your request, such as the AI provider serving it, and otherwise only for security, to comply with law, or in a merger or sale of assets with your prior consent.
  • PeopleNo one at AGI reads it unless you ask us to, for example by escalating a chat to human support, which sends us that chat; unless it is necessary for security, such as investigating abuse or a bug; or unless the law requires it.
  • TokensThe tokens that connect your account are encrypted at rest with AES-256-GCM. When you disconnect or delete your account, we ask Google to revoke them and erase our copy. You can also remove AGI at myaccount.google.com/permissions.
  • RetentionWe keep no separate copy of what a connector retrieves. It persists only where it lands: in a chat reply and that chat's search index, in a routine's run history, or as a Drive file you import into a project. A deleted chat or project can be restored for 30 days and is then permanently deleted. Deleting a routine deletes its run history at once. Workspace retention settings also apply, and deleting your account erases all of it.

05 · Retention

Every row below is a job or a mechanism that exists in the product, with the ones we do not control named as such. We would rather publish a shorter schedule that is true than a complete-looking one that is not.

  • Account and its contentRetention: kept while your account is active. Permanently erased 24 hours after a deletion request.
    Enforced by: the request records a deletion timestamp and schedules erasure 24 hours out; a daily scheduled job then erases your user-scoped records and stored objects and deletes your identity at our authentication provider.
  • Billing recordsRetention: erased with the account, or aged out at the end of the statutory record-keeping period (8 years), whichever comes first for that row.
    Enforced by: your subscription, credit ledger and usage rows are erased with everything else. Three things survive on purpose, and you should know about them: an organisation’s billing history keeps the ledger row with your user id removed, because the record belongs to that organisation rather than to you; double-charge protection keys and any payment still moving when you delete are kept, because deleting those can charge you twice or lose money we owe you; and Stripe holds its own record of your payments and invoices under its retention, not ours: card numbers go to Stripe directly and never reach us. A daily scheduled job now enforces a maximum age on the rows that outlive an account. Books of account (the credit ledger and the organisation usage ledger) are kept 8 years and then deleted, and the request-shaped metadata beside them is emptied after 2 years because the amount, the type and the date are the record, not the routing detail. Metering events are deleted after 2 years and their metadata emptied after 180 days. Double-charge protection keys are deleted once their 24-hour window closes, completed settlement jobs 90 days after they finish, and payment-webhook receipts 180 days after processing, with any error text they captured cleared after 30 days. Two things carry no maximum age and we will not pretend otherwise: your current plan row and your current credit balance, because ageing those out would cancel a live subscription or delete credits you paid for. They go when the account goes.
  • Conversations (Managed Cloud)Retention: kept until you delete them or delete your account, unless your organisation has switched on a retention window, in which case that window also applies. A deleted conversation can be restored for 30 days, then a daily job permanently deletes it with its messages and search index.
    Enforced by: nothing expires a personal conversation automatically. A conversation that belongs to an organisation workspace is different: an owner can set a retention window on that workspace, and a nightly scheduled job then permanently deletes workspace conversations with no activity for longer than it. That sweep is off unless the workspace switches it on, it never touches a personal conversation, conversations under a legal hold are withheld from it, and every run is recorded. This page previously said no such window was enforced; the job was running, and the denial is corrected here rather than quietly dropped.
  • Temporary chats (Managed Cloud)Retention: about 30 days.
    Enforced by: a daily scheduled job hard-deletes temporary conversations past the window; messages go with them. A workspace legal hold that covers a conversation keeps it until the hold is released.
  • Background jobs (Managed Cloud)Retention: up to 30 days.
    Enforced by: the job runner, every few minutes. Jobs that finished are deleted within 30 days. Jobs that failed for good, including Gmail and Google Calendar trigger events, are deleted 30 days after they fail.
  • Deleted filesRetention: 30 days in the recently-deleted bin, then the bytes are removed.
    Enforced by: a daily scheduled job hard-deletes the records and deletes the underlying objects from storage. If an object deletion fails, the record survives and the next run retries it.
  • SandboxesRetention: within 24 hours of creation, or sooner once its resume mapping is gone.
    Enforced by: a scheduled job that runs every hour enforces a 24-hour age cap on every sandbox (matching the resume mapping’s own 24-hour expiry) and reclaims it at that cap or as soon as the mapping no longer points to it, whichever comes first. A sandbox that is merely paused gives its slot up after two hours rather than twenty-four.
  • Feedback and response ratingsRetention: kept until you delete your account. Nothing ages them out earlier.
    Enforced by: account deletion erases the feedback records, ratings included, and deletes any screenshot you attached to feedback from storage. If a screenshot cannot be deleted, the record is kept and the next run tries again. A new rating on a reply replaces your earlier rating on that reply. Feedback sent without signing in is not tied to an account, so account deletion does not reach it. Ask at /privacy/requests and we will remove it.
  • Security audit logRetention: 90 days.
    Enforced by: a database routine deletes entries older than 90 days, run by a scheduled job every night: /api/cron/purge-security-audit-logs at 02:07 UTC, registered in vercel.json. This entry previously said the routine was run by an administrator rather than on a schedule; that stopped being true when the cron was added, and the policy is corrected here rather than left understating what happens.
  • Server logs and backupsRetention: vendor-governed.
    Enforced by: platform logs and database or object-storage snapshots are retained according to our hosting vendors’ own configuration. We do not operate a separate process that reaches into vendor snapshots to remove individual records, and we will not claim a number we do not set.

What deliberately survives deleting your account

“Delete my account” erases an enumerated list of 118 user-scoped tables and your stored files. A short list of things is kept on purpose, and you should know what before you decide, not after.

  • Security and organisation audit log entries naming youBoth audit trails are append-only integrity controls, enforced by database privilege rather than by our code. On the security trail the application role can add an entry but cannot update or delete one; on the organisation trail it cannot insert either, and writes go through a privileged routine instead. That is the point of an audit trail. Erasure does not purge them. We are recording that as a gap rather than describing the erasure as total: a separate privileged routine exists to purge them, and it is not part of the automatic path.
  • A record that you were erasedA suppression entry survives so the system can tell that this subject must stay erased. Deleting it would erase the evidence that the erasure happened.
  • Double-charge protection keys and payments still movingDeleting these can charge you twice or lose a settlement owed to you. They outlive the account they protected.
  • Rows that belong to an organisation rather than to youAn organisation's billing ledger keeps the row with your user id removed; files you added to a shared project keep the file and drop the attribution; abuse reports you filed about someone else keep the report and drop you. Deleting an organisation because its creator left would erase every other member.
  • Stripe's own recordsYour payments and invoices sit with Stripe under its retention, not ours. Card numbers go to Stripe directly and never reach us.
  • Anything given without an account, keyed to an addressAn early-access email, a consent decision or a rights request made without signing in is not reachable by account deletion, because there is no account to delete. Nothing ages those out automatically either. Use the request form at /privacy/requests and we will remove them.

Security incidents

We keep a written procedure for a personal data breach: who declares one, what goes into a notification to a regulator, and what an affected person is told. It runs against a 72-hour clock for notifying a regulator where a law requires one, which is the same commitment the terms make. The safeguards the procedure sits on top of are at /security, including the parts of that posture we have not built.

How a notice would actually reach you. AGI sends email to one account at a time; the Resend entry on /subprocessors lists those messages. No operator procedure for emailing a set of affected customers has been built or exercised. So a notice to you would arrive as an in-product message and at a dated public address rather than by email, with direct email only where we hold your address and a person sends it by hand. Neither that in-product notice nor that public page exists as a built feature today; they would be put up during the incident. The same statement is in section 10 of the India notice.

06 · What you can change yourself

Controls that exist in the product right now, separated from the statutory rights in the next section on purpose. A right you have to write in and ask for is not the same thing as a switch you can reach, and a policy that mixes them makes the product sound more self-serve than it is.

  • Export your dataAccount settings. Downloads the reviewed personal and account-data sections with a completeness record. Complete means every reviewed section was read without skipped or truncated rows; partial names anything unavailable, skipped, or truncated. Live secrets, credential verifiers, and product-internal cost ledgers are intentionally excluded. Every export is rate limited and written to the security audit log. Where something is missing, use the access request in the next section.
  • Delete your accountAccount settings. Erasure is scheduled 24 hours out, then performed by a daily job that also deletes your identity at our authentication provider. Read the survivors table in section 05 first. Cancellation is self-serve: sign back in and cancel from Settings > Account any time before the 24 hours are up.
  • Withdraw a consent/privacy/requests. Per purpose, one click, immediate. Withdrawing an optional purpose never costs you access to anything you did not withdraw.
  • Turn analytics offThe cookie preferences dialog, reachable from /cookies. It is already off until you turn it on; this is how you change your mind.
  • Turn crash reporting offSettings. A separate switch from analytics, in a different place, because they are different vendors doing different things. We would rather say that than imply one toggle covers both.
  • Clear your search historySettings. Removes the stored history for your account.
  • MemoryOff unless you enable it. When on, the assistant keeps facts about you across sessions, and you can remove them.
  • Temporary chatThe composer. A temporary conversation is hard-deleted by a daily job about 30 days later, messages with it, unless a workspace legal hold covers it.
  • Delete a conversation or a fileIn the product. Deleted files sit in a recently-deleted bin for 30 days, then the bytes are removed from storage.
  • Choose where a request goesIn the CLI, Local keeps the conversation on your machine and sends us nothing; BYOK goes straight to your provider on your key. The download page shows which CLI releases are published. VS Code BYOK is coming soon. Web and Desktop are cloud-only.

07 · Your rights, and how to use them

Depending on where you live and subject to applicable exceptions, privacy laws such as the GDPR, UK GDPR, and CCPA may give you rights of access, correction, deletion, portability, objection or restriction, and non-discrimination. Two requests are self-serve in the product:

  • ExportSigned in, you can export your data from the account export endpoint at any time. It is rate limited and each export is recorded in the security audit log.
  • DeletionRequest account deletion from the product. Erasure is scheduled 24 hours later and then performed. You get no confirmation email. Cancellation is self-serve: sign back in and cancel from Settings > Account any time before the 24 hours are up, and the request is discarded without touching your data. Once that window has closed the product refuses to cancel, so the request cannot be revived after erasure begins.
  • Everything elseEmail contact@agiworkforce.com from your account address with the subject line “Privacy request”, or use the form at /privacy/requests, which gives you a reference. You may use an authorised agent where the law allows.
  • How long we takeWe aim to answer within 30 days. Where your law sets a period, that period applies if it is shorter. Most United States state privacy laws, California's among them, give 45 days and allow one extension of 45 more when we tell you why within the first 45. The GDPR gives one month, which can be extended by two more for a complex request. Requests are worked by a person, not by an automatic process.
  • If we say noWe tell you why. You can appeal by emailing contact@agiworkforce.com with the subject line “Privacy request appeal” and your request reference. We answer an appeal in writing, with reasons, within 45 days. We are a small company, so we cannot promise that a different person reviews the appeal from the one who made the first decision. If the appeal is refused, you may complain to the attorney general of your state, or to your data protection authority.

EU, UK and Swiss residents may also lodge a complaint with their supervisory authority. California residents: we do not sell or share personal information, so there is no opt-out to exercise, and the CCPA service-provider terms we operate under are in section 06 of the DPA.

Automated decisions. We do not make a decision that has a legal or similarly significant effect on you by automated means alone, and we build no profile of you for that purpose. Some checks do act without a person, and each affects one request or one reward, not your account: a rate limit refuses requests over a ceiling; the text filter refuses a request that matches one of its rules; and the referral checks in section 01 withhold a referral reward. Suspending or banning an account is never automatic. A person does it. If one of these checks got it wrong, write to contact@agiworkforce.com and a person will look at it.

Sensitive personal information. We do not ask for it, and you can use the product without giving us any. That covers details such as your health, race or ethnic origin, religion, sexual orientation, immigration status, precise location, government identity numbers and the contents of your private messages. It reaches us only if you put it in a chat, a file or a profile field, or connect an account that holds it. When it does, we use it only to provide what you asked for, which includes memory if you turned memory on. We do not use it for advertising or to build a profile of you for any other purpose, and we do not sell or share it. Voice audio is not stored and no voiceprint is made, as section 01 says.

Health information. AGI is not a medical service. It is not offered for protected health information under HIPAA, and we sign no business associate agreement. That is a statement about organisations sending us patient records. It does not mean health details never reach us: what you type or upload about your own health is conversation content like any other, kept and deleted as section 05 says. One connector, HealthEx, is built to read your own health records at your request. Connectors are coming soon and none can be connected yet, HealthEx included. When it opens, it is a personal feature: it is offered only in the United States and only where it is switched on, it is not available inside an organisation workspace, it can read records and cannot change them, and its tools are offered only inside your Health space. A chat in the Health space is sent only to providers we have recorded as not training on what you send; if the model you picked is not one of those, the request is refused and you are asked to choose another. AGI is not a HIPAA covered entity or business associate for this connector.

08 · International transfers

AGI data is hosted in the United States. We do not offer EU or UK data residency, so European customers’ data is transferred to and processed in the US. For EU, UK and Swiss personal data we rely on the Standard Contractual Clauses with the UK Addendum and the Swiss adaptations, set out in section 06 of the DPA. AGI has not appointed a representative under GDPR Art. 27; the current position is at /legal/eu-representative.

09 · Children

You must be at least 13 to create an account, and anyone under 18 needs permission from a parent or guardian, as set out in section 02 of the terms. Sign-up asks for your age to apply that rule. The number is checked in your browser and is not stored, sent to our servers or sent to our identity provider, and we do not verify it or the permission. We do not knowingly collect personal data from children under 13, or under the higher digital-consent age where one applies. If you believe a child has provided us data, email us and we will delete it.

10 · Changes

We may update this policy. The current version is always at this URL with the revision date at the top, and material changes are recorded on /changelog. No mailing path in this product can reach an arbitrary list of customers, so we do not promise emailed notice of a change.

11 · Contact

AGI Automation LLC, c/o registered agent, 5900 Balcones Drive STE 100, Austin, TX 78731, USA. Email contact@agiworkforce.com.