This page is a draft. No lawyer has read it and the owner has not approved it for publication, so nothing written here is in force and the wording may still change.
Terms of Service — APC (Agent Profile Context)
- Effective date
- {{EFFECTIVE_DATE}}
- Service
- APC, at
https://apc.abt.nz - Sign-in
- handled by our own identity service at
https://idp.abt.nz - Operator
- Andrei Shvechkov, an individual in New Zealand. APC is a project called ABT; ABT is not a company, and the operator is the named person
- Contact
- apc@abt.nz. A postal address is given on request to that address
- Governing law
- New Zealand
- Privacy policy
https://apc.abt.nz/privacy
The short version
APC is a free, non-commercial side project. It runs on one machine, is maintained by one person, has no backups, and comes with no promises at all — not about uptime, not about your data surviving, not about the service still existing next month. An agent you have allowed to write puts statements into your profile automatically and nobody reviews them first; that content is yours and you answer for it. Everything in the profile is readable by every agent you connect. You can see every write in a journal and undo it for 30 days — but both of those need a permission that is not handed out by default, and getting it means writing to us. If losing your profile would hurt, keep your own copy elsewhere.
If that is not acceptable to you, please do not use the service. Using it means you accept everything below.
1. What the service does
APC stores a small set of facts about you — who you are, how you work, what you are currently doing — so that the AI agents you use can read them instead of asking you the same questions in every new conversation.
Concretely, the service:
- keeps your facts in a database as plain text, in a fixed set of sections;
- lets any agent connected to your profile read all of it;
- lets an agent you have allowed to write store new facts immediately — there is no queue, no approval step and nothing to wait for;
- keeps two journals: which agent read what and when, and which agent wrote what, when, on what stated grounds and what it replaced. Both are readable only through an agent holding the approval permission (section 4);
- lets that agent undo a write for 30 days afterwards;
- enforces size and rate limits (see section 8).
That is the whole product. It is a storage service with filters, deliberately dumb.
2. What the service does not do
- It does not read, judge, summarise, rewrite or "improve" your facts. There is no language model inside the server. This is a hard architectural rule of the project, not a current limitation: the server never sends your text to a model and never edits it.
- It does not check whether anything in your profile is true, lawful, or yours to store. The only checks applied to a fact are checks of form — length, invisible characters, look-alike letters, embedded links, markup, and imperative phrasing ("do X"). Text that passes those checks is stored exactly as written.
- It does not notify you about anything, ever. The service has no email, no messenger, no webhooks, no push. That is deliberate and it is not going to change. The only place anything is ever shown to you is inside your own agent, when it connects: the profile's manifest carries a count of writes you have not yet reviewed, and an agent that reads it is expected to mention that to you. That count is the whole of the notification. This matters — see section 7.
- It is not shared. One profile has exactly one owner. There are no roles, no team access, no sharing with other people.
- It is not a backup service, a document store, or a CRM. It holds a few hundred short lines of text about one person, and nothing else.
3. Who may use it, and how a profile is created
You may use APC if you can sign in with a Google account and you are old enough to enter into an agreement where you live. The service is not intended for children.
Signing in goes through Google and then through the project's own identity service at https://idp.abt.nz. Your Google account is used to prove that you are the same person who comes back tomorrow — nothing else. What is stored about you at each step is described in the privacy policy.
How a profile gets created: an agent creates an empty draft profile on its own and shows you a claim link. You open that link in a browser, press the button on the page, and sign in with Google through the identity service. The profile is bound to the account you signed in as — no command, no operator, nothing typed by hand. From then on the same sign-in gets you to https://apc.abt.nz/connect/<your profile id>, where you see which agents are connected and allow one of them to write.
An unclaimed draft is deleted 7 days after it is created, without notice. One account may hold up to 3 profiles.
4. Your agents write to your profile. You are responsible for that
This is the part worth reading twice.
APC is built to be used by agents, without you in the loop. Connecting an agent is enough for it to read your whole profile: any client you have authorised for your profile's address at the identity service is admitted on its first request, and nothing further is asked of you. Writing is not part of that — a newly connected agent cannot write until you say so, signed in, at https://apc.abt.nz/connect/<your profile id>, naming the agent by the identifier it shows you. Once you have said so, that agent writes facts at any time without asking you again, and each one lands in your profile with no human involved. That is a supported way to use the service, not a loophole.
A third permission, profile:approve, is your own oversight delegated: it is what lets an agent read either journal, undo a write, and mint pairing codes for further agents. It is never granted by default, never comes along with a "grant everything" flag, and is never handed out by connecting or by the page above. Today the only way to issue the first one is a pairing code minted at the console of the server — which means asking apc@abt.nz. Until you do that, no agent of yours can open either journal or undo anything.
It follows that:
- Whatever your agents put in your profile counts as put there by you. The service cannot tell whether a human stood behind an approval, and it does not try.
- Nobody reviews the content. No person and no model reads your facts to check them. See section 2.
- Agents make things up. A large language model can invent a fact, or be manipulated into writing one by text it read somewhere else. If you let an agent write, you have accepted that risk. What the service gives you against it is a record after the fact, not a checkpoint before it: the write journal lists every write — which agent, when, the reason it gave, and what it replaced — and any write can be undone for 30 days, which retires the fact it added and restores what it replaced. Both need
profile:approve, which you do not have by default; until you ask for it, the only thing you see is the count of unreviewed writes in the profile's manifest. - An undo is bounded, and it is not a delete. An agent may only undo writes that agents made — your own facts, and anything in the
constraintssection, are refused, and only the operator can undo those. After 30 days the undo is gone. Nothing anywhere deletes a single fact outright. profile:approveis the permission to be careful with. An agent holding it can undo writes other agents made, without asking you, and can mint pairing codes for further agents. That is deliberate — it is how you deal with an agent you no longer recognise — but give it only to an agent you drive yourself.- Every agent sees everything. There are no per-agent visibility levels and no way to hide part of a profile from one agent and not another.
- Choosing which agents to connect is on you. Connecting an agent hands its provider a token that identifies you — including your email address (see the privacy policy). Only connect agents you are willing to trust with your profile and with that token.
- You must have the right to store what you store. If a fact is about a third party, it must be yours to write down (see section 5).
5. What you must not put in a profile
Do not store:
- Other people's personal data without a lawful basis for doing so. Profile sections describe you and roles, not other individuals. Do not use APC as an address book.
- Anything unlawful where you are or where the server is: content that infringes someone's rights, discloses someone's secrets, or breaks the law in any other way.
- Anything harmful: instructions or text meant to attack, deceive, or hijack the systems of other people — including text designed to manipulate someone else's agent.
- Secrets: passwords, API keys, tokens, private keys, payment card numbers, medical or other special-category data about anybody. This is a hobby service on one box; treat everything you put in it as recoverable by anyone who gets root on that machine.
- Bulk or automated junk: profiles created to test the limits, load-generation, or any use aimed at the service itself rather than at storing facts about a person.
Because nothing is reviewed automatically, these rules are enforced after the fact: if the operator learns that a profile breaks them, it can be suspended or deleted (section 9).
6. No warranties. Your data can be lost
Said plainly, because it is true:
- The service is provided "as is" and "as available", with no warranty of any kind, to the fullest extent New Zealand law allows.
- There is no uptime commitment and no SLA. It runs as a single process on a single machine, maintained in spare time by one person. Restarts, upgrades, and outages happen without announcement, and there is no way to announce them (section 2).
- There are no backups. A backup script exists in the project's source tree, but it is not installed on the machine that runs the service and has never run there — nothing is scheduled and no archive exists. If the disk or the database file is lost or corrupted, the profiles on it are gone permanently. This is not a hypothetical worry; it is the current state of the deployment, measured rather than assumed.
- There is no promise that the service will keep existing. It may be shut down at any time, with whatever notice is practical — which, given that there is no notification channel, may be none.
- There is no promise that a fact you stored will still be there. Bugs, migrations, and the retention rules in section 7 all remove data.
Keep your own copy of anything you care about. A full export of a profile exists, but today it can only be run by the operator on the server — ask apc@abt.nz. There is no self-service export yet, and we are not going to pretend otherwise.
7. Retention, inactivity, and deletion
The service deletes things on a schedule, silently, because it has no way to warn you:
| What | Rule |
|---|---|
| A profile that has an owner | never deleted for inactivity. It goes when you ask for it to go |
| An unclaimed draft profile | deleted after 7 days |
| An agent grant unused for 180 days | revoked (the record stays, access ends) |
| A write | can be undone for 30 days; after that it stands |
| A fact in the current section | expires on its own date — 90 days after it was recorded, unless a different date was given, which an agent must set between 1 day and 1 year out — and from that moment is no longer served to any agent |
| A fact replaced by a newer one, or retired by an undo | kept 90 days, then deleted — except the most recent one in each section, which is kept indefinitely, and except while an undo could still need it |
| Your read journal and your write journal | each kept 90 days |
| A browser sign-in in progress | 15 minutes |
| Daily usage counters | kept for the life of the profile |
A profile with an owner is not deleted for going quiet, and that is deliberate. An earlier version of this service did delete it after 90 silent days. It no longer does: the service has no channel through which a warning could reach you — adding one is against the project's design rules — and erasing somebody's data without being able to tell them first is not a trade we are willing to make. Unclaimed drafts are the exception, because there is nobody to tell. None of that is a promise that your data will survive: see section 6, and keep an export.
What "deleted" means today. Deleting a profile removes the profile and everything attached to it — facts, tags, links, the write journal, grants, the read journal, counters. It does not remove the link between your Google identity and this service, your account at https://idp.abt.nz, or the server's web logs, which record IP addresses and profile identifiers. The privacy policy describes exactly what survives and what does not. Deletion of a profile on request is an operator-run command today: write to apc@abt.nz.
8. Limits
The free plan currently allows, per profile: 200 facts, 60 000 characters of fact text, 300 characters per fact, and 60 reads per minute. Each agent may make 50 writes per day, and a single fact may carry 5 tags, 5 links, and replace at most 5 existing facts. Agents together cannot fill the last tenth of the two size ceilings — that headroom is reserved for facts you enter yourself, so that an agent cannot lock you out of your own profile. One account may own 3 profiles, and one IP address may create 5 draft profiles per day.
Reading never fails because of a size limit — you get a truncated answer and a cursor. Writing does fail, with a reason. Your agent can always ask the server for the current numbers (apc_get_limits), which is the authoritative source: these limits may change at any time, without notice, including downwards.
Do not try to work around the limits with multiple accounts, scripted profile creation, or automated retries against the rate limiter.
9. Suspension, termination, and your own exit
- You may stop using the service at any time — simply stop connecting. Note that a profile left alone is not deleted (section 7), so if you want it gone you have to ask: write to apc@abt.nz.
- The operator may suspend or delete any profile, revoke any agent's access, or shut the whole service down, at any time, for any reason, without notice and without a refund (there is nothing to refund — the service is free). Reasons will include, but are not limited to, section 5, abuse of the limits, and legal obligation.
- If the service is shut down for good, the operator will try to give advance notice on this page and to run exports for anyone who asks. That is an intention, not a promise — see section 6.
10. Fees
APC is free and non-commercial. No payment is taken, no card details are collected, and there is no paid plan. Nothing here obliges the operator to keep it free, but if that ever changes, existing profiles will not be silently converted into a paid subscription.
11. Liability
To the fullest extent permitted by New Zealand law, the operator — Andrei Shvechkov, in person, because there is no company here to stand behind the service — is not liable for any loss or damage arising from your use of, or inability to use, the service — including lost, corrupted, or leaked profile data, lost business, decisions made by your agents on the basis of what the profile contained, or anything an agent wrote into your profile.
You are responsible for the content of your profile and for the agents you connect, and you agree to cover the operator for third-party claims that arise from what you stored (section 5) — again, only to the extent New Zealand law allows.
Nothing in these terms limits liability that cannot be limited by law.
12. Changes to these terms
These terms may change. The current version always lives at https://apc.abt.nz/terms with its effective date at the top. You will not be notified of changes — the service still has no channel to notify you through. If you keep using APC after a change, you accept the new version; if you do not accept it, stop using the service and ask for your profile to be deleted.
13. Governing law
These terms are governed by the law of New Zealand, and disputes are subject to the courts of New Zealand, without prejudice to any mandatory consumer protections in your own country of residence.
14. Contact
Andrei Shvechkov — apc@abt.nz. A postal address is given on request to that address.
Also see the privacy policy, which explains what data the service holds about you, where it comes from, and who else can see it.