There is a dangerous week in the life of an AI project. It is the week when everything seems to be working. The chatbot answers. The demo looks good. The CRM receives a lead. Someone connects a voice API. Management sees it and says, naturally: “Great. Let us launch it.” That is when the real engineering begins.
For Oman-based founders and companies adopting AI, this distinction is becoming increasingly relevant. Oman launched its National Programme for Artificial Intelligence and Advanced Digital Technologies to encourage adoption across economic sectors alongside localisation and governance. The National Digital Economy Programme aims to increase the digital economy's contribution to GDP from 2% to 10% by 2040.
So the useful question is moving beyond “should we use AI?” It is becoming: what happens after people actually start using it?
A successful AI prototype and a dependable AI product are two different things.
The model is often the easiest part
A modern prototype can be assembled remarkably quickly. Connect a language model. Add a knowledge base and prompt. Put a chat interface in front of it. Connect a CRM webhook. Perhaps add speech-to-text and text-to-speech. You now have something impressive.
Businesses do not operate as a single prompt. A real application has customers with different permissions, existing records, old conversations, staff workflows, missing profile fields, authentication, multiple languages, compliance requirements, rate limits and vendors whose APIs occasionally fail.
Eventually somebody asks a simple product question: “Can this user see this feature?” That answer should not depend on whether the language model is having a creative afternoon. This is the point at which AI engineering becomes software engineering.
Keep intelligence probabilistic and business rules deterministic
Use models for the things models are good at. Use ordinary software for the things ordinary software is good at.
A model can write an explanation, summarise material, conduct a conversational interview or help a customer express an idea. But whether somebody has exceeded a subscription quota, whether a product is available, what customer category someone belongs to or whether a permission is valid should normally be deterministic and auditable.
Prompts are not a replacement for an application model. This matters especially when trust, privacy and customer rights are involved.
A production example: the AI worked, but the product model had outgrown it
Our engineering team encountered this pattern while working inside the multi-vendor programme behind Thotis IA, a French digital education and orientation platform. This was not a “build us a chatbot” project. The product already had specialist AI agents, web and mobile clients, backend services, onboarding, CRM flows, messaging, voice and thousands of historical conversations.
The business wanted a simpler customer experience. Instead of exposing a technical collection of agents and internal names, the product needed to understand different user personas and return the right tools through one consistent catalogue.
On a whiteboard that is a small feature. Inside a mature product it touches data modelling, migration, caching, APIs, web and mobile contracts, localisation, historical conversations and automated testing.
The first surprise came from the database. Fields that looked like the natural source for personalisation did not contain the reliable data the new model required. Useful onboarding information lived in less obvious parts of the workflow, and some users simply did not have enough historical information for confident classification.
The tempting response is “let the AI infer it”. The responsible response is “do not manufacture certainty the system does not possess”. Deterministic migrations handled users for whom evidence existed. Ambiguous cases stayed correctable by the user. Missing data remained missing data rather than becoming an invented profile.
That principle applies far beyond education. Imagine a property platform guessing whether a lead is an investor or owner, a logistics system guessing an entitlement, or a B2B portal guessing which contract rules apply. AI can help explain a decision. It should not silently fabricate the facts on which the decision depends.
Read the engineering record
The full Thotis IA platform re-architecture case study covers the data migration, persona model, conversational AI boundary, real-time voice path and automated quality system in detail.
Your old data is part of the product
A greenfield AI prototype starts with a clean database. A real business almost never does. It has duplicate customer records, optional fields that everyone assumed were compulsory, forms that stopped writing to the original table three integrations ago, renamed products and identifiers embedded in historical transactions.
This is why apparently simple personalisation work often becomes data engineering. In the Thotis engagement, historical agent identifiers were connected to existing chat history. Renaming those identifiers to match new branding risked damaging those relationships.
Instead, identity and presentation were separated. Old keys could remain stable while customers saw new names. This is a broadly useful pattern: do not force database history to look like the current brochure; create a translation layer between them.
For a growing Oman business, the same concern may apply to product SKUs, ERP codes, customer classifications, old Arabic and English labels, branch identifiers or legacy CRM stages.
Integrations fail at the assumptions between systems
Businesses often describe integration projects by listing vendors: CRM, WhatsApp or SMS, LLM, voice, ERP, payments and analytics. That makes integrations sound like connectors. The dangerous part is usually the assumption on each side.
A striking example from the same programme involved voice. A security-hardening change noticed that an HTTP worker URL was missing. Looking only at that function, it was reasonable to conclude that dispatch should fail without the endpoint. After the change, voice stopped working.
There was no HTTP endpoint, and there was never supposed to be one. The LiveKit agent registered directly with LiveKit and received work through its own dispatch path. What looked like missing configuration was the correct production configuration.
The lesson is to document and test the runtime sequence: who creates the session, who owns authentication, who initiates the call, who retries, where state lives, what constitutes success and what survives a retry. A diagram answering those questions is often more valuable than another connector.
Observability becomes mandatory sooner than expected
Every growing product reaches the point where something is broken in production and nobody can reproduce it locally. Developers inspect the code and find plausible defects. Those defects may be real and still fail to explain the affected customer.
The Thotis programme produced that kind of incident. An onboarding problem generated several reasonable code-level explanations. The deeper investigation found that earlier analysis had queried a diverged legacy database while the live application used another production database.
Once the correct environment was established, another limit became visible: the logs did not carry enough correlated information to reconstruct one affected user's journey. Reading more source code was no longer investigation. It was speculation. The product needed instrumentation and tracing.
Monitoring is not an enterprise luxury added after an application becomes successful. It is how you find out what the successful application is actually doing.
Do not let one AI provider become your architecture
Many prototypes are organised around whichever model or agent platform was easiest to integrate. The risk appears later. Prices change. Capabilities change. Contracts end. Data requirements tighten. A business wants to move a workload into private infrastructure. Suddenly “change the provider” means “rewrite the application”.
A healthier architecture introduces a boundary between the product and the engine underneath it. In the Thotis work, conversational routing sat behind an engine abstraction. The established agent platform could remain in service while an alternative self-hosted path was introduced selectively rather than through a high-risk, big-bang migration.
Your customer experience should belong to your product, not to your AI provider. The same principle applies to voice, storage, messaging, CRM and analytics.
Six questions to answer before scaling an AI product
- Where does truth live? Identify the authoritative source for customer identity, permissions, product data, transactions and business rules.
- What may the model decide? Write down the boundary between generative judgement and deterministic application logic.
- What happens when a provider fails? Decide whether the experience retries, degrades, queues work, switches provider or stops safely.
- Can you follow one customer's journey end to end? Correlate authentication, API requests, AI calls, background jobs and third-party integrations.
- Can the product change without rewriting history? Keep stable identifiers separate from customer-facing labels where historical records depend on them.
- Can you test the deployed experience? Unit tests are not enough when failures appear between browsers, APIs, AI providers and external services.
Oman needs AI products that survive success
Oman is treating AI as part of a wider economic and technological programme rather than as a passing software trend. That creates an opportunity for founders and established businesses: the companies that create lasting value will not necessarily be those that call the newest model first.
They will be the ones that connect AI to reliable data, understandable rules, secure infrastructure, measurable customer journeys and systems that can change as the technology changes.
That work is less glamorous than the first chatbot demo. It is also where most of the value is created. If your prototype is beginning to encounter real users, legacy records or business-critical integrations, talk to the Inzint Oman team about the engineering needed to turn it into a dependable product.
The client gave the Thotis engagement a 5.0 rating, thanked Inzint for the work delivered, and described Inzint as committed to quality, clear in communication and accountable for outcomes.