```html
IRAH · TECH & AI
```html
```html
Agentic AI isn’t just another tech buzzword—it’s a fundamental shift in how machines interact with the world. But here’s the catch: most explanations treat it like a black box, dropping terms like "RAG" and "MCPs" without showing how they actually work together. That changes today. Let’s crack open the hood and examine the moving parts, using real mechanisms, sharp comparisons, and concrete examples. By the end, you’ll understand not just what these components do, but why they matter—and how they’re reshaping everything from coding assistants to enterprise automation.
This isn’t hype. It’s the architecture of the next generation of AI systems.
The Invisible Script: How Pre-Prompting Shapes an Agent’s "Personality"
Imagine handing someone a task with three sets of instructions: a job description (system prompt), your personal preferences (user rules), and a dossier of relevant files (context). That’s essentially what happens when you interact with an agentic AI. The pre-prompting stage is where the real magic—or mess—happens, depending on how well these elements are crafted.
Here’s how it breaks down under the hood:
System prompt: The agent’s "constitution." This is a set of general rules and goals hardcoded by developers. Think of it as the agent’s default personality traits—how it should behave, what tone to use, and what constraints to respect. A system prompt for a coding assistant might include: "You are a senior Python developer. Always write clean, modular code. Never suggest insecure practices."
User rules: Custom overrides. These are user-specific instructions that tweak the agent’s behavior. For example, a user might add: "Prefer functional programming patterns. Avoid classes unless absolutely necessary." This layer allows personalization without altering the core system prompt.
Context files: The agent’s "working memory." These are documents, code snippets, or datasets attached to the prompt, giving the agent relevant background. For instance, if you’re asking an agent to refactor a legacy codebase, attaching the current code files lets it analyze the actual structure rather than guessing.
Why this matters: Studies (like those from Anthropic) show that tweaking the system prompt can reduce agent errors by 5-10x. It’s not just about "prompt engineering"—it’s about designing an agent’s decision-making framework before it even sees your request. A poorly written system prompt is like giving someone vague directions ("drive north") and expecting them to arrive at a specific address. A well-crafted one is GPS with lane-level guidance.
Real-world impact: In enterprise settings, pre-prompting is how companies enforce compliance, brand voice, and security policies at scale. For example, a financial AI assistant might have a system prompt that includes: "Never disclose raw customer data. Always redact personally identifiable information (PII) before responding." This isn’t just about accuracy—it’s about alignment.
Tools: The Agent’s Hands in the Real World
LLMs are text generators, not actors. They can describe how to send an email or edit a file, but they can’t actually do those things—unless they’re equipped with tools. Tools bridge the gap between language and action, turning agents from conversationalists into operators.
Here’s how function calling works, step by step:
Tool definition: Developers provide a list of functions the agent can call, each with a name, description, and parameters. For example:
{ "name": "send_email", "description": "Send an email to a specified recipient", "parameters": { "to": "string", "subject": "string", "body": "string" } }
Agent decision: When the user asks the agent to "send an email to Alice about the quarterly report," the agent generates a structured request in JSON:
{ "function": "send_email", "parameters": { "to": "[email protected]", "subject": "Q2 2026 Report", "body": "Hi Alice,\n\nHere’s the updated quarterly report..." } }
Execution: The agent’s runtime environment receives this request, executes the actual `send_email` function (which might integrate with Gmail’s API), and returns the result (e.g., "Email sent successfully").
Response generation: The agent uses the tool’s output to craft a final response for the user, like: "I’ve sent the email to Alice. Here’s the content I used: [preview]."
Comparison: Tools are to agents what APIs are to web services. Just as an API allows a frontend to interact with a backend (e.g., fetching user data), tools allow agents to interact with external systems. The key difference? Agents decide when to call a tool based on context, rather than relying on hardcoded triggers.
Example: At IRAH, we’ve built agents that use tools to automate data pipelines. One tool fetches raw data from a database, another cleans it, and a third generates a visualization—all triggered by a single prompt like "Show me the sales trends for Q3." The agent orchestrates the workflow, calling each tool in sequence and stitching together the results.
Trade-off: Tools add capability but also complexity. Every new tool increases the agent’s "surface area" for errors. A poorly documented tool (e.g., vague parameter descriptions) can lead the agent to call it incorrectly, like trying to send an email with a malformed "to" field. This is why teams at IRAH obsess over tool design—clear descriptions, strict input validation, and fallback behaviors are non-negotiable.
MCPs: Libraries, Not Magic
Multi-Component Packs (MCPs) are the latest darling of the AI world, often hyped as "the next big thing." Here’s the truth: MCPs aren’t revolutionary. They’re libraries—collections of related tools designed for specific domains. Think of them as pre-built toolkits for common tasks.
For example:
Gmail MCP: A set of tools for email management—compose, search, label, archive.
AWS MCP: Tools for cloud operations—launch instances, monitor costs, configure S3 buckets.
Code MCP: Tools for development—read/write files, run tests, debug errors.
Key insight: MCPs don’t provide context—they provide capabilities. They’re like giving a carpenter a toolbox full of hammers, saws, and drills. The tools don’t tell the carpenter what to build, but they enable them to build anything. Similarly, an MCP for GitHub might include tools like `create_pull_request` or `comment_on_issue`, but it’s up to the agent (and the user’s prompt) to decide how to use them.
Real-world analogy: MCPs are to agents what npm packages are to JavaScript. Just as you’d install `lodash` to get a suite of utility functions, you’d import an MCP to give your agent domain-specific tools. The difference? MCPs are discoverable—agents can read the tool descriptions and learn how to use them on the fly.
Example: A startup called Cursor (not affiliated with IRAH) uses a "Code MCP" to turn their AI into a full-fledged coding assistant. The MCP includes tools like `open_file`, `edit_file`, and `run_test`, allowing the agent to autonomously refactor code, fix bugs, and even implement new features based on user prompts. This isn’t hypothetical—it’s how developers at companies like Vercel and Stripe are already working.
Misconception alert: MCPs are not a substitute for fine-tuning or RAG. They don’t teach the agent new knowledge; they give it new actions. An agent with a Gmail MCP can send emails, but it won’t know what to write unless it has context (via RAG) or domain knowledge (via fine-tuning).
RAG: The Agent’s Search Engine
Retrieval-Augmented Generation (RAG) is how agents access information that doesn’t fit into their context window. Imagine asking a colleague a question, but instead of relying on their memory, they can instantly search a massive database of documents and pull out the most relevant passages. That’s RAG in action.
Here’s how it works, broken down:
Chunking: The agent’s knowledge base (e.g., a company’s internal wiki, a codebase, or a set of PDFs) is split into small, digestible pieces called "chunks." Each chunk is typically 100-500 tokens (words/subwords) long—small enough to fit into the agent’s context window but large enough to be meaningful.
Embedding: Each chunk is converted into a numerical representation called an "embedding" using a model like `text-embedding-ada-002`. Embeddings capture the semantic meaning of the text, so similar chunks (e.g., two paragraphs about "database indexing") will have similar embeddings.
Indexing: The embeddings are stored in a vector database (e.g., Pinecone, Weaviate, or Chroma), which is optimized for fast similarity searches. This is like creating an index in the back of a book—it lets the agent quickly find the most relevant chunks for a given query.
Retrieval: When the user asks a question, the agent converts the question into an embedding and queries the vector database. The database returns the top-k most similar chunks (e.g., the 5 chunks most relevant to the question).
Generation: The retrieved chunks are added to the agent’s prompt, giving it the context it needs to generate an accurate response. For example, if you ask, "How do we handle refunds at IRAH?", the agent might retrieve chunks from the company’s policy documents and use them to craft a detailed answer.
Comparison: RAG is like a Google search for agents, but with a crucial difference: it’s private and customizable. Unlike a web search, RAG operates on your own data, whether it’s internal documentation, codebases, or customer conversations. This makes it ideal for enterprise use cases where data privacy is critical.
Example: At IRAH, we use RAG to power our internal "Ask Docs" feature, where employees can query the company’s knowledge base using natural language. Instead of digging through Confluence or Notion, they can ask, "What’s our policy on remote work?" and get an instant, accurate answer sourced from the latest HR documents. This isn’t just convenient—it’s a force multiplier for productivity.
Trade-off: RAG’s effectiveness depends on the quality of the underlying data. If your knowledge base is outdated or poorly organized, the agent’s responses will be too. This is why teams at IRAH invest heavily in data curation—regularly updating embeddings, filtering low-quality content, and optimizing chunk sizes for their specific use cases.
Embeddings & Chunking: The Unsung Heroes
Embeddings and chunking are the backbone of RAG, but they’re often treated as afterthoughts. Here’s why they deserve your attention:
Embeddings: These are numerical representations of text that capture semantic meaning. Think of them as coordinates in a high-dimensional space, where similar texts are close together. For example, the sentences "The cat sat on the mat" and "A feline rested on the rug" would have similar embeddings, even though they use different words.
Embeddings are generated by models like `text-embedding-ada-002` (OpenAI) or `sentence-transformers` (open-source). These models are trained on massive datasets to understand relationships between words, phrases, and concepts. The result? Embeddings that can capture nuance, like the difference between "apple" (the fruit) and "Apple" (the company).
Chunking: This is the process of splitting large documents into smaller pieces that fit into the agent’s context window. The goal is to balance coherence (keeping related ideas together) and granularity (making chunks small enough to be useful).
Common chunking strategies:
Fixed-size chunks: Split text into chunks of a fixed length (e.g., 200 tokens). Simple but can break up sentences or paragraphs awkwardly.
Sentence-aware chunks: Split text at sentence boundaries, ensuring each chunk is a complete thought. More coherent but can lead to variable chunk sizes.
Semantic chunks: Use embeddings to group related sentences together, even if they’re not adjacent. This is computationally expensive but yields the highest-quality chunks.
Real-world impact: The quality of embeddings and chunking directly affects the performance of RAG. Poor embeddings can lead to irrelevant chunks being retrieved, while bad chunking can result in fragmented or confusing context. For example, if a chunk cuts off mid-sentence, the agent might miss critical information.
Example: In one of our experiments at IRAH, we tested RAG performance on a dataset of technical documentation. Using fixed-size chunks, the agent struggled to answer questions about multi-step processes because key steps were split across chunks. Switching to semantic chunking improved accuracy by 30%, as the agent could now retrieve entire procedures in a single chunk.
Forward-looking: Embeddings are evolving rapidly. The latest models (like `text-embedding-3-large`) can handle longer contexts and capture more nuanced relationships. Meanwhile, chunking strategies are becoming more sophisticated, with techniques like "recursive chunking" (splitting text at multiple levels of granularity) showing promise. Expect these components to become even more critical as RAG systems scale.
Fine-Tuning: Teaching the Agent New Tricks
Fine-tuning is the process of adapting a pre-trained model to perform better on a specific task or domain. Think of it as taking a generalist (like GPT-4) and specializing it for a particular job (e.g., legal document analysis, medical diagnosis, or coding in Rust).
Here’s how it works:
Data collection: Gather a dataset of examples relevant to your task. For a coding assistant, this might include pairs of prompts and ideal responses (e.g., "Write a Python function to sort a list" → "Here’s a function using `sorted()`...").
Training: Use the dataset to fine-tune the model, adjusting its weights to minimize errors on your specific examples. This is typically done using low-rank adaptation (LoRA) or other parameter-efficient techniques to avoid catastrophic forgetting (where the model loses its general knowledge).
Evaluation: Test the fine-tuned model on a held-out set of examples to measure its performance. Metrics like accuracy, fluency, and relevance are used to gauge success.
Deployment: Deploy the fine-tuned model to production, where it can handle real-world tasks with improved accuracy and domain-specific knowledge.
Comparison: Fine-tuning is like hiring a generalist consultant and training them to become an expert in your company’s processes. They retain their general skills (e.g., problem-solving, communication) but become much more effective at the specific tasks you need.
Example: A healthcare startup might fine-tune a model on medical literature and patient records to create an AI assistant for doctors. The assistant could suggest diagnoses, recommend treatments, or summarize patient histories—all with a level of accuracy that a general-purpose model couldn’t achieve.
Trade-off: Fine-tuning requires high-quality data and computational resources. It’s not a silver bullet—poorly curated datasets can lead to biased or inaccurate models. Additionally, fine-tuned models can lose some of their general capabilities if not trained carefully. This is why teams at IRAH treat fine-tuning as an iterative process, constantly refining datasets and evaluating performance.
Real-world impact: Fine-tuning is how companies achieve "AI differentiation." While general-purpose models are commoditized, fine-tuned models can provide unique value. For example, a legal tech company might fine-tune a model on court rulings to create an AI that predicts case outcomes. This isn’t just a feature—it’s a competitive advantage.
The Big Picture: How These Components Work Together
Agentic AI isn’t about any single component—it’s about how
Follow IRAH for daily Tech & AI insights














