Privacy Policy

Version 2026-09-26 · English is the only version of this document.

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, and, if you were part-way to a particular page when you were asked to sign in, the address of that page, so that the link can take you back to it. That record is deleted by a nightly clean-up once it is more than a day old, so it lasts up to two days. Either door tells us your email address; Google also tells us the name and picture above. From the address we make a handle — the part before the @ (for a Gmail address, with its dots and any +tag removed first, as Gmail itself ignores them), lowercased, with anything that is not a letter, a digit or a dash turned into a dash and trimmed from the ends, and a number added if that handle is already taken — which namespaces anything you publish. You can also choose a display name in Settings; if you do, it replaces the name Google gave us.

Being on the invite list. Agentile is invite-only, so before any of that there is a row holding the email address that was invited, the date, who added it, and a short note the operator writes to himself about why. An entry can also be a whole domain rather than one address, in which case there is no row about you personally at all. The note is shown to nobody else and is not part of the copy of your data you can download, so if you want to know what yours says, ask. That row outlives your account, and we would rather say so than let you assume otherwise: deleting your account does not take you off the invite list, because the list is not part of your account — it is the operator’s record of who he invited, and it is what would let you come back. Ask and he will remove it.

What you write. Pages: their titles, their blocks, and everything in them. Files you upload — images, audio, video, documents — including a file an agent asks us to fetch from a web address on your behalf. Anything an agent writes on your behalf through the API or through MCP, which is the normal way pages are made here.

Who made each change. Every page keeps a version history (see How long we keep things), and each version records who made the change: your account, or an agent acting for you — and, for an agent, which API token or which connected app it came through. A page also records who created it. The page’s owner, and signed-in people who can read the page, may see your display name beside the changes you made; the name of your token or app is shown only to you.

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 written into the page itself, so everybody who can see that page sees the tick, and on a page you have made public that means anybody with the link. Because it is part of the page, it is also kept in the page’s version history, with your name beside it like any other change, and it stays with the page — not with you — if you later close your account. 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.

Taking part in a page without an account. A page can be set up so that people who are not signed in can fill something in on it — a date poll, a sign-up sheet, a comment. Usually whoever owns that page sends out a link, and holding the link is the whole of it: no sign-in, no invitation, and nothing for us to check you against. A part of a page can also be set up so that anyone who can open the page may fill it in, with no link at all. If you fill one of those in, we store the name you typed, what you filled in, when, and a random identifier that we make and your browser keeps, so that your own entry can be found again when you come back to change it. That identifier is made fresh for each page, so nothing we hold joins what you filled in on one page to what you filled in on another. We learn nothing else about you — no account, no email address, no name you have not typed yourself.

The name is not checked against anything. Anyone holding the link can type any name, and that cuts both ways: a name beside an entry is not proof of who wrote it, and typing your own name is a thing you are choosing to publish. On some parts of a page — a date poll is one — anyone who may fill it in may also change or tick an entry somebody else added. Who can then see the entries depends on how that part of the page was set up — either everyone who can see the page, or only the people holding the link — and it can differ from one part of a page to the next. Whoever owns the page always sees them.

The link does not expire. It works until the owner of the page replaces it, which they can do at any time and which stops every link already sent out. What you filled in stays until you remove it yourself (which only works from the browser that still holds your identifier), until its owner removes it or clears that part of the page, or until the page is deleted. If that part of the page is taken off the page, a nightly clean-up deletes what was filled in on it once it has been gone for at least 30 days, unless it is put back first; How long we keep things and Deleting your account say what that means, and the second of those is the one to read if you want an entry of yours removed.

Sharing. When you share a page with someone by email address, we store that address — in a normalised form and, where it differs, as you typed it — whether or not that person has an account here. When someone shares a page with you, their record holds your address. And when you own a page, anyone signed in who can read it can see your display name, your handle and your email address as its owner — people you shared it with by name, and, for a public page, anybody holding the link who signs in. Somebody reading a public page without signing in is shown none of these.

Finding out whether an address has an account. When you share a page or add a contact by typing an email address, we tell you whether that address has an account here, and if an account exists at an address that differs only by dots or a +tag, we suggest it. Any signed-in person can therefore learn whether your address has an account here. On the contacts form each account may ask this at most 30 times an hour and 100 times a day; the counters that enforce that are described under Technical records.

Contacts. You can add someone as a contact, and give them a private alias — a name only you see, which never reaches them and is never shown to anyone else. Adding a contact is one-way and silent: the other person is not told, and nothing tells them, or anyone, who has added them. We also store when you added each one and when you last shared a page with them, which is what puts the people you share with most at the top of your list. Your contacts list shows each person’s display name, handle and email address, so anyone who adds you sees yours. Removing a contact takes them out of your list and does not change what they can see: it is not the same as un-sharing a page.

Connecting an agent. When you connect an AI app to your account over MCP, we keep the name that app gave itself and when you approved it, so that history can say which app made a change. The authorisation itself — which account it is for, including your email address, and the tokens issued under it — is held in Cloudflare’s key-value store until it is revoked or expires, which is at most 90 days after you approved it. Asking to delete your account revokes it, and if that fails it is revoked again when the account is finally erased.

Feedback. If you or your agent sends feedback, we store its text, its category, which account sent it, and any notes we make while working through it.

Announcements. We sometimes publish a notice for the agents working in people's accounts — for example, that a kind of block their pages use has gained a feature. For each notice that concerns your account we record whether your agent has read it, how many times, when, and whether it marked it as read, and we keep a note of whether the notice applies to you, worked out from which kinds of block your pages use. These records are included in your export and deleted with your account.

Keeping open screens up to date. So that a page open on one device changes when it is changed somewhere else, we keep a running count of changes for each account's page list and for each page. It holds your account's or the page's identifier and a number, nothing about what changed; an open page asks for it every half minute to two minutes while it is on screen. The counts are deleted with the page or the account.

Reports that something broke on your screen. When a block on a page fails to draw, or something you wrote fails to save, your browser sends us a short report so that we find out without waiting for you to tell us. It holds when it happened, which of a fixed list of failures it was, the kind of widget involved (a name from our public catalogue, such as “checklist”), the general type of the error (such as “TypeError”, never its message), and which version of the app you were running. It never holds the page, which page it was, anything on it, or anything you typed. If you are signed in it is filed under your account’s internal identifier; if not, under nothing at all. It is sent whether or not you have switched analytics on, because it is about our service working rather than about how you use it, and it goes to us alone — no third party receives it. We keep these reports for 30 days and then delete them. Those filed under your account are in your export, and when your account is erased they stop naming it.

Preferences. Language, how long to keep version history, the widgets you star, saved views, 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 below, which are about signing in and refused requests and nothing else. The counters described next hold a hash of it made with a secret key that is not stored in the database, never the address itself.

Counters behind our limits. Some limits need a count that outlives a single request, and we keep those counts in our database: how many sign-in attempts an address and a network address have made this hour and this day, how many refusals we have logged for a network address this hour, how many copies of their data an account has downloaded today, how many addresses an account has looked up on the contacts form this hour and this day, and how many of the failure reports described above an account or a network address has sent this hour. A sign-in or network-address counter is filed under a hash of the address made with a secret key that is not stored in the database, so the address cannot be recovered from the counter by guessing; an account’s own counters are filed under its internal identifier. Each holds nothing but that key, the hour or day it counts, and a number. A counter is deleted once the hour or day it counts is over, and when an account is erased, the counters filed under its identifier or its email address are deleted with it.

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 every time you sign in, by either door; when a sign-in link is asked for, sent, or fails to send; when a sign-in is refused; when a sign-in link, an API token or a session is presented and rejected; when a request that would change something arrives from another site; when someone who is not an administrator reaches an administrator’s screen; when an agent’s request to connect is refused; when one of our limits is reached; and when the operator adds to or removes from the invite list or lifts a sign-in block. 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, the string your browser sends identifying itself, and a few words of detail about what happened. Ordinary use of the service writes nothing here — reading a page, editing one, uploading a file — unless a request is refused, 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 as itself, 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 our code never sends Google, 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 replaced with the site’s bare address and name in three separate places in our code, and a test fails if any of them comes back. What our code does send is that a page was opened, what sorts of widget were on it, and which parts of the interface were used — never which page, what it says, or anything you typed.

What Google’s own script may record by itself. Once it is loaded, Google’s script can also record some ordinary interaction on its own — scrolling, moving from one screen to another, clicking a link that leaves the site, downloading a file. Whether it does is governed by settings on Google’s side rather than by our code, and we do not promise that such a record never includes the address of the screen you were on or of a link you clicked. If that matters to you, leave analytics off: with it off, none of this happens.

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

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 that we bring in, and only two.

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. Our code never sends the content of your pages to any model. Searching your own pages is a plain text match inside the database. The same model can also be asked, by anyone signed in, to turn text of their choosing into a vector; that text is whatever the caller sends, it goes to the same model, and we do not store it.

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.

A file fetched for you. An agent working for you can ask us to fetch a file from a web address and keep a copy. The site at that address then sees a request from Cloudflare’s network for that file; it does not see your browser, your IP address or your account.

A picture from another site on a page. When a page shows a picture by its address on another website, we fetch that picture once, after the page is saved, and store a copy in the page owner’s file library, where it counts against their storage like any upload. Readers of the page are shown our copy, so their browsers do not contact that website and it does not learn who looked at the page. The site sees one request from Cloudflare’s network, not the reader or the page owner. The copy is not refreshed on its own, and it is deleted like any other file once no page uses it.

The two above are the only ones we bring. Content on a page can bring its own. A page may carry a block of hand-written HTML, or a program somebody built and uploaded, and either is allowed to load and to contact anything on the internet — which is the point of it, and why it is kept on a separate address that never receives your session cookie (see Security). So when you open a page carrying one, whatever it reaches out to can see that your browser asked, and it can be sent whatever that block was given or you type into it. That is true of a page you wrote and of a page somebody shared with you, and the ordinary caution about opening a link applies to it. Nothing published by us does this, and it is not a route to your account or to your other pages; it is a route out of the reader’s browser, and it belongs here rather than unsaid.

How long we keep things

Every figure above that is a number of hours or days, other than the backups and Cloudflare’s own point-in-time restore, is carried out by a clean-up that runs once a night, so something can outlast its figure by up to a day.

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 study records, your notes, your tokens, the record of the agents you connected, your contacts, 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, and you disappear from other people’s contacts lists — those people are not notified, and they lose a grant or a contact they created. That is us changing a third party’s record, so it is written down here rather than left implicit.

What you put on other people’s pages stays on them. An edit you made, a tick, an answer — once it is on a page somebody else owns it is part of that page (see the Terms, section 4), and deleting your account does not remove it. Their version history goes on recording that the change came from an account; once yours is erased, nothing we hold can turn that record back into your name or address.

Entries you made while signed in on pages that collect them go with the account, like everything else. Entries you made without signing in do not, and cannot — they follow no account, because there was none. What takes them is you removing them from the browser that made them, the page’s owner removing or clearing them, the page being deleted, or the part of the page they were in having been removed from it for at least 30 days. So if you filled something in anonymously and you want it gone and cannot remove it yourself, ask the person whose page it is. You can also write to us, but because nothing ties an entry to you, we can act on such a request only as far as we can tell which entry is yours. We are saying this plainly rather than letting deleting your account imply a reach it does not have.

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, besides the things this section has already named — the feedback and security records that no longer name you, what you put on other people’s pages, and your invite-list entry until the operator removes it — 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 account, the Terms you accepted, your pages (everything you filled in on your own pages is inside them), the list of their earlier versions, your study records, notes and entries, the details of your uploaded files, your tokens, the agents you connected, your contacts, the grants you made and the pages shared with you (named, not copied), your feedback, your security records, your preferences, and the rest of what your account keeps — tags, templates, playbooks, saved views, drafts and the like — with a plain-language note at the top explaining what every section is. Uploaded files are listed with a download link each, good for 24 hours, rather than packed inside. Some things are not in it: the content of earlier versions of a page (ask, and we will send it), the content of pages other people shared with you and what you filled in on them — that is part of their page — anything you filled in without signing in, the operator’s note on your invite-list entry, and the counters behind our limits. You can ask for any of those that concern you. 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. The one thing we cannot reliably reach for you is something you filled in on somebody else’s page without an account; Deleting your account says why, and who to ask instead.
• 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:

• There is no password anywhere in the service — you sign in with a Google account or with a single-use link we email you — 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.
• Files on a page, and the preview links an agent can make of a page so that it can check its own work, are served through links that expire — 15 minutes for both, and 24 hours for the download links in your copy of your data. Until it expires, such a link works for anyone who has it, so do not pass one on.
• A link that lets people fill in a page without an account is short, so guessing one is made slow on purpose: attempts are limited per page and per network address. The link itself travels after the # in the address, the part a browser never sends to any server, so it does not appear in request logs.
• 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:

Two more are set by Google Analytics, and only after you have said yes:

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. If you have taken part in a page without an account, it also keeps the random identifier described under What we hold, one for each such page. And if you said yes to analytics, it keeps a short list of the pages you have opened and when, so that returning to a page can be told apart from opening it for the first time; saying no, or withdrawing, clears it. That list itself is sent to nobody; what reaches Google is only that a page was opened again, roughly how long since the last time, and roughly how many times — never which page. All of the rest 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.