My work with AI did not begin when agents became a popular label. It began with less capable models, costly context, unreliable vision and latency that could undermine an otherwise useful interaction.
I was interested in how a model could participate in a real system: receive information, interpret enough of it, call another service, store a record or continue a workflow. Calling an AI API merely to demonstrate the call was never the interesting part for me.
That question runs through my custom software work at OmniTechs, and it began before modern AI.
Before AI, I was connecting APIs
More than ten years ago, one of my early commercial websites ran on WordPress, gained visibility in Google and made sales. I wanted it to work beyond its usual web interface.
I built a Telegram bot that read its products, showed the catalogue and let people use the shop through Telegram. The implementation was simpler than my later systems, but the principle was already present: reshape one system's information for another interface and make the connection feel like one product.
That question still informs Telegram bot development.
Projects forced me beyond the backend
Mita was intended to use a smartphone's accelerometer to measure vibration and determine natural frequencies of musical instruments. The mobile app sent measurements to a server for signal processing and received the results.
I was originally responsible for the backend. The developer hired for the mobile application left partway through. I was mainly a Python developer at the time, so I learned JavaScript, React and React Native intensively and took over the mobile work.
Later work involved calling services such as DataForSEO, normalising their responses and exposing a predictable internal API. The frontend needed our representation, not the formats of several suppliers. That remains central to how I approach API integration.
Infrastructure forced another learning curve. I received a Docker configuration of roughly a thousand lines that did not work, when I barely knew Docker. I learned it, rebuilt parts and got the system running. Later I learned Angular to carry more of the application.
I also assembled a small team and attempted larger projects. That attempt failed badly. It taught me that scope, communication, architecture, testing, deployment, ownership and recovery matter alongside coding. My current boundaries for AI-generated code are explained in software development with AI.
Experiment: a document inbox
An early concept accepted photographs or scans, interpreted them with AI and classified the documents. The surrounding application decided whether to notify someone, archive the item or extract information into an index.
The useful distinction was between understanding a document and authorising the next action. AI output becomes a workflow only when software defines what may happen with it.
This was an experiment, not evidence that an autonomous document workflow is now offered as a finished product.
Experiment: translation inside a Telegram conversation
My then-girlfriend spoke Polish and little English; I spoke Persian. Ordinary translation applications made conversation slow and awkward. I built a Telegram bot that processed a Persian voice message and produced something she could receive in Polish, with a route for her reply.
Individual sentences can be ambiguous. I experimented with retrieving useful context from earlier conversations so the model could interpret the exchange more naturally. It improved our experience, while raising token cost and sometimes delay.
We used it for months. The project disappeared when the need disappeared, but the architectural lesson stayed: memory is not simply storing everything. Relevant context, cost, latency and what should remain private need decisions.
Real-time translation made latency decisive
The next concept was more ambitious: a voice or video conversation in which each participant used their own language and heard the other in theirs.
Audio needed transcription, interpretation with context, translation and generated speech, all quickly enough to feel conversational. Smaller models could reduce delay without always providing adequate quality. Parts of the project waited for the technology to improve.
Sometimes the concept is wrong, sometimes the implementation is wrong and sometimes it is too early. Waiting can be a deliberate design decision.
Experiment: AI in recruitment conversations
We also explored a workflow that searched candidate records for relevance to a vacancy, with a larger concept of an AI interviewer responding to previous answers and role information.
This was exploratory work, not a claim of validated recruitment decisions or a released hiring product. Real-time performance remained a constraint: stronger models were not necessarily fast enough, and faster ones were not always good enough. We stopped some parts rather than presenting a weak interaction as finished.
The model was rarely the whole product
These projects still needed authentication, APIs, records, permissions, state, queues, storage, search, retries, validation, diagnostic evidence, interfaces and fallback behaviour. A more capable model can improve a component while leaving those responsibilities intact.
Before polishing a finished-looking interface, I usually want to prove the uncertain connections. Can we obtain the required data? Can the systems authenticate? Does a real-time connection work? Can model output become the structure the application expects? Are latency and cost acceptable?
Proving the hard relationships first makes it easier to shape the rest into something useful.
Capabilities improved; the engineering questions remained
In my work, improvements in reasoning, vision, structured responses and speech shifted many constraints. A question that once centred on model capability increasingly became a question about placing it safely and usefully in the system. That is an observation from these projects, not a benchmark for every current model.
I see a model as another computing capability, alongside a database, search engine or deterministic algorithm. Its placement should answer concrete questions: permitted inputs and tools, what stays deterministic, uncertainty, remembered information, failures and whether the model can be replaced without rebuilding the product.
Several experiments never became commercial products. Some were early, costly or slow; some simply failed. Those experiences shaped my method. My preferred work remains proving the uncertain part, connecting the required systems and turning those connections into a product somebody can actually use.
See Sina Esfahani's background and custom software at OmniTechs for the present-day context.