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 the free models providers give away, 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 released CLI supports Local and BYOK; VS Code BYOK is coming soon. Managed cloud is open by default, not invite-only. Last updated: 2026-09-22. Managed Cloud is in public alpha.

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 released CLI to Ollama or LM Studio on loopback. Nothing is transmitted to us and nothing is silently routed to BYOK or Managed Cloud.
  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. Available in the released 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 and calls the provider directly.
• Managed CloudWhere your prompts go: through our gateway to the provider serving the model you selected. 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.
  Why, and how it is protected: authentication. 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. Generated videos use a separate private bucket. Images and other non-video files remain in a public R2 bucket: normal product responses do not expose its raw URLs, but anyone who obtains an underlying storage URL can access that object without signing in.
  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.
• 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 released CLI in the operating system credential store.
  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.
• 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, which is one of the three things in this product that can send email at all.
• 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 on 2026-09-22. 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; MiniMax, Qwen and Zhipu through OpenRouter, which therefore also handles those requests. Which one depends on the model you select. 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 three 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; 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.
• 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.
  Basis: your consent. Nothing loads until you give it, and the gate fails closed: if your choice cannot be read, analytics stays off.
• 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.
• 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.

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.
  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.
• 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.
• 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:30 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 95 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. There is no account-lifecycle mail in this product. The only email it can send is support escalation, scheduled-task notification, and operational alerts to us, and none of those can reach a list of affected customers. 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 released CLI, Local keeps the conversation on your machine and sends us nothing; BYOK goes straight to your provider on your key. 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, because the only email this product sends is support escalation, scheduled-task notifications and operational alerts to us: there is no account-lifecycle mail. 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”. Applicable law determines the response period. You may use an authorised agent where the law allows.

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.

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

AGI accounts are for people aged 18 and over; 13- to 17-year-olds may use it only under an account opened and supervised by a parent, guardian or school, as set out in section 02 of the terms. 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.