What are AI agents? A complete technical guide.

Embeddings: A way to turn text (or images, audio, code) into a fixed-length vector that captures semantic meaning. Similar concepts end up near each other in vector space.

Semantic similarity: “Cancel my subscription” and “I want to end my membership” produce nearly identical vectors, even though they share no keywords. Classic search misses this; vector search finds it.

Components: An embedding model (often the same LLM provider), a vector index (Pinecone, Weaviate, pgvector, Chroma), and a retrieval layer that ranks and filters chunks before sending them to the LLM.

In agents: Vector DBs power RAG. Whenever the agent needs to ground a response in your data, it queries the index and feeds the top-k chunks into the prompt.

A prompt is more than a question — it's a contract with the model. A production-grade prompt typically has:

• Role & context: Who the agent is and what domain it operates in.
• Rules & constraints: What it must do, must not do, and how to handle edge cases.
• Examples: Few-shot demonstrations of good behaviour.
• Tool schemas: Which functions are callable and what they expect.
• Output contract: A strict JSON schema or structured format so the rest of the system can parse the response reliably.

In production, prompts are versioned, evaluated against test sets, and swapped behind a feature flag — just like any other piece of code.

What it is: A pattern where, before calling the LLM, the system retrieves relevant context from a vector DB (or keyword index) and injects it into the prompt. The LLM answers based on fresh, specific data — not just what it memorised during training.

Why it matters: RAG lets you use the LLM over your private corpus — claims, contracts, product docs, past tickets — without fine-tuning. It's the fastest path to grounded, citable answers.

Good RAG is an engineering problem: chunking strategy, embedding model, re-ranking, hybrid search, context-window management, and eval all matter. Most “bad AI” complaints at enterprises trace back to weak RAG.

An agent without tools is just a chatbot. Tool use is what lets agents do things — create tickets, send emails, run SQL queries, fetch live data, hit internal APIs.

How it works: Tools are defined with JSON schemas. The LLM sees the schemas, decides which tool to call and with what arguments, and emits a structured tool-call. The executor runs it and feeds the result back.

Production concerns: idempotency (agents retry), permissions (some tools should require human approval), rate limits, and error handling. Every tool is a surface area that can fail.

For simple tasks, a single LLM call is enough. For real work, the agent needs to plan: break a goal into sub-steps, pick tools, evaluate results, and re-plan when something goes wrong.

Common patterns:

• ReAct: Reason → Act → Observe, repeated until done.
• Reflection: After each step, the agent critiques its own output and decides whether to retry, escalate, or continue.
• Graph-based orchestration: Define the workflow as a state machine (via LangGraph or custom code) — the agent moves along deterministic edges between autonomous nodes.

This is the layer where agents earn their name. It's also where reliability is won or lost.