Add AI to the product you already have without rebuilding everything around an LLM.

The short answer

AI should remain one component of the application.

The model may classify, extract, summarize, retrieve, recommend, or request a tool. The existing system should continue to own identity, permissions, business rules, transactions, source data, and auditability.

Useful patterns

Choose a bounded task with a clear user benefit.

Architecture decisions

Design the controls around probabilistic behavior.

Define context boundaries and access control before retrieval. Keep deterministic logic outside the model. Restrict tool execution, evaluate representative tasks and failures, make fallback behavior explicit, capture traces and operational signals, and avoid unnecessary dependence on one provider.

Deterministic boundaries

Know when not to use AI.

Do not use a model when rules can be stated completely, repeatability is mandatory, errors carry serious consequences, or a conventional query solves the problem. Do not ship the feature if the organization cannot evaluate its behavior or if its only purpose is to add an AI label.

Local, cloud, or hybrid

Choose deployment from operating constraints, not ideology.

Managed APIs, private-cloud models, local inference, and hybrid designs make different tradeoffs. I compare data sensitivity, model quality, latency, throughput, cost, and the team's capacity to operate the stack.

How I approach the work

Integrate the feature as part of the product.

The delivery path can cover use-case analysis, architecture, RAG, tool calling, APIs, authentication, frontend experience, deterministic business logic, evaluation, observability, deployment, documentation, and handover.

Relevant proof

Different systems prove different parts of the integration problem.

These demonstrate distinct parts of integrating probabilistic model behavior into controlled software. They are not presented as equivalent client deployments.