Building Better AI Agent Skills: 8 Best Practices

 AI Agent Skills are becoming more than a SKILL.md file of instructions.

The focus is shifting toward efficient context management, clear execution workflows, controlled autonomy, and built-in validation.

A good skill should not just tell an agent what to do.

It should help the agent:

• load the right context

• follow a repeatable workflow

• use deterministic tools where precision matters

• verify the result before finishing

Here are eight practices that make skills more reliable and reusable.

---

1. Write the Description as a Trigger

Before an agent reads a single line of SKILL.md, it sees the skill's name and description.

That metadata answers one important question:

Is this skill relevant to the current request?

If the description does not match how users actually phrase their requests, the skill may never be selected, no matter how good the implementation is.

A weak description simply says what the skill is about:

Name: cluster-status

Description:
Checks application deployment and workload
status across configured environments.

A stronger description explains:

• what the skill does

• when to use it

• the kinds of user requests it should match

• what it will not do

For example:

Name: cluster-status

Description:
Live, read-only state of the application namespace
on configured clusters — deployments, pods, jobs,
problems, and which image version runs where.

Use when asked:
"are pods up",
"what's deployed where",
"did my rollout finish",
"is anything crashlooping",
or after a deploy to confirm it landed.

Never restarts or edits anything.

The description is not just documentation.

It is part of the routing logic.

The description decides whether the skill is used at all. Write it for matching, not for documentation.

---

2. Keep SKILL.md Lean and Disclose Progressively

Avoid turning SKILL.md into a large instruction manual.

It should contain only what is needed to execute the skill:

• purpose

• workflow

• important constraints

• links to deeper material

• scripts or tools it may use

Move detailed specifications, examples, schemas, and long documentation into separate reference files.

Think of skill context in layers:

Metadata
"Should I use this skill?"
        ↓
SKILL.md
"How should I execute it?"
        ↓
References / Scripts
"Do I need deeper knowledge or deterministic execution?"

More specifically:

Metadata     → always available
SKILL.md     → loaded when the skill is selected
References   → read only when needed
Scripts      → run only when needed

References and scripts are loaded independently, only when the current task needs them.

For example:

references/
├── environments.md
├── api-specification.md
├── validation-rules.md
└── examples.md

The agent may need environments.md for one task and never need api-specification.md.

There is no reason to load both upfront.

Reference files should also be easy to navigate:

• descriptive filenames

• clear headings

• table of contents for larger files

• direct links from SKILL.md

Avoid deeply nested chains such as:

SKILL.md → reference-a.md → reference-b.md → reference-c.md

Every additional hop adds more reading before the agent can act.

Give the agent the right information at the right time.

---

3. Let Scripts Do the Deterministic Work

Some steps do not need model reasoning at all.

For example:

scripts/
├── check_status.py
├── validate_output.py
└── compare_versions.py

Instead of asking the model to reconstruct these operations every time, let code perform them.

Scripts help in two ways.

First, they are precise:

The same input follows the same execution path.

Second, they are cheap in context:

The agent can run a script and read only its output. The full script does not need to occupy the model's active context.

That makes scripts part of progressive disclosure as well as a reliability mechanism.

If a step can be written as code, it shouldn't be regenerated by the model on every run.

---

4. Match Agent Freedom to Risk

Not every task needs the same level of autonomy.

Freedom	Best suited for
High	Brainstorming, writing, summarization
Medium	Analysis, reports, code reviews
Low	Database operations, calculations, sensitive workflows

A writing skill can allow broad freedom.

A database migration skill should be much more constrained.

Ways to reduce freedom include:

• exact commands instead of vague instructions

• bundled scripts instead of reconstructed steps

• explicit "never do X" rules

• confirmation before irreversible actions

Use AI for reasoning. Use deterministic tools for precision.

The more expensive or risky a mistake is, the less freedom the workflow should allow.

---

5. Define Explicit Workflows

For multi-step tasks, make the expected sequence clear.

For example:

Understand Request
      ↓
Load Relevant Context
      ↓
Execute
      ↓
Validate
      ↓
Fix if Needed
      ↓
Return Result

A checklist works well too:

- [ ] Understand the request
- [ ] Load required references
- [ ] Execute the workflow
- [ ] Validate the output
- [ ] Fix errors if necessary
- [ ] Return the final result

Explicit workflows reduce skipped steps, inconsistent execution, and premature completion.

---

6. Build Self-Validation Into the Skill

Generating an output is only half the job.

A skill should also define how to verify that output.

Whenever possible, use deterministic evidence instead of asking the model to decide whether its own answer looks correct.

Validation can include:

• schema checks

• unit tests

• formatting validators

• deterministic scripts

• API validation

• database checks

A strong pattern is:

Generate
   ↓
Validate ──pass──→ Done
   ↓ fail
Fix
   ↓
Revalidate

That loop should also be bounded.

If validation keeps failing, the skill should eventually stop and report the problem instead of looping indefinitely.

A good skill knows how to perform the task and how to prove it succeeded.

---

7. Evaluate Skills Like Code

A skill that has never been tested only works by luck.

Start with realistic evaluation cases:

• Trigger tests — prompts that should select the skill, and near-misses that should not

• Output checks — what a correct result should look like

• Observed failures — real failures turned into new test cases

Then run the same cases across the models you support.

Differences between models often expose:

• ambiguous instructions

• hidden assumptions

• unclear tool-selection rules

• inconsistent execution paths

The skill should provide the structure. The model should provide the reasoning.

A well-designed skill should not depend entirely on the strongest model compensating for weak workflow design.

---

8. Document Dependencies

Skills often depend on more than instructions.

They may require:

• runtime versions

• packages

• command-line tools

• APIs

• authentication

• environment variables

• external services

Document them clearly.

For example:

Runtime: Python 3.12
Dependencies: boto3, requests
Inputs: environment, application
Output: structured JSON

Also consider what the target environment actually supports.

A skill that works locally may fail in a sandboxed runtime with no network access or package installation.

A reusable skill should also be reproducible.

---

What Does a Well-Structured Skill Look Like?

my-skill/
├── SKILL.md
├── references/
│   ├── specifications.md
│   ├── examples.md
│   └── validation-rules.md
├── scripts/
│   ├── execute.py
│   └── validate.py
├── evals/
│   └── cases.json
└── requirements.txt

Each part has a clear responsibility:

Description   → when should this skill be used?
SKILL.md      → how should the task be performed?
References    → what deeper knowledge is needed?
Scripts       → what can execute deterministically?
Validation    → how do we know it worked?
Evals         → does the skill keep working?
Dependencies  → what does the skill need to run?

---

Final Thought

The biggest shift in Agent Skills is moving from:

writing better prompts

to:

engineering better workflows

Good skills do not put everything into context and hope the model figures it out.

They give the agent:

• the right context at the right time

• the right amount of autonomy

• deterministic help where precision matters

• a clear execution path

• a reliable way to verify the result

The future of Agent Skills is not bigger SKILL.md files. It's smarter context management, clearer workflows, controlled autonomy, and verifiable execution.

🤖Organizing a Project for Coding Agents

Instructions Explain, Scripts Execute, Tests Prove

Coding agents can read a lot of code.

That usually isn't the hard part.

The harder part is everything an experienced engineer already knows but the repository doesn't clearly say. Organizing a project for coding agents is really about putting that knowledge in the right place.

A simple principle helps:

Instructions explain. Skills guide. Scripts execute. Tests prove.

---

🏗️ An Application Is Often Many Repositories

A modern application is rarely one repository.

It may be split across several:

app                → application code and build pipeline
database           → schema, migrations, seed data
app-infra          → cloud resources, IAM, DNS, search
cluster-infra      → Kubernetes clusters and shared services
deploy-manifests   → environment-specific deployment configuration

An agent looking at only one repository cannot infer that entire relationship.

That is the first thing we should make explicit:

What repositories make up the application, and what does each one own?

That gives the agent a map before it starts navigating.

---

🧠 Instructions Explain What the Code Cannot

Instruction files such as AGENTS.md or CLAUDE.md should contain information the agent cannot reliably discover from source code alone.

For example:

• Repository relationships

• Architecture boundaries

• How environments are organized

• How tests should be run

• Important operational constraints

• Critical guardrails

The goal is not to document the entire repository.

The agent can already read the repository.

A good rule is:

If the agent can reliably discover something from the code, don't repeat it in the instructions.

Keep instructions short and focused.

Long instruction files consume context and make the important rules harder to notice.

---

🧩 Skills Guide Repeatable Procedures

Some engineering tasks follow the same process again and again.

For example:

• Check deployment status

• Investigate an incident

• Compare environments

• Validate a release

• Inspect a scheduled job

Instead of expecting the agent to rediscover the procedure every time, package it as a skill.

Conceptually:

User Question
      ↓
Relevant Skill
      ↓
Known Procedure
      ↓
Tools / Scripts
      ↓
Result

A skill should tell the agent:

• When to use it

• What procedure to follow

• Which tools or scripts to run

• How to interpret the result

The advantage is that specialized instructions only need to load when they are relevant.

The main agent instructions stay small.

---

⚙️ Scripts Execute Deterministic Work

Suppose the procedure is:

Get deployments
Check pods
Check scheduled jobs
Compare versions
Identify failures

An agent could construct those commands every time.

But why make it reason through something deterministic?

Instead:

Agent
   ↓
Run Script
   ↓
Collect State
   ↓
Structured Result
   ↓
Agent Interprets Result

The script handles the repeatable mechanics.

The agent handles judgment.

This distinction is important:

Every step the agent doesn't have to reason through is one less step it can get wrong.

Use the model where reasoning adds value.

Use scripts where consistency matters more.

---

🛡️ Move Critical Guardrails Below the Prompt

Instructions are useful, but they are still guidance.

Consider a rule like:

Production cluster access is read-only.

You can put that in AGENTS.md.

But if the rule must always hold, don't rely on the model remembering it.

Move the constraint into deterministic controls:

Instruction
    ↓
Hook
    ↓
Permissions

For example:

• The instruction says access is read-only

• A hook blocks unsafe commands

• Cluster permissions prevent writes entirely

The deeper the control is enforced, the less the agent has to remember.

An instruction is a request. A policy or permission is a guarantee.

---

✅ Tests Prove the Work

A coding agent shouldn't stop because a change looks correct.

It should have a way to verify the result.

Without validation:

Change Code
    ↓
Looks Correct
    ↓
Stop

With validation:

Change Code
    ↓
Run Test
    ↓
Failure?
    ↓
Fix
    ↓
Run Again

Tests give the agent evidence.

That changes the role of the human.

Instead of being the verification loop, the human becomes the reviewer of a result that has already been checked.

The same idea applies to agent tooling itself.

Skills, scripts, hooks, and configuration should also be validated like production code.

---

🔄 Let Skills Improve Through Use

Skills shouldn't be treated as finished artifacts.

The most useful improvements often come from real usage.

You may discover that:

• The output is too verbose

• A status is ambiguous

• One workflow takes too long

• A special case needs a shortcut

• An important field is missing

Capture those learnings.

Then update the skill or script.

Use
 ↓
Observe
 ↓
Learn
 ↓
Improve
 ↓
Next Run Gets Better

Over time, operational knowledge moves out of people's heads and into reusable automation.

---

📚 Documentation Is Still for Humans

Agents need instructions, skills, scripts, and tests.

Humans still need architecture documentation.

A short README or architecture document should explain:

• What the major components are

• How they connect

• Where they run

• Which repositories own which responsibilities

The agent can be pointed to that documentation when needed.

There is no reason to copy all of it into the permanent instruction context.

---

🧭 Where Things Belong

A simple mental model:

Need	Put It Here
How do repositories relate?	Instructions
What should the agent know?	Instructions
What repeatable process should it follow?	Skill
What can execute deterministically?	Script / Tool
What must always be enforced?	Hook / Permission
How do we know it worked?	Test
How does the procedure improve?	Learnings
What helps humans understand the system?	Documentation
What is the implementation truth?	Source code

The general direction should be:

Move work toward the most deterministic layer possible.

If guidance can become a script, make it a script.

If a rule can become a permission, enforce it.

If an outcome can be tested, test it.

---

🎯 Final Thought

Making coding agents more effective isn't only about better models or larger context windows.

It's also about designing the engineering environment so the agent has less to infer, less to remember, and less to invent.

A well-organized project gives the agent:

• A map of the repositories

• Clear instructions

• Reusable skills

• Deterministic scripts

• Enforced guardrails

• Tests that prove the result

Instructions explain. Skills guide. Scripts execute. Tests prove.

The goal isn't to make the agent remember everything.

It's to organize the project so it knows where to look, what to run, what it is allowed to do, and how to prove the work is complete.

🧠 Context Offloading Isn't Always a Cost Optimization

 Many modern agent frameworks support automatic context offloading.

The idea is simple.

Instead of keeping large tool responses inside the model's context, the framework stores them externally, leaves behind a small preview, and retrieves the original only if the model needs it later.

On paper, it sounds like an obvious optimization.

Smaller prompts should mean lower token usage and lower cost.

I measured it on one of my production agents.

The result surprised me.

Token usage increased by 68%.

The interesting part wasn't the number.

It was why.

---

🤔 How Context Offloading Works

Imagine an agent receives a large tool response.

Without offloading:

Tool
   ↓
Large Result
   ↓
LLM

The entire payload remains in the model's context.

With offloading:

Tool
    ↓
Large Result
    ↓
Store externally
    ↓
Preview in context
    ↓
Retrieve only if needed

The expectation is simple:

• Smaller prompts
• Lower token usage
• Longer conversations

---

📊 What I Measured

I evaluated multiple context-management strategies against the same workload.

The baseline simply used a sliding context window.

Automatic offloading enabled the framework's built-in context manager.

Strategy	Model Calls	Input Tokens	Quality
Baseline	7	227K	9/9
Automatic Offloading	14	382K	8/9

Instead of reducing cost, offloading:

• increased model calls
• increased total token usage
• slightly reduced answer quality

---

🧩 The Hidden Cost

The reason became obvious after looking at the traces.

The framework successfully reduced the size of individual prompts.

But every time the model needed information that had been offloaded, it performed another retrieval.

That meant another model invocation.

The flow looked like this:

Tool
    ↓
Large Result
    ↓
Offload
    ↓
Preview
    ↓
Model requests original
    ↓
Retrieve
    ↓
Another model call

The content wasn't removed.

It simply came back later.

You paid for:

• the preview
• the retrieval
• another model call
• the conversation history again

The content was effectively processed twice.

---

📉 Compression Worked

One result initially confused me.

The average prompt actually became smaller.

Per-call context was reduced by roughly 16%.

So why did total cost increase?

Because billing depends on total tokens processed, not the size of an individual prompt.

Reducing the size of each request didn't help when the framework created many more requests.

In my case:

Smaller prompts
        +
More model calls
        =
More total tokens

The compression worked.

The retrieval round trips outweighed the savings.

---

📏 Context Window Matters

The most important number turned out not to be token usage.

It was context utilization.

My model supports a 1 million token context window.

The baseline execution peaked at approximately 55,000 tokens.

That's roughly 5.5% of the available context.

I had enabled a feature designed to prevent context overflow.

The problem was...

I was nowhere near overflowing.

I was paying the cost of protection against a problem that didn't exist.

---

✅ When Context Offloading Makes Sense

Context offloading isn't a bad feature.

It's solving a different problem.

It works well when:

• Long-running conversations
• Small context windows
• Very large tool responses
• Information that is unlikely to be referenced again

Those are situations where preventing context growth is more important than minimizing model calls.

---

❌ When It Doesn't

Be cautious when:

• The conversation easily fits inside the context window
• Tool responses are immediately reused
• Every reasoning step depends on previous tool output

In these cases, offloading often creates additional retrievals without providing meaningful savings.

---

🎯 Final Thought

Context offloading isn't primarily a cost optimization.

It's a context management strategy.

If your agent is approaching the context window, it can prevent important information from being discarded.

If your agent is nowhere near that limit, it may simply replace larger prompts with more model calls.

The lesson isn't:

Always enable context offloading.

It's:

Measure first. Optimize only for the bottleneck you actually have.

🔥 Hot, Warm, and Cold: Reducing Vector Search Costs with Tiered Storage

In previous articles, we looked at retrieval strategies and knowledge base architectures.

One assumption quietly made throughout was that every embedding lives in the same vector index.

That works well for small datasets.

At hundreds of millions of vectors, it becomes expensive.

The reason isn't the embeddings.

It's the index.

---

💰 The Real Cost of Vector Search

Unlike relational databases, vector search doesn't scan every embedding.

Instead, it traverses an Approximate Nearest Neighbor (ANN) index to quickly find similar vectors.

To achieve low-latency search, that ANN index is typically kept in memory.

As the corpus grows, so does the amount of memory—and infrastructure—needed to keep that index available.

The important observation is this:

Not every vector is queried equally.

---

📈 Most Corpora Follow a Long Tail

Think about any corpus with a time dimension:

• Support tickets

• Meeting notes

• Product documentation

• Incident reports

• Contracts

Recent information is queried constantly.

Older information is still valuable—but much less frequently.

A typical access pattern looks like this:

10% of documents
        ↓
90% of queries

90% of documents
        ↓
10% of queries

Yet many systems keep 100% of the vectors in the fastest—and most expensive—infrastructure.

---

🔥 Hot, 🌤️ Warm, ❄️ Cold

The idea is the same one object storage has used for years.

Not every document needs the same retrieval speed.

🔥 Hot Tier

Frequently accessed vectors.

Examples:

• OpenSearch k-NN

• pgvector (HNSW)

• Pinecone

• Weaviate

Characteristics:

• ANN index kept in memory

• Lowest latency

• Highest infrastructure cost

Typical data:

• Recent documents

• Frequently queried content

---

🌤️ Warm Tier

Occasionally accessed vectors.

The vectors live in low-cost object storage but are loaded into memory on demand and cached for subsequent searches.

Examples:

• Cached JSONL or Parquet embeddings in S3

• Amazon S3 Vectors

• Other managed vector services

Typical flow:

First Query

S3
   ↓
Load vectors
   ↓
Cache in memory
   ↓
Similarity search

Subsequent Queries

Memory
   ↓
Similarity search

Compared to the hot tier:

• No always-running ANN index

• Lower infrastructure cost

• Slightly higher latency

• Good for infrequently accessed data

---

❄️ Cold Tier

Rarely accessed vectors.

Vectors remain in object storage and are only read when a query requires them.

Typical flow:

User Query
      ↓
Read vectors from object storage
      ↓
Exact similarity search
      ↓
Return Top-K

Characteristics:

• No ANN index

• No persistent memory

• Lowest storage cost

• Highest latency

Cold storage is ideal for historical archives where occasional slower queries are acceptable.

---

🏗️ Hide the Complexity

The biggest mistake is exposing storage tiers to application code.

Instead of writing:

if document_is_hot:
    search_hot()
elif document_is_warm:
    search_warm()
else:
    search_archive()

Applications should simply ask:

Search documents

The retrieval layer decides which storage tier to query.

This keeps applications independent of storage decisions while allowing the storage architecture to evolve over time.

---

📉 Where the Savings Come From

Many people assume tiering reduces storage cost.

That's only part of the story.

The real savings come from reducing:

• Memory-resident ANN indexes

• Compute

• Always-on infrastructure

The fewer vectors you keep in expensive memory, the smaller your always-running infrastructure becomes.

Tiering isn't about storing vectors more cheaply.

It's about keeping only the right vectors in expensive infrastructure.

---

🤖 Intelligent Routing

As storage tiers grow, deciding where to search becomes another retrieval problem.

Simple rules such as document age often work.

Increasingly, AI agents can route queries based on user intent.

For example:

• "Show the latest incident." → Hot

• "Summarize the original agreement." → Cold

• "How has this evolved over time?" → Multiple tiers

Applications continue to issue a single retrieval request.

The retrieval layer decides which storage tier—or combination of tiers—to search.

---

📋 When Tiering Makes Sense

Tiering is valuable when:

• Very large vector collections

• Strongly skewed access patterns

• Historical data is queried infrequently

• Different latency requirements are acceptable

It adds little value when:

• Datasets are relatively small

• Access patterns are uniform

• Every query requires consistently low latency

As with most optimizations, measure your access patterns before introducing additional architectural complexity.

---

🎯 Final Thought

The biggest cost in vector search isn't storing embeddings.

It's maintaining large, memory-resident ANN indexes.

Just as object storage evolved into Standard, Infrequent Access, and Archive tiers, vector storage is beginning to follow a similar path.

The goal isn't to store vectors more cheaply.

It's to keep only the vectors that require low-latency access in your fastest—and most expensive—infrastructure, while allowing the long tail to move to lower-cost storage without changing how applications retrieve information.

Deep Dive into a Strands Agent Trace

When working with AI agents, one of the most useful ways to understand what is happening behind the scenes is through tracing.

A seemingly simple user request can result in multiple model invocations, tool executions, and event-loop cycles before the agent produces its final response.

In this post, I'll walk through a simple Strands Agent example:

greet rahul using tool

---

🧠 What Actually Happens?

The resulting trace looks roughly like this:

agent.run
|
+-- invoke_agent
    |
    +-- execute_event_loop_cycle #1
    |   |
    |   +-- chat #1
    |   |
    |   +-- execute_tool greet
    |
    +-- execute_event_loop_cycle #2
        |
        +-- chat #2

Although the user made only one request, the agent performed:

• Two event-loop cycles

• Two model calls

• One tool execution

The obvious question is:

Why is a second model call needed?

---

⚙️ Event-Loop Cycle #1: Decide and Act

The first chat span represents a model invocation.

The model receives:

• The user prompt

• Conversation history

• Available tools

It decides that the appropriate action is:

greet(name="rahul")

Strands then executes the tool.

chat #1
      |
      | decides to call
      v
execute_tool greet
      |
      v
"Hello, Rahul"

At this point the tool has completed.

But the agent has not.

---

🧩 Why Another Model Call?

Tools execute code.

They don't decide what should be shown to the user.

Once the tool returns its result, the model must reason over that result and determine:

• Is another tool required?

• Is the task complete?

• What should the final response be?

That requires another model invocation.

---

⚙️ Event-Loop Cycle #2: Observe and Respond

The updated context now contains:

User:
greet rahul using tool

Assistant:
toolUse -> greet("rahul")

Tool:
toolResult -> "Hello, Rahul"

The agent enters another event-loop cycle:

execute_event_loop_cycle #2
        |
        +-- chat #2
               |
               v
         Final Response

The model observes the tool result, determines that no further actions are required, and generates the final response.

The complete execution becomes:

User Prompt
      |
      v
Cycle #1
      |
      +-- Model decides
      |
      +-- Tool executes
      |
      v
Tool Result
      |
      v
Cycle #2
      |
      +-- Model reasons over result
      |
      v
Final Response

Notice that the first model call decides what to do.

The second model call decides what to say.

---

🧠 Why This Looks Like ReAct

This execution naturally follows the ReAct pattern:

Reason
   |
   v
Act
   |
   v
Observe
   |
   v
Reason
   |
   v
Answer

For our example:

Reason  → Decide to call greet()
Act     → Execute greet()
Observe → Receive "Hello, Rahul"
Reason  → Determine no further actions are required
Answer  → Return final response

ReAct describes how an agent behaves.

OpenTelemetry describes how that behavior is observed.

For example:

Agent Execution              OpenTelemetry Representation

Model invocation       →     chat span
Tool execution         →     execute_tool span
Tool result            →     span output / attributes
Next model invocation  →     next chat span
Agent invocation       →     trace containing these spans

A ReAct iteration is therefore a logical agent concept—not an OpenTelemetry primitive.

---

📂 Where Does a Session Fit?

A session can contain multiple user interactions.

Each interaction creates a new trace.

Session
|
+-- Prompt #1
|     +-- Trace #1
|
+-- Prompt #2
|     +-- Trace #2
|
+-- Prompt #3
      +-- Trace #3

Within each trace, the agent may execute multiple event-loop cycles.

Session
     |
     | 1:N
     v
Trace
     |
     | 1:N
     v
Event-Loop Cycles
     |
     | captured as
     v
Spans

The exact relationship between sessions and traces depends on the application's instrumentation, but this is a useful mental model.

---

🧩 Two Views of the Same Execution

When debugging an agent, think about two different perspectives.

Execution

Event Loop
     |
     +-- Reason
     +-- Act
     +-- Observe
     +-- Repeat

This explains how the agent works.

---

Observability

Trace
   |
   +-- Span
   +-- Span
   +-- Span

This explains what happened while the agent was working.

---

🎯 Final Thought

For our simple example:

One User Request
      |
      v
One Agent Execution / Trace
      |
      +-- Event-Loop Cycle #1
      |      +-- chat
      |      +-- execute_tool
      |
      +-- Event-Loop Cycle #2
             +-- chat
      |
      v
Final Response

Understanding this distinction makes agent traces much easier to read.

The event loop explains how the agent reasons.

The trace records that reasoning as observable spans.

OpenTelemetry doesn't change how the agent works.

It simply makes that work visible—making it easier to debug behavior, optimize execution, analyze tool usage, and evaluate agent performance.

🏗️ When a Managed Knowledge Base Isn't Enough

In the previous article, we looked at how a knowledge base works—from connectors and indexing to retrieval and generation.

The next question is usually:

Should I use a managed knowledge base or build my own?

For most projects, the answer is simple:

Start with a managed service.

Custom architectures only become worthwhile when your requirements exceed what managed knowledge bases were designed to solve.

---

☁️ Why Managed Knowledge Bases Exist

Managed knowledge bases package the entire retrieval pipeline into a single service.

They typically provide:

• Connectors
• Document ingestion
• Chunking
• Embedding generation
• Indexes
• Retrieval
• Synchronization

You configure the pipeline.

The platform operates it.

For many RAG applications, that's exactly what you need.

Typical use cases include:

• Internal documentation
• Product manuals
• Customer support
• Enterprise search
• AI assistants

---

🔧 When Managed Starts to Break Down

Managed services are intentionally opinionated.

They optimize for common retrieval problems.

Eventually, some teams discover that retrieval isn't their biggest challenge anymore.

The challenge becomes everything that happens before retrieval.

For example:

• Custom chunking strategies
• Rich metadata extraction
• External data enrichment
• Specialized embedding models
• Multiple indexing pipelines
• Custom ranking logic

These requirements often don't fit naturally into a managed pipeline.

---

🚀 When Custom Makes Sense

Building your own knowledge base gives you complete control over every stage of the pipeline.

You can customize:

• Connectors
• Ingestion
• Chunking
• Metadata extraction
• Enrichment
• Embedding generation
• Retrieval

That flexibility comes at a cost.

You now own:

• Infrastructure
• Scaling
• Monitoring
• Synchronization
• Upgrades
• Operational support

The question isn't whether you can build it.

The question is whether you need to.

---

📋 Decision Guide

Requirement	Managed	Custom
Standard document search	✅
Built-in connectors	✅
Semantic search	✅
Basic metadata filtering	✅
Low operational overhead	✅
Custom chunking		✅
Rich metadata extraction		✅
External data enrichment		✅
Multiple indexing pipelines		✅
Specialized retrieval or ranking		✅
Full control over the pipeline		✅

---

⚠️ Don't Build Custom Too Early

One of the biggest misconceptions is that a vector database is a knowledge base.

It isn't.

The real complexity isn't storing vectors.

It's everything around them:

• ingestion
• synchronization
• metadata management
• enrichment
• indexing
• retrieval

Building those components yourself is a long-term engineering commitment.

---

🎯 Final Thought

Managed knowledge bases solve the infrastructure problem.

Custom knowledge bases solve specialized business problems.

Start with a managed knowledge base whenever possible.

Move to a custom architecture only when your requirements clearly exceed what managed services were designed to support.

In the next article, we'll look at one of the biggest reasons teams outgrow managed knowledge bases:

The real challenge isn't retrieval—it's the ingestion and enrichment pipeline.

📚 Understanding Knowledge Bases: From Documents to Retrieval

In the previous article, we looked at different retrieval strategies—BM25, Vector Search, Hybrid Search, SQL, and LLM-powered retrieval. The next logical question is:

Where does the information actually come from?

The answer is a Knowledge Base.

Knowledge bases have become the foundation of many RAG and AI applications. Every major cloud provider now offers a managed knowledge base service, but regardless of the implementation, they all follow a very similar architecture.

At a high level, a knowledge base consists of six stages:

Data Sources
      ↓
Connectors
      ↓
Indexing Pipeline
      ↓
Indexes
(Vector • Metadata • Keyword)
      ↓
Retrieval
      ↓
LLM

---

🔌 Connectors

The first step is getting data into the knowledge base.

Common connectors include:

• S3

• SharePoint

• Confluence

• Google Drive

• Salesforce

• Web crawlers

• Custom APIs

The connector continuously discovers new or updated documents and feeds them into the indexing pipeline.

---

🏗️ Indexing Pipeline

Before documents become searchable, they pass through an indexing pipeline.

Typical steps include:

• Text extraction

• Chunking

• Metadata extraction

• Embedding generation

• Index creation

This is where raw documents are transformed into searchable knowledge.

---

📚 Indexes

Most knowledge bases maintain multiple indexes, each optimized for a different retrieval strategy.

• Vector Index for semantic search

• Metadata Index for filtering

• Keyword Index (BM25) for exact matching

Different queries may use one index—or combine multiple indexes—depending on the retrieval strategy.

---

🔍 Retrieval

When a user submits a query, the retrieval layer determines the best way to find relevant information.

Depending on the use case, it may use:

• BM25

• Vector Search

• Hybrid Search

Metadata filters are often applied before returning the most relevant chunks.

(If you're interested in when to use each retrieval strategy, see my previous article on BM25, Vector Search, Hybrid Search, SQL, and LLM-powered retrieval.)

---

🤖 Generation

The retrieved chunks are passed to an LLM as context.

The LLM doesn't search your documents directly—it generates an answer using the retrieved context.

This is the Generation in Retrieval-Augmented Generation (RAG).

---

☁️ Managed Knowledge Bases

Most cloud providers package this entire pipeline into a managed service.

You typically configure:

• Connectors

• Chunking strategy

• Embedding model

• Indexes

• Retrieval settings

The platform manages ingestion, indexing, synchronization, and retrieval.

Although services differ in their connectors, indexing options, and extensibility, the underlying architecture remains largely the same.

---

🎯 Final Thought

A knowledge base is much more than a vector database.

It's an end-to-end pipeline that ingests content, transforms it into searchable indexes, retrieves relevant context, and provides it to an LLM.

Understanding this architecture makes it much easier to understand where managed knowledge bases fit—and why some organizations eventually choose to build their own.