ZAMBO.

Direct answer

One account, every client, one long scroll. The record has to be per job, not per account.

Every client you serve runs through the same AI account, so the history is one long river: one client's brief, another client's draft, a third client's figures, all in speaking order, none of it labelled by job. Now one client needs their complete record, for an audit, a dispute, or a handover, and the account gives you no way to pull their thread out clean. Scrolling and copying produces a pile of excerpts the client cannot check and you cannot stand behind. Here is how to separate this client's work honestly from what exists, how to label every part at its real strength, and how to change the unit of work from the account to the job, so the next complete record is a single link you hand over in a minute.

See the instrument first: the live demo runs one real call and hands you its verifiable receipt, no signup.

Updated November 5, 2026. First published November 5, 2026. The two delivery records quoted below are real and public, with their client decision states read back from the live service on November 5, 2026.

Step 1. Stop trying to untangle the history by scrolling

A chat history is ordered by conversation, not by client, and it fails this job in three specific ways. Steps from different clients interleave whenever you switched tasks mid day, so a sequence that reads as one job is often two jobs braided together. Context bleeds across the braid: an instruction given for one client sits above another client's work and reads as if it belonged to it. And excerpts prove nothing on their own, because a copied passage carries no date the client can check, no place in a sequence, and no way to tell what was left out. Accept the shape of the problem before you start: from a mixed history you can build an honest reconstruction for this client, clearly labelled, and you can fix the system so it never happens again. What you cannot honestly do is present copied excerpts as if they were a sealed record. That distinction is the whole page.

Step 2. Separate this client's work with a three label sort

Work through the history once, client by client, and put every item that touches this client into one of three piles, labelled exactly this way in what you send. Theirs: items that name this client, their project, their files, or their figures, and belong to no one else. Shared: items that served this client and at least one other, a research pass you reused, a template you built once and applied twice; list these with a note on how they were shared, and include only the part that is actually this client's. Not theirs: everything else, named as excluded, so the client can see the boundary of the record instead of wondering where it is. For each item in the first two piles, keep its date and its place in the order it happened. A record is a sequence, not a scrapbook, and the order is often what a later question turns on. This sort takes an hour the first time. It is also the last time, if step 5 lands.

Step 3. Read the two states a client record can sit in

The sorted reconstruction above is the best a mixed account can offer after the fact. The stronger shape is a record that was separated while the work ran, one job at a time. The record format is AER-1, published as an IETF Internet-Draft (draft-zambo-aer1-26), and each step carries a verifiable receipt: a receipt proves the saved result was not changed since it was saved. The two public records below show the states a single client's record can carry:

Accepted: the decision is on the record

Pending: checked, and still waiting on a decision

Look at what makes these records separable. Each one is a single job: a named set of steps, 4 steps in the accepted record and 5 in the pending one, each step with its own verifiable receipt, wrapped under one link that belongs to that job and no other. Nothing from any other client can drift into it, because the boundary was drawn when the job was wrapped, not reconstructed months later from a shared scroll. The accepted record also carries the client's own decision, decided_by client at 2026-10-16T14:31:51.146Z, release_hint ok_to_release. The pending record, 5 of 5 steps checked and release_hint hold, shows the honest middle state: the work is separated and checkable, and the one missing thing, the decision, is visible as missing instead of buried in a thread.

Step 4. Hand this client their reconstruction, labelled, with the gaps named

Send the sorted record as one document with a short covering note that does three things. It states what the record is: a reconstruction from a shared account history, assembled on this date, covering this client's work in date order. It states the labels plainly: theirs, shared with a note, and excluded, so the client reads the boundary the same way you built it. And it names the gaps before the client finds them: any period where work happened in a call, on paper, or in a tool with no saved trace is listed as missing, not smoothed over. Then invite the client to confirm the record as the agreed account of the job, in writing or by accepting it as a delivery, so the reconstruction itself becomes settled from that day forward. A client handed a labelled record with named gaps trusts it more than a client handed a perfect looking excerpt pile, because the labels are exactly what a person with nothing to hide would include.

Step 5. Change the unit from the account to the job

The durable fix is not a second account, although separate accounts per client help some practices. Accounts still mix jobs for the same client together, and clients come and go faster than account structures do. The fix is to run each job as its own record from the first step: the work for this client runs as steps in one job, each step saved with its own verifiable receipt as it completes, and at the end the job is wrapped into a handover that is that client's complete record, steps, sources, decision state, and all. The account becomes what it should have been all along, a tool you happen to work in, while the job record is the thing you keep, search, and hand over. Starting a new job then costs one habit, not a new login: name the job for the client at the start, run its steps on its own record, wrap it when it closes. Two clients on the same afternoon produce two records that never touch.

Step 6. Keep a client index so any record is findable in a minute

Separation only pays if you can find the record later, so keep one simple index outside the AI account: client name, job name, dates, and the record link, one line per job. File the link with the invoice and the final delivery message, the two places you will actually look when a question arrives. When a client leaves, changes team, or asks for everything you hold on their work, the index gives you their complete list in one pass, and each link opens a record the client can check without your account, your login, or your narration. That is the answer to the original problem in its finished form: not a cleaner history, but a practice where no client's record was ever inside the history in the first place.

What a record does not settle

A verifiable receipt proves the saved result was not changed since it was saved; it does not sort a mixed history for you, recreate steps that were never saved, or decide what you may share with one client about work that also touched another. The three label sort, the named gaps, the client's confirmation, and a per job record from the next job on are what this answer stands on. This page is general information, not legal advice.

Frequently asked questions

I use one AI account for all my clients and everything is mixed together in one history. How do I pull out one client's complete record?

Sort the history once, by client, into three labelled piles: theirs, items that name this client, their project, files, or figures and belong to no one else; shared, items that served this client and another, included with a note on how they were shared; and not theirs, named as excluded so the boundary of the record is visible. Keep each included item in date order with its place in the sequence, name any gaps where work left no saved trace, and send the result as one document the client can confirm as the agreed account of the job. Be plain that this is a reconstruction from a shared history, not a record sealed while the work ran. Then fix the cause: from the next job on, run each client's work as its own wrapped job record, so a complete record is one link instead of an afternoon of sorting.

Can I just copy this client's chats into a document and send that?

You can, and for an informal update it may be enough, but understand what the client receives: excerpts with no checkable dates, no visible sequence, and no way to tell what was left out or whether a passage belonged to their job or the one above it in the scroll. In any setting where the record matters, an audit, a dispute, a handover to a new supplier, excerpts are the weakest form of the answer and the first form a sceptical reader discounts. If you do send copied material, strengthen it with the labels from this page: which items are wholly theirs, which were shared, what is missing, and the dates in order. The labels cost you nothing extra and turn a scrapbook into something a third reader can follow and test.

Should I open a separate AI account for every client instead?

It helps at the edges and does not solve the problem. Separate accounts stop one client's chats sitting next to another's, which is worth having if your tools make it cheap. But an account per client still mixes that client's jobs together in one history, still orders everything by conversation instead of by job, and still gives the client nothing they can check without your narration. The unit that solves the problem is the job, not the account: one wrapped record per job, with per step receipts and the client's decision on it, findable from an index you keep. Run jobs that way and the account question becomes a matter of taste. Keep scrolling one shared history and no number of accounts will give a client their record.

What do I do about work that served two clients at once?

Name it, share it honestly, and never bill or present it twice as if it were two separate pieces of work. Research, templates, and setup often genuinely serve more than one client, and clients understand that when it is stated up front. In each client's record, include the shared item with a short note: what it is, that it was shared, and which part of it is theirs, the applied result, the figures for their case, the draft in their name. What stays out of both records is the other client's material itself; a shared method travels, a client's data does not. If a shared item later becomes a problem, its presence in both records, labelled the same way in each, is what shows the sharing was open rather than discovered.

How do I keep one client's record separate from the start?

Run the job on its own record instead of inside the shared history. When the work runs through Zambo, each job is its own set of steps with a verifiable receipt on every step under AER-1, published as IETF Internet-Draft draft-zambo-aer1-26, and wrapping the job seals that client's record under one link the client can check and accept, with nothing from any other client inside it. New users get 20 calls and 1 wrap-up free every day, and picking up work in another AI is always free. For $0.99, run the next mixed up job that way and hand that client a record that was never tangled in the first place: get the Day Pass. A Day Pass is unlimited for 24 hours, no subscription. Ongoing use is the Zambo Pass at $29 a month or $290 a year, and $19 a month for $ZAMBO holders, which adds private handover links, your branding, and the approval record as PDF and JSON files.

Related