I've had an unspoken discomfort about procurement for years: every record of pricing, reconciliation, and sign-off between us and a supplier basically sits inside whatever system the supplier uses, or on some third-party SaaS server neither of us controls. Sure, you can call it industry standard practice — but standard practice doesn't make it comfortable, especially the time a supplier's sales rep turned over and the new one pulled up a six-month-old chat log to justify a price to me. I couldn't help wondering who else had ever had eyes on those numbers.
This time we tried a real order a different way: a spring restock of 2,000 USB-C chargers. The supplier kept her own records on her own KarmaLith; our side kept ours on my own KarmaBox. Quoting, doing the math, and confirming the order all happened in the same group chat, but each side kept its own copy — not a single word passed through any shared server, and neither system ended up holding the other party's full correspondence. Before writing this, I specifically double-checked something: even with the network between our box and the cloud cut off entirely, the whole process still goes through start to finish. Here's how this particular order actually went, from quote to sign-off.
The quote came in, and the boss just asked the avatar right there in the group
The supplier posted the quote first: 2,000 USB-C chargers at $3.2 each, packaging included, a 15-day lead time. Our purchasing specialist replied "got it, let me check with the boss," then, in that same group, @-mentioned my own avatar — we call it Assistant — and asked: "at $3.2 × 2,000 units, plus 8% shipping, what's the total? Show the math." I wasn't even near my computer at the time.
Twenty-five seconds later, a reply landed in the group: total $6,912, with the math spelled out plainly — 3.2 × 2,000 = $6,400 (goods), 6,400 × 8% = $512 (shipping), 6,400 + 512 = $6,912 (total, same as 6,400 × 1.08). When I looked back at that message, my first thought wasn't whether the math checked out — it was where that math had actually been run. It turned out the avatar had done this entirely with local compute on my own KarmaBox — it hadn't sent this order's figures or the supplier's quote anywhere else to "check." It just applied the pricing rule I'd already given it, on my own device. I replied straight away, "good, go with this price, order by Friday," and the supplier confirmed, "okay, samples ship tomorrow, I'll post the tracking number."
I later pulled up that exchange and compared it against the copy each side had kept — word for word identical. That sounds simple, but in a supply-chain context it's actually a fairly rare arrangement: both sides share one negotiating group, yet each keeps an independent, complete, third-party-free original record. In other words, proof of the quote and the confirmation no longer rests on whose system says so — both parties simply hold the same truth, each on their own. This is exactly the problem we built KarmaBox to solve: let an AI avatar do the work and run the numbers for you, but keep the place it works and the data it touches on your own device, not someone else's server.
"There's no address book" — I didn't take that seriously at first
The team mentioned something to me early on that I didn't think much of at the time: no central server, no address book, yet both sides still know exactly who they're talking to. I figured that was just adding a contact, same as any chat app. It wasn't until I actually opened the contacts page myself that I realized "knowing who someone is" meant something different here — each person's address itself carries the key that proves their identity, with no central database to check against, and that key would keep working even if the company running this service shut down tomorrow.
Adding someone relies on an invite code: the other person sends you theirs, you paste it in, and you're mutual contacts — a stranger can't even get a message through. In our case, our purchasing specialist sent the invite code to the supplier, who pasted it in and was added instantly, with the first greeting landing right away. I later had the team deliberately try a handful of harassment tactics — a stranger messaging directly, guessing a passphrase, forging a contact's business card, tampering with a letter's contents, re-sending the same message several times, a stranger forcing their way into a group, even stuffing fake letters into a relay inbox — and none of it got through. Even a message delivered more than once only ever shows up a single time in the chat, never flooding the screen.
This sounds technical, but what it actually solves is a pretty basic procurement anxiety: I don't want to re-verify a supplier's identity just because we switched chat tools, and I especially don't want the other side to suddenly "not exist" because some platform's database had an issue. An address carrying its own key is, in plain terms, taking the question of "are you really you" out of a platform's hands and putting it back into the hands of the two people actually talking.
The supplier powered her device off for a whole night, and not one message was lost
What actually surprised me most came later. Anyone in trade or supply chain knows the other party can't be online 24 hours a day — the supplier needs to sleep, and her device isn't immune to restarts or dropped connections either. With the tools we used before, you either needed some "master server" standing watch around the clock, or you just accepted that messages might get delayed or even dropped while the other side was offline. This time we deliberately left the supplier's device powered off overnight, just to see what would happen.
What happened was this: while she was offline, letters addressed to her were temporarily held by a device belonging to one of her authorized contacts — those letters stay locked, so the device holding them can't open them; it's purely a courier, nothing more. Once her device powered back on, within about half a minute, every held message was retrieved by her own device, no more, no less. We also deliberately sent the same message twice during that window, just to see if it would show up twice on her end — it didn't. The system recognized it as the same message by its global ID and kept only one copy.
I later figured out why this mattered to me: supply-chain collaboration used to assume either "the other side has to stay online" or "someone has to keep a server running," which really just pushes the cost of reliability onto one party. Now it's become "people around you casually relay for each other," with no one required to keep a machine on around the clock. That design fits the actual rhythm of doing business far better — nobody stays up just to receive a message.
I deleted the key myself, just to see if it could really come back
This part is the one I personally stress-tested the hardest. Devices break — that's common sense. If you really did switch to a new one, would your identity get lost along with it? The team told me there were two approaches: write down an 11-group recovery code and keep it offline, or split the key into several pieces and hand them to trusted friends to hold, where recovering it requires gathering an agreed-upon number of those pieces — any single piece alone reveals nothing, and a friend has to personally approve the release of their piece inside their own app. I couldn't just unilaterally take it back myself.
I tried the recovery-code path first: deliberately deleted the key, then reinstalled it using the recovery code I'd written down — the address came back exactly as it was, with chat history and contacts all intact. I then deliberately mistyped one character, and the system immediately flagged it as wrong rather than letting it slide through. Next I tried the friend-share path: I picked three colleagues, gave each one a share, and set it so any two agreeing could recover the identity. In testing, when two of them approved, the identity came back without issue; with only one approving, it couldn't be reconstructed no matter what; and neither someone without a share nor a forged share worked at all. What mattered even more to me was the recovery window itself — if someone sent me a message during that time, it would queue in a relay inbox and get automatically retrieved once my identity was restored, instead of simply vanishing because I was technically "identity-less" for a stretch.
In procurement, what you're really afraid of isn't a broken device — it's "the person's gone, the password's gone, and the deal's entire history disappeared along with it." This recovery mechanism made me realize that sovereignty doesn't mean "you alone have to shoulder every risk." The key can be split among people you trust, yet no single one of them can walk off with your identity. That balance is exactly what I wanted.
The supplier tried to boss my avatar around, and got politely turned down
We'd already seen that a cross-home group chat lets you ask the other side's avatar to help with math or draw up a list. What I actually wanted to know was where the boundary sat — could someone on the supplier's side casually direct my avatar to do something else entirely? The team had the supplier say directly to my avatar, Assistant, in that same group: "create a new file for me." The result was unambiguous: the box refused the request outright and executed nothing, while the avatar remained just as responsive to me the moment I was the one asking.
Another detail I hadn't expected to care about was the duplicate-name scenario — across two of my own devices, each happened to have an avatar with the same name. Would both respond at once in a cross-home group and step on each other? In testing, they didn't. Whichever device's avatar is registered in that particular group's member list is the only one that responds; the other, even sharing the identical name, stays completely out of it.
When I later talked this design over with the team, I said something plainly honest: an avatar being able to do work is a plus, but an avatar knowing "this isn't mine to act on" is the actual reason I'm willing to put it into a cross-company collaboration setting at all. It doesn't achieve that through good judgment — it's constrained from the start to only answer to its owner. That's the same underlying logic a customer-service avatar needs when deciding which boundaries to hold with a customer it's never met.
A few of our colleagues haven't moved to a box yet, and we could still pull them into the same group
Honestly, not everyone switches tools right away. A few people on our team are still on Karma's cloud for now, not yet on a box. While working this deal, I tested that side too: once the interop switch between cloud and box is turned on, a colleague on the cloud and the rest of us on boxes can add each other with invite codes and still end up in the same group chat. When a box is powered off, the cloud side can relay a copy on its behalf too, retrievable once the box comes back — and interop doesn't cause a duplicate copy to show up either.
This switch is off by default — leave it off, and the cloud handles that kind of address exactly as it always has, with the channels people already use unaffected. That mattered to me: moving to a more sovereign way of collaborating doesn't mean forcing every partner to switch tools on the same day. People can move at their own pace, starting with whichever part of the business is most sensitive.
What I actually came away caring about, after this deal closed
This particular order for USB-C chargers closed at $6,912, ordered by Friday, samples shipped the next day — and the process itself wasn't any slower than any collaboration tool we'd used before. Every step that needed to happen — quoting, running the numbers, signing off — happened in full. What's actually different is what's left behind once the deal closes: the supplier holds her complete record, we hold ours, the two match word for word, but they're physically locked away on separate devices, with no third-party platform able to see both sides' full correspondence at once.
I later mentioned this to a colleague in finance, and she asked a very practical question: "what's actually better about this compared to what we use now?" Thinking it over, the answer is fairly plain — what's better is that the question of whose record this actually is no longer depends on trusting some platform's word for it; it's physically, cleanly separated from the start. It's the same point we made in an earlier piece about sovereign AI procurement standards — whose model, whose data, whose machine — except this time we actually walked that sentence through on two real machines with one real order.
Quoting, running the numbers, and signing off all happened in the same group chat — but whoever's record it is, it stays theirs. That's the one line I most wanted to hold onto after this deal closed.