Privacy Policy
Who is responsible
Agentile is run by one person: Landice Fu, in Taiwan. He decides what is collected and why — in data-protection language, he is the controller. There is no company, no staff and no second operator.
Contact: landicefu@gmail.com
Which law applies, and why we do not argue about it
This service is run from Taiwan, on infrastructure in the Asia-Pacific region. It is invite-only, free of charge, offered in English and 繁體中文, and marketed nowhere. Which data-protection laws reach a service of that shape is a question with a genuinely complicated answer, and different regulators would answer it differently.
We have taken the position that arguing about it is not worth your time or ours. This policy describes what actually happens to your data, and offers the protections those laws require — this information, correction, deletion, and a copy of your data — to everyone who uses it, wherever they are. Where a legal basis is named below, it is the basis we rely on; nothing here turns on which law you are covered by.
What we hold
When you sign in. There are two doors and they lead to the same
account. With Google: your email address, your name and the URL of your
profile picture, taken from the identity token Google returns. We ask Google for
openid email profile and nothing else, and we never receive and never
store your Google password. With a sign-in link: you type your email address
and we email a single-use link to it. We store that address, a one-way hash of the
link — never the link itself, so a copy of our database cannot sign anybody in — and
the moment it expires, which is 15 minutes later. That record is deleted the following
night. Either door tells us your email address and nothing more, and from it we derive
a handle — the part before the @, lowercased — which namespaces anything
you publish.
What you write. Pages: their titles, their blocks, and everything in them. Files you upload — images, audio, video, documents. Anything an agent writes on your behalf through the API or through MCP, which is the normal way pages are made here.
What you do on a page. Ticks, notes, answers, review grades, amounts — what the platform calls reader state. Almost all of it belongs to the page rather than to you. A tick on a checklist is stored against the page, so everybody who can see that page sees the tick, and on a page you have made public that means anybody with the link. This is deliberate — a shared checklist that showed each person a different set of ticks would be useless — but it is worth knowing before you type something private into a widget on a page other people can read. The one exception is a study record: a flashcard's grade and its schedule are filed under your account, follow you from page to page, and nobody else sees them.
Sharing. When you share a page with someone by email address, we store that address, whether or not that person has an account here. When someone shares a page with you, their record holds your address.
Feedback. If you or your agent sends feedback, we store its text, its category, and which account sent it.
Preferences. Language, how long to keep version history, and various view settings. Several of these live only in your browser — see Cookies.
Technical records. Cloudflare, which runs and stores everything, records requests to the service — the URL, the status, how long it took — and we have that logging switched on so that faults can be diagnosed. Those records include your IP address as seen at Cloudflare’s edge, and we use that address as a key for rate limiting. Cloudflare holds the request logs under its own retention, which we do not set. In our own database we store your IP address in one place only — the security records described next, which are about signing in and nothing else.
The record that you accepted the Terms. One row: your account, the version of the Terms of Service you accepted, and when.
Security records. Signing in is the one place where an ordinary action, repeated often enough, is an attack — so we keep a record of it. One is written when a sign-in link is asked for, when a sign-in is refused, when a link or an API token is presented and rejected, and when one of our limits is reached. Each record holds the time, what happened, the email address that was typed, the account it belongs to if it belongs to one, your IP address, the country Cloudflare reports for it, and the string your browser sends identifying itself. Ordinary use of the service writes nothing here — reading a page, editing one, uploading a file — and nothing about the content of any page ever reaches it. These are kept for a year and then deleted. They are the only place in our own database where an IP address is stored, and they exist because a log of failed sign-ins that cannot tell one visitor from another cannot do the job it is for.
What we do with them. If someone asks to sign in more than five times in an hour, or ten times in a day, we stop accepting sign-ins for that address until the hour or the day is over. We count against the address and against the network address the request came from, because those catch different things: one person locked out of their own account, and one machine working through a list of other people’s addresses. The block lifts by itself, and nothing else about you is decided automatically.
What we do not collect
No advertising. No tracking pixels. No fingerprinting. We do not sell anything to anyone, we do not build a profile of you out of what you write, and no content of yours is used to train any model.
Analytics is the one exception to “no third-party scripts”, and it only happens if you say yes. The next section is what it is.
Analytics, and the choice you are given
We use Google Analytics to see how the site is used — which screens people reach, which widgets get used, where something is slow.
It is off until you switch it on. Before you answer the banner, nothing is loaded from Google, nothing is written into your browser, and nothing is sent anywhere. Say no, or close the banner without answering, and nothing loads at all. You can change your mind whenever you like: the control is in Settings if you have an account, and under any public page if you do not. Switching it off stops the tag at once and deletes the two cookies below from this browser.
What Google never gets, even when you have said yes. Not the address of the page you are looking at, not its title, and not the page you came from. On this site a page address names one specific private page, so those three are suppressed in three separate places in our code, and a test fails if any of them comes back. Google can see that a page was opened and what sort of widget was on it. It cannot see which page.
What Google collects anyway, which we cannot switch off. A random
identifier kept in your browser (the _ga cookie — this is the thing the
banner is really asking about), your IP address, your browser and its language, and
your exact screen size. And if you happen to be signed in to a Google account, Google
may tie the visit to that account across your devices and work out an age band and
interests from it, because this property has Google’s “signals” feature switched on.
That is the honest weight of saying yes, which is why we ask before a single byte
loads rather than after.
Google Analytics is run by Google LLC in the United States; see Who else touches it.
Why, and on what basis
| What for | The basis we would rely on |
|---|---|
| Signing you in and running your account | Performance of the contract the Terms make with you |
| Storing, indexing and displaying your pages and files | Performance of the contract |
| Rewriting the stored form of a page so it still displays after the platform’s data formats change | Performance of the contract — keeping the pages you already have working. A rewrite done to enable something new rather than to keep something working would be a different purpose, and we would say so before doing it |
| Keeping version history of every change | Our legitimate interest in being able to undo a mistake — and it is a security measure in its own right, being the ability to restore data after an incident |
| Rate limiting, preventing abuse, keeping the service up | Legitimate interest in a service that works |
| Keeping the security records above, and blocking a burst of sign-in attempts | Legitimate interest in accounts that cannot be broken into — a purpose the GDPR names itself, at Recital 49 |
| Backups | Legitimate interest in not losing your data |
| Answering you, and handling abuse reports | Performance of the contract, and legitimate interest |
| Recording which version of the Terms you accepted | Our need to be able to show what was agreed |
| Analytics, if you switched it on | Your consent — the only thing here that runs on it, and the only thing that stops the moment you withdraw it |
We do not rely on your consent to run the service, and that is deliberate. Consent can be withdrawn at any moment; a service whose only basis for holding your pages was a ticked box would have to stop working the instant you changed your mind about the box. Analytics is the one thing that does rest on consent, and that is the right way round: it is not part of running the service, so withdrawing it costs you nothing. This is also why the sign-up screen asks you to agree to the Terms but only to confirm you have read this policy: a privacy policy is a disclosure, not a bargain.
Where it is stored
Everything is on Cloudflare. The database (Cloudflare D1) reports its region as APAC, and both object-storage buckets (Cloudflare R2) — the one holding uploaded files and the one holding backups — report their location as APAC.
No jurisdiction restriction is set on any of them. Cloudflare offers one; we have not used it. That means Cloudflare is not contractually prevented from placing or moving data outside that region. We are saying this plainly rather than glossing it: if you need your data to stay inside a particular jurisdiction, Agentile does not do that today.
The operator administers the service from Taiwan.
Who else touches it
Two companies, and only two.
| Who | What for |
|---|---|
| Cloudflare, Inc. (United States) | Running the service (Workers), the database (D1), files and backups (R2), the key-value store the MCP sign-in flow requires (KV), the embedding model described below (Workers AI), sending the one email we send (Email Service), and the request logs |
| Google LLC (United States) | Sign-in, if you use the Google door: Google tells us who you are. And Google Analytics, only if you switched it on — never the address or the title of any page. See Analytics |
Workers AI. When you search the widget catalogue, the words of your query are sent to a model on Cloudflare’s network so that they can be turned into a vector. The content of your pages is never sent to any model. Searching your own pages is a plain text match inside the database.
The only email we send is the sign-in link, and it goes out through Cloudflare’s own email service — the company already named above, not a new one. There is no support-desk provider, no error-reporting provider, no newsletter and no other network in front of the site. The only analytics is the one described under Analytics, and only if you agreed to it.
How long we keep things
| What | How long |
|---|---|
| Your pages and files | Until you delete them |
| Trash | 30 days, then permanently deleted |
| Version history | 30 days by default, and you can change that in Settings. At most 20 revisions per page, and the 5 most recent are kept whatever their age |
| Temporary pages | 14 days by default; an agent may ask for a different figure, up to a year |
| Reader state whose block has been removed | 30 days |
| Session cookie | 30 days, or until you sign out |
| Sign-in link | The link expires 15 minutes after we send it; the record of it is deleted the following night |
| Security records (see What we hold) | 365 days |
| Database point-in-time restore (Cloudflare D1 Time Travel) | 30 days |
| Daily backup | 35 days |
| Weekly backup | 90 days |
| Monthly backup | 365 days |
| Deletion record (see below) | 365 days |
| Feedback you sent | Kept, but it stops naming you when your account is purged |
Deleting your account
You can delete your account yourself, in Settings. You have to type your own email address to unlock the button, because the route deletes whoever is calling it and two tabs signed in as different people is an ordinary way to get that wrong.
Immediately, when you ask:
- the account stops working — every signed-in session on every device is ended at once, and every API token you had issued is revoked;
- all your pages are moved to the trash, so anyone you had shared one with loses access to it.
Nothing in that is irreversible, on purpose. For the next 30 days you can change your mind: sign in again and the app offers to restore the account. What comes back is exactly what the deletion took — a page you had thrown away yourself before deleting the account stays in the trash, because the restore matches the deletion’s own timestamp rather than everything that happens to be deleted.
After 30 days the nightly clean-up finishes it, and that part cannot be undone. Permanently deleted: your account row, your pages, your uploaded files, your reader state, your notes, your tokens and your preferences. At the same moment, grants other people made that named your email address are removed, so your address stops appearing on their pages — those people are not notified and they lose a grant they created. That is us changing a third party’s record, so it is written down here rather than left implicit.
Thirty days is the same figure the trash, version history and the database’s own point-in-time restore already use — one number rather than several — and it is inside the one month that data-protection law allows for answering an erasure request.
Feedback you sent keeps its text but stops naming you: the report outlives the account, because what it says about a missing feature is still true.
Security records stay, and stop naming you the same way: the email address and the account identifier are cleared, and what is left is that something happened, when, and from where. Deleting them outright would make closing an account a way to erase the record of what was done with it, which is the one case they exist for; keeping the address would defeat the erasure.
What is left afterwards is one row we call a tombstone: your account’s internal identifier and the date. No email address, no name, nothing else. It exists for one situation, described next. It is deleted after 365 days.
Backups, and the honest part about them
Backups are whole-database snapshots. They are compressed and encrypted with AES-256 before they leave the machine that makes them; the passphrase is not on any server that runs the service, and the bucket that holds them is deliberately not connected to the service, so a compromise of the service cannot reach or destroy them. They are used for one thing: restoring the service after a failure.
We do not open a backup to remove one person from it. Nobody does — a backup is a single encrypted blob, not a set of records to edit. What we do instead is the accepted practice: delete you from the live system, leave the backups alone and use them for nothing else, and let them expire on the schedule above. The last copy that could still contain you is gone 365 days after it was taken.
There is a hole in that, and we closed it rather than leaving it unsaid: if we ever did restore a backup, accounts deleted after that backup was taken would come back alive. That is what the tombstone is for. After a restore, it re-applies the deletion. It holds an internal identifier rather than an email address for three reasons — a list of deleted email addresses is still a list of email addresses; the same person signing up again gets a new identifier, so an email-keyed record would delete the new account they just made; and an identifier that no longer exists cannot function as a blocklist. It is kept for 365 days because that is the longest a backup lasts, after which it protects nothing.
What you can ask us for
- A copy of your data. Sign in and open
/api/me/export. It downloads one JSON file holding your pages, what you have done on them, your notes, the details of your uploaded files, your tokens, your security records and your preferences, with a plain-language note at the top explaining what every section is. Uploaded files are listed with a download link each rather than packed inside. There is no button in Settings for it yet — that link is the whole of it — and you may take five copies a day. If it does not work for you, ask, and we will produce one by hand. - Correction of anything wrong. Most of it you can correct yourself by editing the page.
- Deletion — in Settings, as above, or by asking.
- An explanation of anything in this document, or of what we hold about you.
- To object to a use of your data that rests on our legitimate interest rather than on the contract.
Write to landicefu@gmail.com. We will answer within 30 days.
Security: what we actually do
The useful thing a policy can say about security is what is in place, not what is disclaimed. These are checked, and several are enforced by the build rather than by somebody remembering:
- Sign-in is Google only. We hold no password, so there is no password here to leak.
- Session cookies are signed and carry an epoch counter. Revoking every session on every device is one write, and deleting an account does it.
- API tokens are stored as SHA-256 hashes and never in plain text; the token itself is shown once, when it is created.
- Permission checks are enforced by the type system. A write to a page that has not been through a permission check does not compile — a build failure rather than something an audit has to notice.
- Values in database queries are always bound as parameters, never pasted into the query text. A test enumerates every place a query is assembled from a string and fails when a new one appears.
- Content you author — custom HTML, uploaded files, widget bundles — is served from a separate origin that never receives your session cookie, inside a restrictive sandbox. A page cannot reach your account.
- Every automatic rewrite of your content stores a restorable copy of what it replaced.
- Backups are encrypted, verified after they are taken, and compared against the retention published above by a script that fails loudly when the two disagree.
And the part a security section usually leaves out: there is one operator. Nobody is watching overnight, there is no on-call rota, and the response to anything is as fast as one person can be.
If something goes wrong
If we discover a breach that puts your data at risk, we will tell you, and any authority we are required to tell, as quickly as we can — and within 72 hours of becoming aware of it where that duty applies. That duty is owed under the law rather than under our contract with you, and nothing in the Terms of Service removes it. We are not trying to remove it.
Cookies and browser storage
Three cookies are necessary to run the service, and none of them is used for tracking:
| Name | What it does | How long |
|---|---|---|
agentile_session | Keeps you signed in. Signed, and HttpOnly, so scripts cannot read it | 30 days |
agentile_oauth | Set only during sign-in, to stop a cross-site attack on the sign-in flow | 10 minutes |
agentile_locale | Which language to draw the interface in | Until changed |
Two more are set by Google Analytics, and only after you have said yes:
| Name | What it does | How long |
|---|---|---|
_ga | A random identifier, so Google can tell one browser from another. Set by Google, not by us | 2 years |
_ga_<id> | The same thing, per property: keeps track of the current visit | 2 years |
Your answer to the analytics question is itself remembered in this browser only — we do not store it against your account — so that you are not asked on every page. Answering on your phone therefore says nothing about your laptop, and clearing this browser's site data asks you again. Withdrawing stops the tag immediately and deletes the two cookies above; that deletion is best effort, because a script can only remove a cookie whose name and domain it can work out.
Your browser also keeps preferences in local storage — which sections are open, sidebar state, favourite widgets, theme — and a recovery copy of text you had typed but not yet saved, so that a closed tab does not lose it. All of that stays in your browser.
Children
Agentile is not for anyone under 16, and you must not store data about anyone under 16 on it. If we learn that we hold such data, we will delete it.
Changes to this policy
This policy carries a version, which is a date. When we change it we publish the new version at /privacy, and if a change materially affects you we will say so in the app. We will not ask you to “agree” to it, for the reason given under Why, and on what basis.
Contact
Landice Fu · landicefu@gmail.com
The Terms of Service are at /terms.