Andrew Missey, CTO and Co-Founder of Convos – Interview Series

Andrew Missey, CTO and Co-Founder of Convos, is a software engineer and product leader with experience spanning AI product development, software architecture, networking, and full-stack engineering. Before co-founding Convos, he helped develop and launch two AI-powered creative and marketing platforms at Forum3, combining hands-on engineering with technical product management. His earlier roles at N-able (NABL ), Autoshop Solutions, and Brand IQ involved building frontend applications, backend systems, client dashboards, and internal software tools using technologies including Svelte, NestJS, Angular, and JavaScript. This multidisciplinary background has enabled him to bridge technical execution with product strategy as he leads the development of Convos’ AI-driven communications platform.

Convos is a controlled AI-powered texting platform designed to help political campaigns and communications firms replace one-way mass messaging with personalized, two-way voter conversations at scale. The platform converts responses into real-time sentiment analysis, topic classifications, call-to-action results, engagement metrics, and structured voter insights that campaigns can use to refine their outreach. Its closed-system AI operates within campaign-approved materials and messaging guardrails, while providing features such as contact segmentation, conversation histories, link tracking, data exports, and compliance-focused audit trails. Convos can also complement an organization’s existing texting infrastructure rather than requiring it to replace its current communications systems.

You co-founded Convos after observing how political and organizational texting had become largely one-way communication. What was the original insight that convinced you there was an opportunity to transform mass texting into AI-powered conversations, and what were the biggest technical challenges you faced in building the platform?

The insight came from being on the receiving end of it.

Around the 2024 election I was getting bombarded with political texts, like a lot of people were. At some point I started replying to them. I would ask a question or respond, and nothing ever came back. The messages were going out by the millions, but the moment you tried to have an actual exchange, there was no one there.

It struck me as a huge missed opportunity. The person on the other end was already engaged. They were asking a real question. But no response would ever be sent.

So the idea behind Convos was simple. Turn the broadcast into an actual conversation, at scale, without needing a room full of people to staff it.

The biggest technical challenges came down to three things: scale, latency, and compliance.

Scale is the obvious one. You are managing thousands of conversations at the same time, and each one has its own state and history. Latency matters more than people expect. If someone texts back and the reply takes too long, the moment is gone. Texting feels nearly immediate, and the experience has to match that.

Compliance was the hardest part, and it was something we prioritized from the beginning. Political texting is heavily regulated, and getting it wrong is not an option. A lot of our early engineering went into making sure the system stayed on message and respected consent and opt-outs in ways that go well beyond just catching the word “STOP.”

Convos operates at the intersection of conversational AI, large-scale messaging, and real-time sentiment analysis. What lessons have you learned from deploying AI systems that must engage thousands of people simultaneously while still feeling personal and authentic?

The biggest lesson is that “personal at scale” is something you have to engineer for. It does not happen by default.

When you are running thousands of conversations at once, the temptation is to treat them as one big batch. But the person receiving the text does not care about your batch. To them it is a one on one exchange, and it has to feel that way. That means every conversation has to carry its own context and history, so a reply actually responds to what that specific person said, not to some average of everyone.

We also learned to pay close attention to what people are really telling us. A reply is not just a reply. It carries sentiment. Someone can respond with a question, with enthusiasm, with frustration, or with a clear signal that they want to be left alone. Reading those nuances correctly is what makes or breaks an interaction.

In the end, authenticity comes from listening, not from sounding clever. The exchange that feels most human is the one that answers the actual question and respects the person’s time.

You’ve argued that many organizations focus too heavily on model benchmarks while overlooking personality and communication style. Why do you believe personality is becoming a critical factor in enterprise AI deployment, and how should organizations evaluate it?

Benchmarks measure capability. They do not measure fit.

A model can score extremely well on reasoning or coding and still be the wrong choice for a conversation with a voter. The way it phrases things, how warm or how formal it sounds, whether it knows when to be brief, all of that matters enormously once a real person is on the other end.

In our world the model is not solving a math problem. It is representing a campaign in a text message. Every campaign has its own voice, and the model has to match it rather than impose its own. If the tone is off, it does not matter how smart the underlying model is. The interaction fails.

There is also a capability side to this that benchmarks miss. A campaign can give the agent detailed guidance on what to say, what to avoid, and how to handle specific topics. The model has to follow all of it, consistently, across a long back and forth. Some models are far better than others at holding onto complex instructions without drifting halfway through the conversation. That ability is part of personality too, because a model that sounds great but stops following its instructions is not one you can put in front of real people.

That is why personality is becoming a real factor in enterprise deployment. As models get more capable across the board, the raw capability gap between them narrows. What is left is character. How they communicate, and whether they stay within the lines you set.

The way to evaluate it is not on a leaderboard. It is to test models on your actual use case, with your actual content, and read the outputs the way your end user would. We put models through the exact kind of exchanges they will handle in production and judge them on whether the conversation feels right. That tells you far more than a benchmark score ever will.

Your team has tested multiple leading models and observed significant differences in how they perform across tasks. What have you learned about the strengths and weaknesses of today’s major LLMs, and why are some better suited for conversational work than others?

What we have learned is that there is no single best model. There is only the best model for a given job.

Some models are excellent at following instructions precisely, which matters when you need the system to stay inside strict boundaries. Some are stronger at natural, conversational tone. Some are faster, which is its own kind of strength when latency is part of the experience. Others are better at reasoning through a complicated request but feel stiff or take too long to respond in a casual exchange.

For conversational work specifically, the qualities that matter are not always the ones that get headlines. Speed matters. Consistency matters. Knowing when to be short matters. A model that writes a beautiful three paragraph answer is often the wrong choice when the right answer is one sentence.

None of this shows up on a leaderboard. You only learn it by putting models in front of the actual work and paying attention to how they handle it.

Many companies are increasingly adopting multi-model strategies rather than relying on a single AI provider. What are the advantages of building systems that can switch between models, and what architectural considerations are required to make that possible?

The main advantage is that you are not locked in.

If you build everything around one provider, you inherit all of their constraints. Their pricing, their rate limits, their latency, their outages, and their release schedule become yours. A multi-model approach lets you route each task to whatever model handles it best, and it gives you somewhere to go when one provider has a bad day.

It also lets you match the cost to the job. Not every interaction needs your most powerful and most expensive model. Being able to send the simple work to a lighter model and reserve the heavy model for the hard cases makes a real difference at scale.

The architecture is what makes this possible, and the key decision is to build an abstraction layer between your application and any specific model. Your system should not be talking directly to one provider’s API all through the codebase. It should talk to your own internal interface, and that interface decides which model actually handles the request.

Once you have that, you can add routing logic, fallbacks when a provider fails, and the ability to swap models without rewriting your application. You also need consistent handling of prompts and outputs across models, because each one behaves a little differently, and your system has to smooth over those differences.

It is more work up front. But it buys you flexibility that is very hard to add later.

You recently highlighted how rapidly AI models evolve, with new releases sometimes changing performance characteristics in unexpected ways. How should enterprises balance the desire to adopt the latest models with the need for stability, reliability, and predictable performance?

The honest answer is that a new model is not an upgrade until you have proven it is one.

Every release is exciting, and there is real pressure to adopt the latest thing right away. But we have seen new models change behavior in ways that we were not expecting. Something that worked reliably starts responding a little differently, and in a production system those small changes add up.

The way we handle it is simple. No model goes into our pipeline until we have hand tested it ourselves. When a new release comes out, we do not take the benchmarks or the announcement at their word. We sit down and run it through its paces on the exact kind of conversations it would be handling in production, and we read the outputs ourselves.

That hands on step is not optional for us. A model can look better on paper and still handle a real exchange in a way we are not comfortable putting in front of voters. The only way to know is to put it through the same situations our system deals with every day and see how it actually responds.

This is another place where the abstraction layer earns its keep. Because our application does not depend on one specific model, we can bring a new release in, test it against the conversations we actually handle, and compare it honestly against what we are already running. If it clears the bar, we switch. If it does not, we wait.

Hallucinations remain one of the biggest barriers to enterprise AI adoption, especially when models work with large datasets and complex information. What practical techniques have proven most effective in reducing hallucinations in production environments?

The most effective technique we have found is to constrain what the model is allowed to know.

A lot of hallucination comes from asking a model to answer from its own general knowledge, where it will happily fill gaps with something that sounds right. We do the opposite. Our AI works strictly from the information the campaign has provided. It does not have access to the open internet, and it is not drawing on some vague memory of the world.

If the answer is not in the material it was given, the correct response is to say it does not have that information. That single boundary removes an enormous amount of risk.

We do not stop there, though. We have multiple checks in place to make sure a response matches what the campaign provided. Even after the model generates a reply, that reply is cross checked against the campaign’s information before it goes anywhere. If something does not line up, it does not get sent.

Beyond that, the practical techniques are about grounding and guardrails. Give the model the specific, relevant context it needs for the task in front of it rather than a giant undifferentiated pile of data. The more focused the information, the less room there is to drift.

We also put clear limits on what the system is allowed to do and say, and we monitor real conversations rather than assuming everything is fine. You do not catch problems by trusting the model. You catch them by watching the output.

In a regulated space like political texting, a made up answer is a liability, so we designed the system to prefer transparency over guessing.

As organizations deploy AI agents across customer support, communications, marketing, and operations, what mistakes do you see teams repeatedly making when moving from pilot projects to production-scale deployments?

The mistake I see most is that teams test whether their agent works, but not whether it can be broken.

I cannot count how many times a company has released an AI chatbot, and within a day someone online has jailbroken it into saying something it was never supposed to say. It gets talked out of its instructions, tricked into going off script, or manipulated into representing the brand in a way that ends up as a screenshot everyone is passing around.

That happens because in a pilot, everyone is well behaved. You are testing the agent with reasonable people asking reasonable questions, and it looks great. Production is the opposite. The moment something is public, a portion of the people talking to it are actively trying to trip it up.

If you have not tested for that adversarial case, you have not really tested it. You have to try to break your own system before someone else does. Push it, feed it the strange and hostile inputs, and see whether it holds its boundaries when someone is deliberately working against it.

The other repeated mistake is assuming a demo that works is a system that works. A pilot is a handful of watched conversations on the happy path. Production is thousands of people at all hours behaving in ways you did not anticipate, and the edge cases you waved off become daily events at scale.

My advice is to spend less time perfecting the demo and more time trying to break the thing yourself. If it can’t survive you attacking it, it will not survive being public.

AI agents are becoming increasingly capable of handling conversations that once required human staff. Where do you see the balance between automation and human oversight over the next five years, and which workflows do you believe should always keep a human in the loop?

This is a hard one, and I do not think anyone honestly knows exactly where the line lands in five years. The way I think about it, the real value of AI is as a force multiplier. It lets a small group of people do far more than they ever could alone.

The teams getting the most out of these tools are using them exactly that way. The AI takes the volume and the repetition, and the people spend their time on judgment, strategy, and the situations that genuinely need a human. That is a very different goal than trying to remove people from the picture.

When the goal is pure replacement, you tend to push the technology past what it is actually good at, and it fails in ways that are visible and expensive. When the goal is to multiply your people, you let the AI do what it does well and keep humans where they add the most value. The second approach works better, and it is more honest about where the technology really is today.

Over the next five years I expect agents to take on more and more of the routine conversational load, and they should. That work does not need a person watching every word.

The workflows that should always keep a human involved are the ones where the stakes are high or the situation is genuinely new. Anything that touches consent, compliance, or a decision that would be hard to walk back. A person should own the direction, and the AI should help them cover far more ground than they otherwise could.

Looking ahead, what developments in conversational AI are you most excited about, and how do you envision platforms like Convos evolving as models become more capable, multimodal, and autonomous?

What excites me most is that the conversations are going to keep getting better.

As models improve, the exchanges our platform handles become more natural and more useful without us having to rebuild the foundation each time. Because we designed the system to move between models, we get to bring those improvements in as they arrive.

Multimodal is the development I am watching most closely. Right now the conversation is text. As models handle images and other formats more capably, there is a real opportunity to make these exchanges richer while keeping the immediacy that makes texting work.

On autonomy, I am optimistic but careful. More capable agents are being released monthly, and they will be able to handle a great deal on their own. But in a regulated space, more autonomy has to come with more discipline, not less. The boundaries matter more as the capability grows.

I got into this because I was the person texting into the void and getting nothing back. That is still the problem I care about most. No matter how capable these models get, the measure I keep coming back to is simple. Does the person on the other end feel heard?

Thank you for the great interview, readers who wish to learn more should visit Convos.