Randall Newman, CPTO and Co-Founder of Satisfi Labs – Interview Series

Randall Newman, CPTO and Co-Founder of Satisfi Labs, is a technology and product leader with extensive experience building AI platforms, financial technology, and high-performance systems. Since co-founding Satisfi Labs, Newman has played a central role in envisioning, designing, and scaling the company’s conversational AI technology, while overseeing product development, architecture, engineering teams, and strategic integrations. Before Satisfi Labs, he served as Head of Product at Satisfi Inc. and co-founded mobile marketing company Right On Mobile. Earlier in his career, Newman spent more than 17 years at CIBC World Markets, where he held senior leadership roles spanning strategic risk, high-frequency trading, and equity arbitrage, combining quantitative trading expertise with hands-on technology development.

Satisfi Labs is an AI company focused on deploying specialized AI agents for sports, entertainment, tourism, attractions, and other live-experience businesses. Founded in 2016, the company has evolved from conversational AI and its Answer Engine into an agentic platform designed to help organizations automate guest support, increase ticket and commerce conversions, and extract insights from customer conversations. Its AI agents can operate across more than 50 languages and connect with ticketing, CRM, content management, and other business systems to perform actions such as selling tickets, escalating conversations to human staff, collecting customer information, and delivering personalized responses. Satisfi Labs says its technology is now trusted by more than 775 brands, with integrations and partnerships spanning companies such as Ticketmaster, Simpleview, MappedIn, Ventrata, and Vozzi.

You spent nearly two decades in financial markets, including building low-latency trading systems and leading high-frequency trading strategies at CIBC, before moving into technology entrepreneurship and ultimately co-founding Satisfi Labs. What lessons from operating systems where speed, reliability, and risk management were critical have most influenced how you build production-grade AI agents today?

Trading taught me that a good idea and a good business are two different things. You can identify an opportunity correctly and still lose money because your execution is slow, your costs are too high, or your risk assumptions are wrong. AI is the same. Model capability is one input. The business depends on whether you can turn that capability into a repeatable outcome at an acceptable cost and risk.

Running an index arbitrage book also teaches you to look past individual decisions. A small error repeated across a portfolio becomes a very large exposure. With AI, you can have thousands of agents making individually reasonable decisions that collectively create a problem. They all depend on the same bad data, or they all retry the same failing service. You have to manage the system, not just the individual response.

And speed only matters when it improves the outcome. In trading there were moments where microseconds mattered. In AI, I’d rather spend one more second confirming a transaction than deliver the wrong result instantly. The discipline is knowing where speed creates value and where it just accelerates a mistake.

The last lesson is the one that started the whole business. The edge comes from spotting a mispricing before everyone else does. I think the mispricing right now is that most businesses look at AI agents as a way to cut support costs. At Satisfi Labs, we see them as a revenue channel. At our sports venues, about 40 percent of agent conversations are about tickets. These fans aren’t coming to complain. They’re showing up with money in hand, asking where to sit. Find the thing the market’s priced wrong, and go capture it. Same instinct as the arbitrage business.

Satisfi Labs was founded in 2017, well before the current generative AI boom, and has evolved from contextual natural language processing and conversational AI into an agentic platform. What were the biggest architectural changes required to move from systems designed primarily to answer questions to agents capable of taking actions on behalf of users?

We spent a decade building thousands of AI agents for 800+ enterprise clients including MLB/NFL teams, entertainment venues, and tourism organizations.The biggest change is that you’re giving the system authority, not just information.

If an assistant tells you which tickets are available, it’s providing an answer. If it exchanges your tickets, it’s changing inventory, customer records, and potentially money. Now you need to know who authorized the action, what actually happened, and how to recover if the process stops halfway through.

So we separate the model’s judgment from the authority to execute. The model can interpret a request and propose the next step. The systems underneath it enforce permissions, business rules, and transaction limits. A persuasive explanation from the model can’t override those controls.

You also need a hard distinction between “the agent said it completed the task” and “the business system confirmed completion.” Those aren’t the same thing. If a purchase request times out, you’d better find out whether the purchase happened before you try again.

And strategically, better models shouldn’t force you to rebuild your business controls. I want to take advantage of every improvement in reasoning without renegotiating what the system is allowed to do each time a new model ships.

The term “agentic AI” is now being applied to a wide range of products. From an engineering perspective, where do you draw the line between an advanced chatbot, an AI copilot, and a genuinely autonomous AI agent?

I’d ask one question: what responsibility has the person actually delegated?

A chatbot provides information. A copilot helps you get work done, but you’re still directing and approving the important steps. An autonomous agent has permission to make some of those decisions itself while pursuing an objective.

The interface doesn’t tell you which one you’re looking at. A conversational product can have real autonomy behind it. Something marketed as an agent may still need a person to approve every useful action.

For an enterprise, autonomy should be a specific agreement: this system may perform these actions, for these users, within these limits, and must stop under these conditions. That’s something you can actually test and govern.

I also wouldn’t make maximum autonomy the goal. Sometimes the best product asks one well-timed question and handles the rest. Removing that question makes the demo more impressive and the business less safe. The objective is to remove unnecessary human work, not necessary human judgment.

Satisfi Labs recently launched Satisfi Forward, a forward-deployed engineering practice. What gap were you seeing between building a capable AI platform and actually getting agents to work reliably inside a customer’s real-world environment that led you to create this model?

The last mile was becoming the bottleneck. A platform can standardize a lot, but it can’t assume every customer’s business works the same way. Their ticketing system has certain limitations. Their approval process runs through three departments. Their definition of a qualified lead is different from the next client’s. Those details decide whether the deployment is actually useful.

You can buy an out-of-the-box platform and put together a demo that impresses people. Commercializing it as a robust experience for real users, that’s different. That’s where forward-deployed engineers come in. Our team at Satisfi Forward’s job is to understand the outcome, figure out what’s blocking it, and build the workflows and integrations on top of the platform that make it happen.

But we put clear boundaries around every engagement. Before we build, we agree on what success means, who owns the business process, what depends on the customer, and who maintains it after launch. Otherwise a last-mile project becomes an unlimited obligation. And the engagement isn’t done when the code ships. It’s done when the workflow works in the customer’s operation and somebody’s accountable for keeping it working.

Code’s also gotten much cheaper to produce, which makes this model far more practical than it used to be. But I don’t look at Satisfi Forward as a services arm bolted onto a SaaS product. Every engagement teaches us what the next product should be. When three customers ask for the same workflow, that’s not a support burden. That’s the roadmap writing itself, with paying customers attached. The old SaaS model guessed at features and waited for evidence. This way we get the evidence first, and the revenue while we gather it. I think that’s how product companies get built in the AI era.

Your agents can connect with ticketing systems, customer relationship management platforms, content management systems, and other sources of real-time information. As agents gain the ability to transact and trigger actions, how do you balance real-time data access and low latency with grounding, security, and safeguards against incorrect actions?

First, I’d never let speed compensate for a security failure. Some requirements are constraints. You optimize within them.

Then you distinguish between types of work. Answering a parking question and completing a ticket purchase don’t need the same data freshness or the same controls. You can cache stable information. When money changes hands, you need the authoritative transaction system to confirm price, availability, and completion.

The dangerous cases are the ones where the system doesn’t know what happened. A backend accepts a purchase, but the response never arrives. If the agent assumes failure and retries, you’ve got two purchases. That’s not a language problem. That’s a transaction-recovery problem.

And you measure the experience under the conditions that actually matter. Average latency on a quiet Tuesday tells you almost nothing. If an event gets rained out, you suddenly have thousands of people asking what happens to their tickets, all at once. If you only plan around average traffic per minute, you’ll miss the capacity you need in that burst. I learned that directly from trading systems.

There’s a cost decision in here too. Not every request needs the most expensive model or a chain of agents. Use the simplest path that meets the requirement, and spend the extra time or computation where it materially improves the decision. The user should get an honest result, including an honest statement that something couldn’t be confirmed.

Satisfi Labs describes a model in which specialized agents can operate together as an AI workforce. What are the hardest technical problems involved in orchestrating multiple specialized agents, particularly around routing, shared context, conflicting decisions, and determining which agent should act?

The hardest part is keeping accountability as you distribute the work.

Start by asking whether you need another agent at all. Sometimes you need a specialist. Sometimes you just need a tool call or a plain workflow. Every agent you add is another interpretation of the request, another dependency, another place for an error. And the number of agents running behind the scenes should be invisible to the user.

When several agents are justified, I want one agent to own the interaction. Specialists can provide information or do bounded work. A ticketing agent handles inventory and exchanges, a customer-service agent handles policies. But somebody has to reconcile the results and decide whether the user actually got what they came for.

Routing is hard because people don’t ask questions in neat categories. One request might touch three agents. The system has to decide: can one handle it, do several need to run in sequence, or should it ask the user one more question before doing anything?

Same with context. You don’t send everything to every agent. That adds latency, creates noise, and can expose information an agent doesn’t need. And an agent’s assumption shouldn’t become a fact just because it got passed to the next agent.

If two agents disagree, I don’t want them arguing until one sounds more convincing. There has to be a clear authority model. The ticketing system establishes availability. The business establishes exchange policy. Real-time data beats cached data, business rules beat model judgment, and if it still can’t be resolved, you ask the user or bring in a person. The hard part isn’t getting agents to talk to each other. It’s being able to reconstruct exactly which agent did what and where responsibility sat.

Satisfi Labs has increasingly focused on measuring agents against objectives and business outcomes rather than metrics such as conversation volume. What should enterprises actually be measuring to determine whether an AI agent is performing well, and how do you evaluate reliability before allowing an agent greater autonomy?

Start with the business result, then ask how much of that result the agent actually caused.

If someone buys tickets after talking to an agent, that doesn’t automatically mean the agent created the sale. They may have bought anyway. Where you can, you want controlled comparisons or a credible baseline, not just credit to the last interaction. For a ticketing client, that means measuring whether the fan ended up with seats, not whether the agent answered politely. For a venue trying to shrink lines at the box office, it means measuring what the agent resolved before anyone had to stand in one.

Then look at the economics of a successful outcome: model costs, infrastructure, human review, escalations, and the cost of fixing mistakes. An agent that looks cheap until you count the people repairing its work isn’t cheap.

Reliability needs its own scorecard. Completion, correctness, unauthorized actions, recovery from failures, escalation quality. You don’t average a serious privacy incident into a good conversion rate.

For more autonomy, I’d require evidence on the specific class of action being delegated. Test it, watch it under supervision, expand within limits, and keep a way to stop it. A good overall accuracy score doesn’t prove the system is ready for every transaction. And be careful with incentives. Sometimes bringing in a person is the correct outcome. If you reward the agent only for avoiding handoffs, don’t be surprised when it keeps problems it should have escalated.

You recently argued that voice AI needs to be designed around measurable outcomes rather than treated as another interface for an existing chatbot. What technical breakthroughs are still needed before voice agents can become a primary interface for complex, real-time interactions, particularly in environments such as stadiums, attractions, and live events?

A lot of clients ask, can you just take the chat application and plug voice into it? We can. But that doesn’t mean it’ll be a good experience. The next real improvement isn’t a more human-sounding voice. It’s an interaction that survives the conditions people actually use it in.

In a stadium, somebody’s talking over crowd noise, using an unfamiliar player name, changing their mind halfway through a sentence, and trying to finish a purchase before the gates open. The system has to handle interruption, uncertainty, and backend delays without losing the task.

Pay particular attention to critical details. Mishearing a casual phrase is one thing. Mishearing the number of tickets or the event date is another. The agent needs to confirm the details that change the consequence of the action without making the whole conversation tedious.

And voice shouldn’t be forced to do everything. Comparing twenty seating options is better on a screen. Someone might start by typing, get in the car, and want to keep the same conversation going by speaking. The system should preserve that context and use voice, text, and visuals however best fits the moment.

Some of this needs better models. A lot of it needs better integration and interaction design. Waiting for a breakthrough won’t fix a workflow that was designed around text and then read aloud. I’d judge progress one way: do people complete the task accurately, with less effort, under real conditions?

As agents move from providing information to selling tickets, collecting customer data, personalizing experiences, and interacting with operational systems, how should companies determine which decisions an agent can make autonomously and which should always require human oversight?

It’s risk management. If this goes sideways, what damage can it cause? Does the agent open a door it can’t close?

Reversibility is a useful first test, but look at total exposure too. One refund may be small and reversible. Ten thousand incorrect refunds before anyone notices is a different problem. You need limits on individual actions and on the cumulative activity of the system.

If the action’s low-risk and reversible, give it more autonomy: update a preference, check an order, hold an item. As the consequences go up, add confirmation or approval. A purchase might need the customer to confirm the price. A large refund might need an employee’s sign-off. A safety threat gets escalated immediately. And some decisions should just stay with a person, period.

Customer consent and company approval are different things, by the way. A customer confirming a purchase doesn’t authorize the agent to bypass company policy. An employee approving an exception doesn’t mean the customer agreed to a charge.

The limits have to be enforced by the systems that execute the action, not just described in a prompt. You don’t give an agent broad access and then rely on a prompt telling it to be careful. And when a person is required, give them enough context to make a real decision. Hand somebody hundreds of approvals with no information, and you’ve built a rubber stamp, not oversight. Put human attention where it reduces meaningful risk. Don’t spread it thin across every interaction.

Looking ahead, do you expect technologies such as the Model Context Protocol and agent-to-agent communication to fundamentally change how enterprise AI systems are built, moving us from isolated agents toward ecosystems in which agents can discover tools, exchange context, and coordinate actions across companies and platforms?

I think the protocols are a means to an end. MCP gives AI applications a common way to access tools and context. Agent-to-agent protocols handle cooperation between agents. That’s valuable. You shouldn’t have to build a custom integration every single time an agent needs a tool. It’s similar to what APIs did for software integrations.

But a common format doesn’t mean two businesses agree on what an action means, who can authorize it, or what happens when it fails. Just because an agent can discover a tool doesn’t mean it should be allowed to use it. You still have to figure out identity, permissions, trust, accountability. If one agent asks another to do something and it goes wrong, who owns that decision?

Here’s what I think actually changes. Today, a venue has a website and an app. In a few years, it’ll have an agent that other agents negotiate with. A fan’s personal assistant asks the venue’s agent for two seats under a certain price, plus a parking pass, and the whole transaction happens between the two agents. Finding the right capabilities is the easy step. Knowing the customer’s spending authority, confirming the combined price, and handling the case where the tickets succeed but the parking fails, those are the real problems.

And I don’t believe operating an agent automatically hands you the customer relationship. That has to be earned. But I also don’t believe venues are going to hand these transactions over to a search company or a ticketing marketplace. Our goal at Satisfi Labs is to be the agent that represents the venue in that economy, the one dependable enough that a business puts its name on it. Everything we’ve built around reliability, permissions, and accountability is what earns that seat.

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