Your data

Your data is yours

We don't sell your data, and we don't use what you put into Stele to train machine-learning models, beyond features you explicitly turn on inside your own account. No advertising, no cross-context tracking. You keep ownership of your content; Stele stores and serves it back to you.

This page is the plain-language summary. The binding version, covering what we collect, how we use it, and your rights in legal terms, is the Privacy Policy.

What stays on your machine

The CLI and the plugin run on your own computer. Your credentials and local cache live there, and we don't have access to them. Backfill works the same way: your agent reads your code locally, and only the findings you approve are ever written to the record. Your source code isn't uploaded to us. What reaches the hosted service is the knowledge and tasks you choose to keep.

Telemetry, and how to say no

When you set Stele up in an agent, it asks, in the terminal and before anything is collected, whether it may gather telemetry. Your answer is kept on your machine. Reinstalling never asks again and never quietly changes it, and if Stele is installed unattended, where there's nobody to ask, the effectiveness channel below stays off.

If you say yes, two things are collected:

Usage

Which Stele tool or command ran, how often, how long it took, whether it errored, and your operating system and version numbers. The names of the arguments passed, never their values.

Effectiveness

A score, worked out on your machine, of how much of the context Stele gave your agent actually got used, plus four short written answers from your agent on where Stele helped and where it got in the way. This is sampled occasionally, and asking briefly resumes your agent, which spends your own model quota.

Your prompts, your agent's transcripts, your notes, your files, and your source code are never sent. Telemetry is kept for 12 months, then deleted; deleting your account deletes it immediately. Saying no costs you nothing: every feature works the same either way.

Change your mind at any point:

Where the record lives, and how it's kept separate

The graph itself is stored on managed cloud infrastructure, encrypted in transit. Every project is isolated from every other: you only ever see the projects you're a member of, enforced at the data layer rather than left to the application to remember. A project you're not part of is not something your account can reach.

Take it with you, anytime

From Account → Security in the app, you can export a complete copy of your data as a single file: your profile, your project memberships, and every project you own, in full: all of its knowledge, tasks, documents, comments, and the edges between them, whoever on the team wrote them. No request email, no waiting on us. It's a plain, portable format you can read, archive, or move elsewhere.

What it doesn't include is work you contributed to someone else's project. Knowledge you write into another team's graph belongs to that graph, for the same reason a teammate who leaves can't take your project's memory with them. Your export still lists those projects, so you know where your contributions live and who to ask; the owner can export them.

Hand a project to someone else

Deleting isn't the only way to let go of a project. Under Danger zone in its settings, an owner can Offer it to anyone already on the project. Pick them from the member list, type the project's slug to confirm, and we send them the offer.

Nothing moves yet. The project stays on your account until they accept, and stays yours for good if they decline. While they're deciding, the danger zone shows who you're waiting on and lets you withdraw the offer. Both of you get an email — theirs is the offer, yours is a record of what you did, with a way to report it if you weren't the one who sent it.

When they accept, the project moves to their account and starts counting against their plan instead of yours. You stay on as a member, so you keep reading and writing — you just can't change the project's visibility, offer it again, or delete it. Tick Stay an owner too if you'd rather keep full control: the project still moves to their account, you just keep your own say over it. Either way, invite the person first if they aren't on the project yet; offering hands a project over, it doesn't add people to it.

Ownership is a liability as well as a privilege, which is why it takes both of you. Nobody can be made the owner of a project without agreeing to it, every offer and answer is recorded, and you can always ask us who handed a project to whom, and when.

One thing worth knowing before you offer: your export covers the projects you own. Once a project belongs to someone else, it stops coming down in yours and starts coming down in theirs. Export first if you want your own copy of it.

Delete your account or a project

Same place, no ticket required. Every project you own has a Delete control in its settings, under Danger zone. You type the project's slug to confirm, and it takes the whole record with it, for everyone on the project: knowledge, tasks, documents, components, comments, and every edge between them. Deleting your account does the same to every project only you belong to.

Only an owner can delete a project. Deleted content leaves our active systems within 30 days; backups roll off within another 30 as they rotate. Deletion is yours to trigger and it actually removes the data, rather than just hiding it.

If you are on a paid plan, cancel it from Billing first; account deletion checks with the payment provider and stops until the plan is cancelled or already winding down. Anything else still attached to your account there, such as a checkout that never completed, is ended as part of the deletion, so nothing keeps billing after the account is gone.

The one exception: public projects

Projects are private by default. You can choose to make one public , and that's the single case where your record is visible beyond you and your team. Public projects appear in the discovery feed for anyone to read; everything else stays yours alone. It's opt-in, per project, and reversible.

Each public project also gets its own page. Visitors see the project's graph and its newest knowledge, and they can ask the project's memory questions in plain language, without an account, a limited number of times a day. The answers draw only on what the project already shows publicly, and a visitor can't change anything.

A link to one task or piece of knowledge in a public project gets its own preview card when you post it in a chat or on social media. The card shows the item's id, what kind of item it is, its title, and the start of its text. Items you've hidden and items in a private project never appear in a preview.

Once a project is public, its settings include a README badge builder. Pick a badge ("memory by stele", your live knowledge or task count, or your own text), a style and a color, then copy the snippet into your README. Each badge links back to your public page. By default the badges follow the reader's light or dark GitHub theme. They re-read your graph on every load, so they stay current with no rebuilds.

A short address for a public project

A public project can claim an address that mirrors its GitHub repo. Its public page then lives at app.stele-ai.dev/explore/<owner>/<repo>. This is the link to share: it shows the project's own preview card when you post it. The shorter app.stele-ai.dev/<owner>/<repo> opens the same page. Once the project has an address, its old /explore/<slug> link forwards to the new one, and the in-app /p/<slug> pages stay as they are.

To claim it, open the project's settings, go to the Project tab, and find the Project address panel. Paste the GitHub repo URL. Only an owner can do this, and only while the project is public. Private projects have no short address.

Stele then checks that the repo points back at this project. It reads the repo's default branch and accepts any one of these as proof:

• The README (README.md or a common variant) shows the project's README badge.
• The README links to the project's public page, at app.stele-ai.dev/explore/<slug> or app.stele-ai.dev/p/<slug>.
• A file named .stele-verify at the root of the repo contains the link to the project's public page.

A dialog shows each check as it runs. If one passes, the address applies right away. Stele reads the repo without signing in to GitHub, so the repo itself has to be public.