The Line Isn’t Intelligence
Everyone can tell you what a chatbot does. Almost nobody can tell you what your chatbot would have to become before you could hand it work and walk away.
Disclosure: I work on KarmaBox, which sells AI avatars. This article argues that the line between an avatar and a chatbot is the deliverable, not the intelligence — and the product I work on is built on that argument, so weigh it accordingly. What I’ve done to keep it checkable: every number from our own logs carries a date and a caveat, the one external news source is linked, and I’ve named the three things avatars are genuinely worse at rather than leaving you to find out.
The question that actually separates them
Ask yourself what happens after the answer arrives.
With a chatbot, the answer is the end of its contribution and the beginning of yours. You copy it, cut it, check the pricing figure, format it, send it. The tool did the thinking-adjacent part; you did everything with a recipient attached to it.
With an avatar, the thing that arrives is the artifact. The reply that was actually sent. The deck that’s already in the folder. The quotation that went out with a number that traces back to a file. Plus a record of what it did, which is the part nobody asks about in a demo and everybody wants after the first mistake.
That’s the line. Not “how good are the answers” — both can run the same model, and today plenty of chatbots are smarter than plenty of avatars. The line is where the work stops.
Written as two columns, it stops being an argument:
Conceptual diagram, not a measurement. Both rows can run the same model.
Neither column wins. The question isn’t which product is better — it’s which of your recurring tasks ends in an artifact.
What each word actually means, since sales decks won’t tell you
The vocabulary is a mess, and the mess is useful to vendors because it lets any product claim any category. So here’s the split I use:
- An assistant answers. Its surface is conversation. Its failure mode is a bad paragraph.
- An agent acts. Its surface is tools. Its failure mode is a bad action — a sent email, a published page, a spent budget.
- A copilot acts beside you, with you structurally in the loop.
- An avatar is an agent with a persistent identity, a persistent memory, and a signature. A thing your colleague can address, hand work to, and find again next week.
Only the last one lets you be unreachable. That’s the use case worth comparing, and it’s why the comparison is about architecture rather than model quality.
One request, 126 ms to dispatch, 19 replies back inside 20.1 seconds. The interesting part isn’t the speed: each reply is shaped by that avatar’s role and permissions, so the copywriter and the contract reviewer answer differently to the same sentence. Redrawn in English from the 10 October 2026 run record (vendor material); replies abbreviated.
I care about this distinction because the blur has a predictable cost. Buy an “agent platform” after a demo, get a system that can act but cannot tell you what it did, and the quarter that follows goes into building the audit trail the vendor should have shipped. The demo was real. It just wasn’t evidence.
Four properties a demo cannot show you
If you strip the marketing off this category, four properties recur in everything that holds up. Most products have two and claim four. None of them are visible in a five-minute demo, which is the point.
Identity. A name, a role, a signature, and the name resolves to something — a message history, a task log, a permission set. Without this, work can be suggested to you but not handed off. The practical test: can a colleague tell, at a glance, whether a sentence came from you or from your agent? If not, they can’t tell whether to act on it.
Boundary. A policy per action type, enforced at a layer the model has no vote in. Not “my system prompt says don’t send without approval” — that’s a request. A mechanism that intercepts the action before execution, so the outcome is identical whichever model is answering. This is the least glamorous engineering decision in the stack and the one that decides whether you sleep.
Memory. Context that belongs to the avatar, not to a conversation, a project container, or an account-level setting that changes without telling you. It should survive a model swap and a vendor decision. This is the property that makes a working relationship possible instead of a permanent onboarding.
Receipt. A record written for a human who wasn’t watching: what was asked, what it did, what it declined, what it caught, what it handed back. Chat transcripts record what was said. That’s not the same document, and the difference only becomes obvious after something goes wrong — which is exactly when a transcript stops being useful.
Chatbots have none of these by construction. Agents often have two. Avatars are defined by all four, and the fourth is the hardest, because a receipt is a stance about honesty rather than a feature you can bolt on.
Product architecture, not model capability. Most products have two of the four and claim all four.
The receipt, in one real example
This is the part that changed how I evaluate these tools.
An avatar on our own account was asked to produce a short three-page deck. It produced one. It also reported, unprompted, that its preferred layout service was unreachable that time, that it had fallen back to a standard template, and that the fallback had padded in an agenda page and a summary page which could be deleted. Then it noted that every line of content traced back to what had been specified, with no invented numbers.
Read that again as a list. It’s a negative disclosure — the system telling you where it fell short before you discovered it. You cannot demo this, because it only happens when something breaks, and demos are designed around things not breaking.
Now contrast with the ordinary experience of a model that has drifted off its material. You get a fluent paragraph with no signal that the basis was thin. You find out later, usually from a person on the other side of an email, which is the most expensive possible notification channel.
So the evaluation question isn’t “how good is the output.” It’s: when it fails, does it tell me? Three follow-ups get you the answer in under ten minutes:
- Show me a run where it failed. Not one where it worked — one where it hit a wall. What did it report?
- Show me the record for that run. Is it a transcript of messages, or a record of actions with timestamps?
- Show me what a human had to fix. The correction list is more informative than the success list.
A vendor with a working receipt answers all three from memory. A vendor without one shows you the demo again.
What happened this week, and why it matters
The vocabulary is converging in public, which makes the properties easier to talk about and harder to fake.
OpenAI’s assistant, dots, was explained at TechCrunch Disrupt by Alexander Embiricos, who leads its enterprise product team. His account of why it exists is, almost verbatim, the avatar argument: “if we could frame this as, it’s an entity and it’s a single conversation, not many different conversations… it starts to become intuitive.” It runs $100 a month on the Pro tier and up.
That’s the framing this whole category has been reaching for, from a company with hundreds of millions of users. It also means the words will unify long before the properties do — which is precisely why you want properties you can test.
And here’s the part I found more interesting than the launch. In the same interview, two admissions, and both are boundary problems rather than intelligence problems:
- The proactive timing wasn’t good enough early on. Its own product lead was warned about a calendar conflict three minutes before the conflict.
- It refuses read-only access to cloud drives. The reporter’s characterisation is exact: the controls “aren’t granular and the app can be pushy.”
A system that can only request full read-write when you wanted to lend it read-only has built a permission gesture, not a permission model. And a system that detects a conflict correctly and surfaces it three minutes out has solved the hard part and failed the delivery — which is the whole difference between a demo and a colleague.
There was a third admission that I think is the most honest thing in the piece: the team knew conservative defaults would generate complaints about being asked too often, and shipped them anyway, planning to tune later. That’s the correct instinct. It’s also the tension this whole category lives inside: a boundary that interrupts you is expensive, and a boundary that doesn’t is decoration.
Where the boundary has to sit, and why
Three things erode a constraint that lives in a prompt, and all three happen routinely:
- A model swap. New model, same prompt, different weighting of instruction against context.
- Context pressure. Fifty pages of document competing with a one-line rule for attention.
- Chaining. Agent one’s constraint isn’t visible to agent three.
Nobody edits the prompt in any of those cases. What enforces the prompt changed. That’s why “never touch the pricing sheet” written in a system prompt is a request and not a rule, and why the only test worth running is whether the rule survives a model you didn’t choose.
Get KarmaBox’s stories in your inbox
Join Medium for free to get updates from this writer.
A server-side boundary is evaluated outside the model, so it produces the same outcome whichever model answers, which is the only property that survives an upgrade. The cost is real: it interrupts you. A prompt-based boundary politely never mentions what it declined to do. A server-side one asks you to press a button — and if that button fires dozens of times a day, you will stop reading it, and the log will say you consented.
What a boundary looks like when it’s visible: what’s waiting on you, split into “someone’s waiting for an answer,” “approve before it goes out,” and “it couldn’t finish.” Outbound sends, publishes, deletes and spend stop here. Redrawn in English from the app layout of 10 October 2026 (vendor material).
Memory is what makes it compound
The memory property deserves its own paragraph because it decides whether any of this accumulates.
In a chat product, memory belongs to a conversation, a project, or an account setting. Close the thread and the reasoning goes with it. In an avatar architecture, memory belongs to the avatar — which means it survives a model swap, because it isn’t stored in the model, and survives a vendor decision, because it isn’t stored in the vendor’s project. The cost of getting this wrong shows up as a migration: everything you thought you’d accumulated turns out to be attached to a session you no longer have.
One thing memory is not: a bigger context window. A long context is a long prompt, re-read and re-weighted every turn, gone when the session closes. Teams that conflate the two say “it remembers everything” and discover, on the day they try to move, that nothing was ever theirs.
The test costs ten minutes. Ask something only answerable from history — “why did we drop the second vendor in March” — then ask where the answer came from. It either points to a file (retrieval, working), can’t say (dangerous, because it does this with invented answers too), or admits it doesn’t know (honest, and more useful than the middle one). Most teams live in the middle. The longer version of that argument is worth reading before you buy.
Why the protocol layer raises the stakes
One piece of context that turns this from a definitional argument into an operational one.
The layer beneath agents has standardized. The Model Context Protocol gives models a common way to call external tools and data. The Agent2Agent protocol lets agents from different vendors discover and call one another, with an agent card that’s supposed to declare capability and boundary.
Standardization is good for capability and bad for control, and the second half rarely makes the announcement. When bolting an agent onto a workflow is one line of configuration, the number of agents grows faster than the number of people who know they exist. The one somebody wired in on the side is still running a year later and nobody can produce the list.
That’s where the receipt stops being a nice feature. If each avatar’s record is a real, queryable artifact, “how many agents do I have and what can each touch” has an answer. If the record is a transcript inside a tool you don’t control, the question has no answer — and the answer you’d get by asking around would be wrong.
At the scale of one person or five, the shape is identical and the numbers are small. The failure isn’t 150,000 agents. It’s the fourth one you forgot.
The cost that doesn’t show up on the invoice
The licence is the visible cost. Rework is the real one.
If an avatar hands you a deliverable and you must re-check every line, you haven’t saved the time — you’ve moved it to the end, where mistakes are most expensive and your attention is thinnest. Verification that costs as much as production isn’t automation; it’s a very fast way to generate work.
Illustrative model, not measured. A one-off setup cost only pays back if enough outputs are accepted without a full re-read.
Our own measurement, caveats included: nineteen avatars, five small tasks each, ninety-five tasks dispatched at once, last result back at 44.7 seconds. Done one at a time by one person, that same pile sums to 1,332 seconds — just over 22 minutes. (KarmaBox run log, 10 October 2026. One account, one run, tasks deliberately small — not a benchmark. An earlier 12-task round came out at only 2.89× because one job took 204.8 seconds on its own after its layout service failed, which tells you the wall clock is always the slowest task.)
The human translation is the actual point. 44.7 seconds is reading a paragraph. Twenty-two minutes is a coffee break. So the question isn’t how fast it is. It’s: of those 95 results, how many could go out without me reading them?
The same run log as above (10 October 2026, one account). The 95 tasks were deliberately small; this is not a benchmark of general workloads.
The run, laid out the way the app showed it on a demo account with 19 avatars: 95 tasks, 44.7 seconds to the last result, 29.8x against doing them one at a time. Redrawn in English from the 10 October 2026 run record (vendor material).
That number is a property of your design, not the model. Three choices set it: whether the boundary is enforced outside the model, whether the avatar verifies its own send landed, and whether the receipt volunteers the caveat. With all three you review exceptions. Without them you review everything, and you’ve bought a faster way to work.
Where avatars are genuinely worse
Setup is front-loaded. A chatbot works in ninety seconds. An avatar needs a role, a boundary policy per action type, and a body of reference material — otherwise it produces confident work from nothing, which is worse than producing nothing. Budget an afternoon for the first one.
It can act before it should. A chatbot’s worst case is a bad paragraph. An avatar’s is a sent email or a spent budget. The design is defensive about this and it costs responsiveness: you get interrupted, you resent it, and if you turn the interruptions off you’re back to trusting a prompt.
Attribution cuts both ways. Being visible as an avatar means your colleagues can see it wasn’t you. If you wanted it to quietly represent you, this refuses. Deliberate trade-off, not a feature.
And a naming problem worth saying plainly: a lot of what’s sold as an “avatar” is a chatbot with a face. The visual layer is not the property. If it can’t name the file it produced, it isn’t in this category no matter how good the render is.
What I’d actually do
Run five tests before any purchase conversation, in the tool you’d really use rather than the vendor’s sandbox — half these properties belong to the environment, not the model.
- Ask for something with a file at the end. See where the file lands.
- Ask for something at the edge of its material. See whether it tells you the edge.
- Ask it to do something adjacent to what it’s allowed to. See whether it declines, asks, or just does it — and whether you can find the record afterwards.
- Ask the history question and demand the source.
- Put an avatar and a human in the same group. See whether origin is obvious at a glance.
Pass 1, 4 and 5 and you have the architecture. Pass 2 and 3 and you have the discipline. You want both, and neither is a model feature you can read off a spec sheet.
So: which of your recurring tasks actually ends in a file?
What KarmaBox does here
This is product information about our own work, not an independent review.
KarmaBox ships nineteen avatars, each with a boundary policy per action type — send, publish, spend, delete — enforced server-side, so the policy survives a model swap. Each hands back a receipt rather than only a result. It runs on a free iOS app and on hardware you hold; local models such as Llama and Qwen run on the device, and each task can be routed to a model you choose.
The parts I’d want you to check rather than take on faith: whether the model tier you need actually fits the hardware you’d buy, and whether your volume is high enough for the local economics to flip. The full write-up is on our site, and it’s the canonical version of this piece.
What this doesn’t give you: the strongest reasoning available. On the hardest problems, a hosted frontier model is still ahead, and a hybrid setup beats a purist one. It also doesn’t remove the setup afternoon, or the approval fatigue.
If it isn’t a fit, no problem — every test above works on any tool you’re considering.
If you’d rather not go looking: the whole thing reduces to one question. When it does something you didn’t watch, how do you find out what it did?
Sources
- TechCrunch — How OpenAI turned its coding tools into dots, an always-on personal assistant, Tim Fernholz, 26 October 2026. Secondhand reporting of an on-stage interview. The $100/month price, the three-minute warning, the refusal of read-only cloud drive access and the Embiricos quote are all from this piece.
- KarmaBox — What’s it actually like running 20 avatars at once?, 12 October 2026. First-party measurement from a run on 10 October 2026; single account; vendor content. Source of the 95 tasks / 44.7 seconds / 1,332 seconds figures.
- Model Context Protocol specification, public standards document, accessed 28 October 2026. Primary.
- Agent2Agent protocol specification, public standards document, accessed 28 October 2026. Primary.
- Our own operating records — scenario details and internal failure modes, 2026. First-party, not customer cases and not survey data.
The three-page-deck anecdote is a first-party operating record, not a customer case.
