A few months ago, our engineering team at Tars started asking a dangerous question : if we built Tars today, with everything we have learned from ten years of customer conversations and everything that is now possible with AI, what would we build ?
Underneath it was the question we kept returning to : what would it take for a business to not just deploy an AI agent, but actually trust it with real customer conversations ?
The answer is what we have been calling Tars 3.0.
It is not a new coat of paint or an LLM added on top of the existing product. We have been going back to first principles and rebuilding the foundation : how a conversation runs, how AI makes decisions, how a human joins, how messages move across channels, and how we know the whole thing actually works.
This article is a look at what we have been building, why we are building it, and the ideas underneath it — without turning it into a technical changelog nobody asked for.
The belief behind the rebuild
Tars is a conversational CX platform. Businesses use it to answer questions, guide customers through processes, take actions in other systems, and bring in a human when human judgment is needed.
But the customer on the other side does not care whether the last response came from an AI agent, an automated flow, a support executive, or an API. They do not care which internal system received the message. They care about one thing : did this conversation help me ?
That is the belief behind Tars 3.0 : a customer should get one continuous, useful conversation, no matter who — or what — is handling it at that moment.
The product should carry the context. The customer should never have to restart, repeat the problem, or learn how our software is organized just to get an answer.
Starting from first principles does not mean starting from zero
Tars has been in this industry for almost a decade. That history matters.
Over the years, we have learned that great customer conversations cannot be built with AI alone. Some moments need flexibility and judgment. Some need a strict, predictable process. Some need a human. Most real conversations move between all three.
We have also learned where CX systems are tested hardest : incomplete questions, frustrated customers, information spread across different systems, channel switches, failed integrations, and all the strange edge cases that never appear in a polished demo.
Tars 3.0 carries those lessons forward. The first-principles part is not forgetting what came before. It is separating what is essential from what is accidental, keeping the capabilities customers rely on, and rebuilding the underlying system for the next decade.
A completely new conversation engine
The heart of Tars 3.0 is a new conversation engine.
An AI model by itself is not an agent. The model sits inside a larger system — the harness — that gives it context, knowledge, tools, memory, safety boundaries, and a way to decide what happens next. The quality of that surrounding system often matters as much as the model inside it.
We rebuilt this layer so that the decision-making part of a conversation is cleanly separated from the infrastructure around it. The same conversation brain can work with knowledge, call tools, follow structured steps, remember state, stream a response, or hand control to a human without every capability becoming its own disconnected path.
The principle I kept coming back to was simple : the agent we test should be the agent we ship. A simplified copy built only for a demo can tell us very little about how the real system will behave. By separating the conversation brain from its environment, we can run the same logic in production, in a test, or inside a simulation by changing what surrounds it — not the agent itself.
This boundary also lets us improve the agent loop without destabilizing the rest of the conversation. And it forces us to treat the uncomfortable paths as real product behavior : tools fail, models time out, replies can arrive empty, a human can take over in the middle of a turn. A reliable engine has to recover without losing context, repeating an action, or leaving the customer in a broken state.
The goal is not to make the AI talk more. The goal is to help it make better decisions inside a reliable system.
Security is a pillar, not a layer
A conversational CX platform sits unusually close to sensitive data. Customers share names, phone numbers, account details, grievances, and sometimes information they would not put into any other interface. An AI agent may also be allowed to search internal knowledge, call business tools, update a record, or trigger a workflow.
The moment an agent can act, security stops being only an infrastructure concern. It becomes part of conversation design.
One rule has shaped many of our decisions in Tars 3.0 : every boundary is a trust boundary. A customer message is untrusted input. So is an uploaded document, a tool response, a webhook, or content arriving from another system. None of it should silently gain authority just because it appeared inside the agent's context.
That principle shows up across the platform : keeping customer organizations isolated from one another, validating data at the edges, keeping credentials outside the agent's reach, limiting tools to the actions they are supposed to perform, and making important state changes explicit and traceable. Where a process cannot tolerate improvisation, a structured workflow should constrain what happens instead of asking the model to make up the rules each time.
Security also includes how the system fails. A provider error should not expose an internal secret. A retry should not perform the same action twice. A malformed input should not crash the conversation. A human takeover should immediately stop an older AI turn from continuing in the background. These cases are easy to ignore in a demo and impossible to ignore in production.
Compliance and certifications matter, especially for the regulated industries Tars serves. But our responsibility cannot end at a badge. The safer architecture is the one where the default path gives every component the least authority it needs, risky behavior has a clear boundary, and every important action leaves enough evidence to understand what happened later.
Trust is not something we can add after the agent becomes capable. It has to grow with the capability from the beginning.
AI and humans in the same conversation
Human support is not a fallback we wanted to bolt on after the AI is done. It is a native part of Tars 3.0.
An AI agent can instantly handle the questions it understands, fetch information, and complete routine actions. When the situation becomes sensitive, ambiguous, or simply needs empathy and judgment, a support executive can step into the same thread with the full context already there.
No separate conversation. No copy-pasted summary. No asking an already frustrated customer to explain everything again.
The AI and the human are two possible controllers of the same conversation. This sounds like a small distinction, but it changes how the entire product is designed. Live chat is not an integration at the edge of the platform; it is part of the platform's core.
A good handoff should feel like help arrived, not like the conversation restarted.
One conversation, every channel
Customers do not live in one channel. They might start on a website, reply later on WhatsApp, and expect an update over email or SMS. The conversation should survive that movement.
For Tars 3.0, we built the channel layer around a simple idea : the core of the platform should understand conversations, not the quirks of every transport.
At the edge, a gateway translates incoming messages into a common language the conversation engine understands. On the way out, a channel adapter turns the response into the right shape for its destination. The brain does not need to be rebuilt every time a new channel is added.
This makes channels easier to add, but the bigger benefit is consistency. The same rules around identity, consent, delivery, retries, and conversation state can be applied in one place instead of being re-invented for every channel.
The channel is where a message travels. It should not decide how intelligent the conversation is.
Confidence has to be built, not assumed
Most AI demos are designed to succeed. Production conversations are not.
A real customer might be impatient, provide half the information, change the subject, phrase the same question in ten different ways, or ask for something the agent should refuse or escalate. Testing a few happy-path prompts cannot tell you whether an agent is ready for that reality.
As the new platform started taking shape, we kept returning to a different version of the same question : how will we know that each change actually made the agent better ?
That question is why evaluations have become a central part of how we are taking Tars 3.0 forward.
We are building a system that can simulate complete conversations before an agent reaches customers. Instead of checking one isolated answer, we can put the agent in realistic scenarios, let a simulated customer interact with it over multiple turns, inspect the resulting conversation, and evaluate whether the agent behaved the way the business expected.
Did it give the right answer ? Did it use the right tool ? Did it follow the required process ? Did it know when to bring in a human ?
We are not trying to compress an entire customer experience into one impressive-looking score. A number can tell you that something failed; it rarely tells you what to fix. The useful unit is a failure we can understand : the agent missed an intent, used the wrong tool, skipped a required step, gave up too early, or failed to escalate when it should have.
There is another important detail : an evaluator can be wrong too. Asking one AI to grade another does not automatically produce truth. The evaluator has to be checked against human judgment before its verdicts deserve trust. Otherwise, we have only moved the guesswork one layer higher.
Evaluation, then, is not a one-time gate before launch. It becomes a loop : test, find a failure, understand it, improve the agent, and run the same scenarios again. When a new model, prompt, tool, or knowledge source is introduced, the team can see whether the change actually made the agent better — and whether it quietly broke something that used to work.
A demo gives you excitement. An evaluation system gives you confidence. You need both, but only one of them should decide whether you ship.
I am intentionally keeping the mechanics of our simulation system for another article. The important idea is simple : businesses should be able to see evidence that their agent works the way they expect before real customers have to discover where it does not.
The invisible work matters too
Some of the most important improvements in Tars 3.0 will never appear as a big feature card.
We have upgraded the technology underneath the product, followed web standards more closely, consolidated repeated patterns, made boundaries between systems explicit, and removed accidental complexity that had accumulated over time. We have also put more thought into reliability, observability, security, and what happens when a dependency inevitably fails.
None of this makes for a flashy demo. Customers may never know which part of the stack changed. They will feel the result when a conversation is faster, an error recovers cleanly, a new channel behaves consistently, or the team can improve an agent without being afraid of breaking something unrelated.
That is the strange thing about platform engineering : when it is done well, the complexity becomes less visible, not more.
This has been a team effort
Every engineer sees a rebuild through a different window. Mine has naturally been closest to the conversation brain and the question of how we can trust it. But neither exists in isolation, and Tars 3.0 is the result of work across the entire engineering team.
Rebuilding a product like this means thinking through hundreds of decisions that users should never have to think about : conversation state, identity, live-agent routing, billing, permissions, streaming, channels, retries, analytics, and the small interactions that make the product feel coherent.
The most encouraging part has not been any single feature. It has been watching those pieces converge around the same idea : one platform for AI and human conversations, built to give customers a genuinely better experience.
The loop we are building toward
Tars 3.0 is not a claim that we have solved conversational AI. Nobody has. It is also not a system we expect to declare "finished" on launch day.
The direction is a continuous CX learning loop : understand what customers actually contact a business about, turn that reality into scenarios, test the agent, deploy it across channels, observe what happens, and feed every meaningful failure back into the next version.
A strange production conversation should not remain an anecdote buried in a support thread. It should become a case the agent can be tested against forever. A fix should not be accepted because it sounds sensible; it should have to prove that it solves the failure without creating a new one somewhere else.
Models will keep improving, and we will benefit from that. But a product that gets better only when a model provider releases something new is not truly learning. The more durable advantage is the system around the model : the harness that lets it act reliably, the evaluations that show where it fails, and the loop that turns those failures into improvements.
That loop is the real product — and it is how we intend to keep making Tars 3.0 better long after its first release.
We are still building, testing, and polishing, and I am excited to share more as Tars 3.0 gets closer to customers. For now, the simplest way I can describe what we are making is this :
Tars 3.0 brings AI, structured workflows, human support, and every customer channel into one continuous conversation — and gives businesses the confidence to trust it.
I hope you find this article interesting. Thanks for reading. Until then, bye 👋