Hello, and welcome!
Today, our topic is broad: why do we need AI-first software architectures, and how do they differ from traditional approaches? It will take us several posts to look at specific solutions, but let's start with defining the goal: to leverage AI in a business setting, via software, to significantly reduce cost, effort, and risk - and to improve the quality of our services. This forces us to look far beyond a well-understood use of AI for writing marketing copy, taking meeting notes, summarizing documents, or conducting web research. The text capabilities are now commonplace and do not necessarily require specialized architecture.
Today, we will focus on those far less trivial. Let's start by discussing autonomous AI phone calls. Many businesses rely on the revenue generated by their contact centers. They rely on placing sales calls or receiving calls in response to advertising, a web presence, or from existing customers. This includes practically all field services companies, and more. Other businesses use phone calls for customer support, and the quality of those calls affects customer retention, reputation, and, subsequently, customer acquisition and subscription revenues.
At the same time, operating a contact center staffed with human agents is costly. In search of a less expensive solution, many businesses hire offshore agents, which often leads to a decline in quality. Replacing human agents with AI is an obvious way forward. A good number of startups sprouted in the phone call automation space: VAPI (pronounced as Vahpee), Retell, Bland, and LiveKit, just to name a few. Those companies do a fantastic job automating phone calls, but, more often than not, retrofitting calls into traditional software architectures is painful. The first challenge is that most business architectures today are transactional and are designed to support fast-executing commands: the user pushes a button, and the system responds in sub-second time. A phone call (and any other work done by an LLM) takes much longer to execute, and the software must be able to track long-running activities and their context. This is easier said than done. Database transactions will time out and block concurrency; network connections will be dropped; serverless architectures will exceed their execution time limits; and countless other issues will arise.
The second challenge is enabling a human-in-the-middle. This is necessary because we don't fully trust AI - and not without a reason. The AI may fail to perform a task on its own, and it may require human assistance. This imposes atypical requirements (uncommon in traditional business software) on both the core architecture and the user experience design.
Then, there's trust. AI has earned very little of that so far. For that reason, you may want a human to evaluate the results of AI work either always or when certain conditions are met (or not). For instance, in a house repair coordination system, AI could be tasked to call local vendors to schedule service appointments, but you may want to force a human review when the vendor's hourly rate is out of a predetermined range. You may also want to prevent the outcome of AI work from being recorded by the system until a human review takes place. But a human operator may not be available at the time AI finishes its job, so you need to have queues of some sort that are monitored by humans. This would be unusual if compared to a traditional design.
The next challenge is security. AI agents are prone to leaking sensitive information and vulnerable to prompt-injection exploits. A proven approach to preventing information leaks is practiced by military and intelligence agencies worldwide: the "need-to-know principle". In the AI context, it means allowing the AI to access only the dataset necessary to complete its current assignment, and no more. Similarly, we must limit the tools to those required for the task at hand, and their functionality must be strictly controlled. This differs from traditional business software, which typically has unrestricted access to the entire database from all server-side code. In such applications, security is typically enforced at the perimeter when a user accesses the application's exposed functionality, but rarely within the internal code. For AI functionality, perimeter-only security is insufficient and must be woven into the system's internals. A more reliable approach is implementing a true zero-trust security.
A related risk is authentication. While outbound calls are relatively straightforward and low-risk, the inbound ones are a practical nightmare and can leave your entire system wide open. There's no traditional password-based login, which served us well for decades on terminals and on the web. We need something new.
So far, we've only looked at phone calls, but AI can do much more. Extending calls to texting seems straightforward, but it has its own pitfalls. One of them is that SMS sessions have no definitive end, unlike phone calls, which end when the line is disconnected. This has to be taken into account.
If not faint of heart, we may start using AI to make human-grade decisions. In most applications, decision-making is not represented in the design. Let me give you an example. Let's say the application is a shopping site that displays products and allows users to click the Buy button. Here, the Buy button registers the outcome of the human decision, but the decision process happens in your head; the application only provides you with the food for thought in the form of a product listing, and a way to register the decision once it is made. There's no Think button anywhere, and there's nothing on the screen to initiate and run an AI workflow. This is one reason an AI assistant is often cramped in a chat box: connecting it natively to the rest of the application is far from trivial. An obvious solution would be to package the decision-making workflows in an RPA tool, but that is a clumsy and unreliable afterthought, far from solid architectural practice. If you want AI decision-making to be a native part of your solution, you will need to do better.
Now, whether you use AI for phone calls, SMS, decision-making, text processing, or any other purpose, there is one thing about it that renders traditional architectures obsolete. Software of the past was deterministic by construction. That is, for any given input, it acts 100% predictably. This shaped software engineering since its inception. AI, in contrast, is probabilistic in nature. It gives us results that range from acceptable to completely hallucinated, that have no bearing on reality, but are delivered with high confidence. This mandates adding an evaluation step (manual, programmed, or AI-driven). From an architectural perspective, you have very few options: either create a harness around AI that makes it deterministic and, as such, pluggable into traditionally written software, or embrace a probabilistic approach throughout your entire architecture (which is much harder and somewhat counterintuitive). The third option is a probabilistic harness with deterministic tools used within it, the path taken by today's agentic systems that use MCP tools, such as Cursor or Claude Code.
The main takeaway from today's discussion is that you need a specialized, AI-first software architecture to leverage AI capabilities in modern business solutions. Not convinced? Share your questions and thoughts in the comments. Mention the specific use cases that you want me to cover going forward. I will do my best to respond promptly.
Subsequent posts will provide specific recipes for the challenges I've mentioned, as well as more.
All the Best!