Four Useful Ways to Incorporate AI Into Your Business

Picking the Right Shape of AI

"We should add AI" is one of the least useful sentences in software. It is not a plan; it is a wish. The teams that ship AI features successfully are the ones that can name which kind of AI they need before they write a line of code.

In practice, almost every useful application of AI in a product falls into one of four buckets:

Vector database search — turn things into embeddings and compare them.
Retrieval-augmented generation (RAG) — give a model your data as memory.
Multi-agent systems — orchestrate specialized models around a workflow.
Training your own model — when none of the above are good enough.

They are listed in roughly increasing order of cost, complexity, and time to value. Most teams should start at the top and only descend when they have a real reason to. This article walks through each one — what it is good for, what it is bad for, and how to tell which one fits your problem.

1. Vector Database Search

The simplest and most underrated pattern. You do not even need to call this "AI" with a straight face — it is closer to a really good search index.

How It Works

You take each item in your dataset — a product, a document, a profile — and pass a description of it through an embedding model. The model returns a vector: a list of numbers that captures the meaning of the description. You store that vector in a database alongside the item.

When a user searches, you embed their query the same way and ask the database for the items whose vectors are closest. Closeness in vector space approximates closeness in meaning.

A Real Example

We use this exact pattern in the pet portal system to power product search. Each product is summarized once — its description, category, and key attributes — and that summary is embedded into a vector. Searches like "something to keep my dog calm during fireworks" land on the right products even when the literal words ("calm," "fireworks") never appear in the product copy.

What makes this powerful is that we did not have to enumerate every searchable attribute up front. There is no is_anxiety_related boolean, no noise_sensitivity tag. The vector captures all of that implicitly.

When to Use It

You have a lot of items and need to find "similar" or "relevant" ones.
The interesting axes of similarity are fuzzy or numerous.
A traditional keyword search keeps missing things that should obviously match.

When Not To

You have ten items. Use a WHERE clause.
The match criteria are exact and known. Use an index.
You need to explain why a result was returned. Vector similarity is hard to justify to a user.

This is not really an "agent." There is no reasoning, no loop, no tool use. It is a smarter way to compare things. That is exactly why it is a great place to start.

2. Retrieval-Augmented Generation (RAG)

RAG is the pattern behind most "chat with your docs" products — the company assistant that knows your handbook, the support bot that has read every help article, the legal tool that can cite the relevant clause.

How It Works

A pretrained model — GPT, Claude, Llama, whatever — does not know anything about your company. RAG fixes that by giving the model your knowledge as part of the prompt, on demand.

The flow is usually:

Chunk your documents into reasonable pieces.
Embed each chunk into a vector (yes, you are reusing pattern #1).
When a user asks a question, embed the question, retrieve the most relevant chunks, and stuff them into the prompt.
Ask the model to answer the question using only the retrieved material.

The model brings the language skills; you bring the knowledge. The two combine into something that feels like the model has read your entire wiki.

When to Use It

You have a body of documents (handbooks, tickets, contracts, code) and want users to query it conversationally.
The information changes often enough that fine-tuning a model would be a maintenance nightmare.
Citing the source of an answer matters.

When Not To

Your "knowledge" is a database. Just query the database.
You need the model to perform actions, not just answer questions. That is closer to pattern #3.
The questions require reasoning across the entire corpus at once, not pulling a few relevant pieces.

Practical Tips

Chunking is the whole game. Bad chunks make even the best model look stupid.
Always show the source. Users trust answers they can verify.
Keep the retrieval scope narrow. Pulling in twenty mediocre chunks is worse than pulling in three good ones.

3. Multi-Agent Systems

When the task is not "answer a question" but "do a job," you usually need more than a single prompt. Multi-agent systems split a workflow into specialized roles — one agent gathers information, another decides, another writes the result — and coordinate them.

I have written about this in more depth in What I Learned Building Agents for Multi-Agent Systems, so I will keep this section short.

When to Use It

The task has multiple distinct steps with different requirements.
The output of one step meaningfully informs the next.
Quality matters more than latency or cost.

When Not To

The task is one prompt away from being solved. Do not over-engineer.
Determinism matters. More agents means more variance.
You have not yet exhausted what a single well-prompted agent can do. (You probably have not.)

The trap with multi-agent systems is that they look impressive on a whiteboard and brittle in production. Start with one agent. Split it only when you have evidence that splitting helps.

4. Training Your Own Model

The heaviest option, and the one most teams should not choose. You take a base model — Meta's Llama family is the common starting point because the weights are open — and continue training it on your own data, on rented GPUs, for hours or days, until it has internalized something the base model did not know.

Chris pointed me at a subreddit a while back that walks through this end-to-end: rent a few H100s by the hour, prepare a dataset, run the training loop, evaluate, repeat. It is genuinely accessible now in a way it was not even two years ago.

When to Use It

You have proprietary data that gives you a real edge — not a few thousand examples, but enough to actually shift the model's behavior.
Latency or cost at scale makes calling a frontier model untenable.
You need the model to run somewhere a frontier API cannot reach (on-device, air-gapped, regulated).
RAG and prompting have genuinely been tried and are not enough.

When Not To

You have not first tried RAG. Almost every "we need to train a model" turns into "actually RAG was fine."
Your dataset is small. Fine-tuning small models on small data tends to make them worse, not better.
The base models keep getting cheaper and better — what you train today may be obsolete in six months.

Training is the most exciting option and the one with the worst ratio of effort to outcome for most teams. The bar for picking it should be high.

Choosing Between Them

A rough decision tree that has held up for me:

Need to find relevant things? Vector search.
Need to answer questions about your data? RAG.
Need to perform a multi-step task? Multi-agent.
All three are inadequate and you have the data to prove it? Train.

The mistake I see most often is teams jumping straight to step three or four when step one would have solved the problem. The other mistake is staying at step one when the user is clearly asking for something more.

Pattern	Cost	Time to Value	Best For
Vector search	Low	Days	Discovery, recommendations, fuzzy matching
RAG	Low–Mid	Weeks	Q&A over your data, internal assistants
Multi-agent	Mid–High	Weeks–Months	Workflows, automation, judgment-heavy tasks
Training	High	Months	Proprietary edge, edge deployment, scale

Conclusion

"AI" is not a feature. It is a category that contains at least four meaningfully different tools, each with its own cost curve and failure modes. Picking the right one is the most important decision you make before any code gets written.

Start with the smallest pattern that could plausibly work. Vector search will surprise you with how far it goes. RAG will surprise you with how rarely you need anything more. Multi-agent systems and custom training are powerful, but they are also where most AI projects quietly die — usually because they were chosen before the simpler options were honestly tried.

The discipline is not in knowing every technique. It is in knowing which one your problem actually needs.