Agents, workflows, RAG, or fine-tuning

The first AI architecture decision is often a vocabulary problem. Teams use "agent" to mean a chatbot, a tool-calling loop, a workflow engine, a background job, or a model with a large prompt. Those systems fail in different ways.

Before a team chooses an architecture, it should name the job the AI system owns.

Use a workflow when the business process has known steps

Many AI features are workflows with one or two model calls. A lead triage system might extract fields from an email, match the company against CRM data, score fit, and write a summary for sales. The order is known. The data sources are known. The team needs retries, logs, and clear ownership.

That is workflow territory. The model handles language judgment inside bounded steps. The application owns state, permissions, retries, and review.

Use RAG when the answer must come from owned material

Retrieval-augmented generation fits questions where the answer should be grounded in documents, tickets, policies, source code, or product data the company controls. The core design question is not "which vector database." It is "which record is allowed to answer this question."

A good RAG design includes document ownership, permissions, chunking rules, refresh timing, search evaluation, cited source records, and logs that show which records entered the prompt.

Without those details, RAG becomes search with a confident writing style.

Use fine-tuning when behavior repeats and examples are available

Fine-tuning is useful when the team has a repeated behavior it can describe with examples: classification, formatting, extraction, tone, routing, or domain-specific shorthand. It is a poor substitute for missing product rules or missing data access.

The test is simple: if a staff member cannot produce accepted examples, the team probably is not ready to fine-tune.

Use agents when the system must choose tools

An agent makes sense when the system needs to inspect state, choose from several tools, and adapt its path based on intermediate results. That power creates a testing problem. The team now needs tool permissions, execution limits, traces, timeouts, idempotency rules, and a way to replay failed runs.

An agent without those controls is not a junior employee. It is a production process with loose permissions.

The right architecture is the one whose failure mode the team is prepared to operate.