Can you add AI to an existing product?

That is the usual shape of this work. The codebase already exists, it already has users, and the AI feature has to arrive without destabilising what those users depend on. We integrate into what is there rather than proposing a parallel system nobody asked for.

Which model provider do you use?

Whichever fits the constraint that actually binds — accuracy, latency, cost, or where the data is allowed to go. Endpoints stay behind one interface so the decision remains reversible. A provider you cannot leave is a dependency, not a choice.

How do you know the AI feature actually works?

It is measured. Accuracy, latency and cost are instrumented per release and compared against the previous one. Without that, an AI feature is judged on the demo that convinced someone to build it, which is the one condition it will never face again.

AI Integration & LLM Development

AI features that survive contact with production.

We add AI to products that already work. That means model integration wired into a codebase somebody is already depending on — prompt and tool-calling pipelines, endpoints kept behind one swappable interface, and evaluation that tells you whether the feature got better or only got newer. The interesting part of an AI feature is rarely the model. It is everything around it.

What this includes

LLM and agent integration

Prompt and tool-calling pipelines built into the product you already have, with model endpoints behind a single interface so that changing provider is a configuration change rather than a rewrite.

Evaluation and telemetry

Accuracy, latency and cost measured per release instead of judged by demo. A model that answers well on the day you shipped it is not the same model three months later, and without instrumentation you find that out from your users.

AI inside developer tooling

Agent-assisted workflows in the tools a team already has open — the work we do at Microsoft on the AI for Science initiative, building agent tooling inside a Visual Studio Code–based research environment used by scientific and machine learning teams.

Guardrails and accessible interfaces

Rate limiting, input validation, honest failure states, and interfaces that meet WCAG 2.1 AA. An AI feature is still a feature: it has to fail politely and be usable by keyboard and screen reader like everything else on the page.

Numbers

9+years of production engineering behind every AI integration
AAWCAG 2.1 conformance level the agent tooling ships to
0provider lock-in — model endpoints sit behind one swappable interface

Evidence

The current engagement is Microsoft’s AI for Science initiative, as a vendor engineer through Akvelon: integrating and deploying production AI and LLM models into a Visual Studio Code–based research environment, wiring model endpoints through Azure AI services, and instrumenting the evaluation and telemetry that judge them — alongside the accessibility and test-coverage work that decides whether any of it is shippable.

Tech stackTypeScript · Node.js · Python · Azure AI · Large Language Models · AI Agents · Docker · GitHub Actions

Common questions

Can you add AI to an existing product?: That is the usual shape of this work. The codebase already exists, it already has users, and the AI feature has to arrive without destabilising what those users depend on. We integrate into what is there rather than proposing a parallel system nobody asked for.
Which model provider do you use?: Whichever fits the constraint that actually binds — accuracy, latency, cost, or where the data is allowed to go. Endpoints stay behind one interface so the decision remains reversible. A provider you cannot leave is a dependency, not a choice.
How do you know the AI feature actually works?: It is measured. Accuracy, latency and cost are instrumented per release and compared against the previous one. Without that, an AI feature is judged on the demo that convinced someone to build it, which is the one condition it will never face again.