DEV Community: Parth Sarthi Sharma

Stop Mocking Your Test Dependencies— Get the Real Thing, Locally and in CI, in 3 Commands

Parth Sarthi Sharma — Tue, 25 Aug 2026 02:27:08 +0000

It's 2pm. You need to ship a fix before end of day. You run the integration suite and it fails — not because your code is wrong, but because staging is down. Someone else's bad migration took it out an hour ago, and now you're in the "is it up yet" channel with six other engineers, watching a thread instead of shipping.

Sound familiar? This is the actual, daily cost of how most teams do integration testing. And it usually comes down to one of two bad options.

The two options, and why both are bad

Mock everything. Fast, deterministic, runs anywhere — and proves almost nothing. Your mock says Postgres returns rows in this shape. Real Postgres doesn't care what your mock thinks. The bug that matters — the one your mock can't see by definition — ships to production and pages someone at 2am.

Share a staging environment. Real dependencies, finally — but now you're queued behind whoever's deploying, debugging, or has just quietly broken it for everyone. It's slow, it's flaky in ways that have nothing to do with your code, and "is staging even up right now" becomes a real question you ask multiple times a week.

Neither of these is a testing strategy. They're both just different ways of accepting risk.

There's a third option: real dependencies, but yours alone

Morarix is a CLI that reads a small, hand-authored dependency graph for your service and provisions the real thing — Postgres, Redis, Kafka, and eight AWS services via LocalStack — as disposable, isolated containers on your laptop or in CI. Not a shared environment you wait for. Not a mock you have to trust. The real dependency, health-checked, torn down when you're done, every time.

morarix init                # scaffold morarix.graph.json
morarix import compose      # or: convert an existing docker-compose.yml
morarix up                  # provision + validate — real Postgres, Redis, S3... on localhost

Then you run your existing test suite — completely unmodified — against those real dependencies. Same commands, locally and in CI.

Show, don't tell

Here's the whole morarix.graph.json for a FastAPI service backed by Postgres, Redis, and S3 (one of the reference examples):

{
  "schema_version": "1.0",
  "service": { "name": "python-fastapi", "repo_path": ".", "language": "python", "framework": "fastapi" },
  "dependencies": [
    { "id": "db", "type": "postgres", "fidelity": "real", "source": "manual",
      "required_env_vars": ["MORARIX_DB_CONNECTION_STRING"], "optional": false,
      "image": "postgres", "version": "16" },
    { "id": "cache", "type": "redis", "fidelity": "real", "source": "manual",
      "required_env_vars": ["MORARIX_CACHE_CONNECTION_STRING"], "optional": false,
      "image": "redis", "version": "7" },
    { "id": "assets", "type": "s3", "fidelity": "real", "source": "manual",
      "required_env_vars": ["MORARIX_ASSETS_HOST", "MORARIX_ASSETS_PORT"], "optional": false,
      "resource": { "bucket_name": "widget-assets" } }
  ]
}

That's it. No YAML you have to hand-sync with your CI config. fidelity: "real" means Morarix actually provisions a container and health-checks it — not "the process started," but "Postgres will accept a connection," "Redis responds to PING," "the LocalStack S3 endpoint is reachable."

Here's the actual output of running it — nothing hand-written for this post:

$ morarix up
morarix: loaded 3 dependencies for "python-fastapi"
  - db                   postgres       fidelity=real
  - cache                redis          fidelity=real
  - assets               s3             fidelity=real

morarix: environment ready (run_id=morarix-3f16480cfbc9-1786016512, mode=isolated) — morarix.connections.json and .env.morarix written

$ pytest -v
============================= test session starts =============================
collecting ... collected 9 items

tests/test_api.py::test_health_reports_ok PASSED                         [ 11%]
tests/test_api.py::test_create_widget_then_list_returns_it PASSED        [ 33%]
tests/test_api.py::test_get_widgets_is_cached_across_consecutive_calls PASSED [ 44%]
tests/test_data_access.py::test_insert_and_list_widgets_round_trips_through_postgres PASSED [ 77%]
tests/test_data_access.py::test_cache_set_and_get_round_trips_through_redis PASSED [ 88%]
tests/test_data_access.py::test_spec_upload_and_download_round_trips_through_s3 PASSED [100%]

======================= 9 passed, 3 warnings in 24.13s ========================

$ morarix down
morarix: environment torn down (was: isolated)

No compose file in the app repo. No mocks. No manual container wrangling. Just the real dependencies, up, tested against, and gone.

"Isn't this just docker-compose / Testcontainers / Tilt?"

Fair question — here's the actual difference:

vs. docker-compose by hand — compose has no fidelity concept (a service is either real or entirely absent), no per-type health checks (depends_on isn't "Postgres will actually accept a connection"), and nothing stops your compose file and your CI YAML from silently drifting apart over time.
vs. Testcontainers — Testcontainers is a library embedded in your test code, per language, with its own API to learn per dependency type. Morarix is a CLI: one graph, one morarix up, zero test-code changes, and the same graph works across every language in a polyglot org instead of being re-implemented per service.
vs. Tilt / Skaffold / Garden — those solve your whole live-reload dev loop, usually against Kubernetes, often building and deploying your app itself. Morarix deliberately doesn't touch your app — it only provisions what's around it, so your app keeps running exactly how you already run it.

The same three commands in CI

This is the actual payoff — not a separate CI-specific setup that quietly drifts from what you run locally, but the literal same commands:

- name: Install morarix
  run: go install github.com/morarixhq/morarix/cmd/morarix@latest
- run: morarix up
- run: pytest
- run: morarix down

ubuntu-latest already has Docker. That's the whole prerequisite.

Get it

go install github.com/morarixhq/morarix/cmd/morarix@latest

Prebuilt binaries for Linux, macOS, and Windows (amd64 + arm64) are on the v0.1.0 release — no Go toolchain required.

Currently working end-to-end for Go, Node.js, TypeScript, Java, .NET, and Python, with six runnable reference examples covering both onboarding paths (init from scratch and import compose from an existing docker-compose.yml), plus Postgres, MySQL, Redis, Kafka, REST, and LocalStack health checkers already built in.

Try it, then tell me where it breaks

This is genuinely early — v0.1.0, not a polished v3. If you've got a service with a Postgres/Redis/Kafka dependency sitting behind mocks or a shared staging environment you're tired of waiting on, that's exactly the case this is for. Point it at that service and see what breaks.

⭐ Repo: github.com/morarixhq/morarix
📖 Why Morarix (the full case): morarix-docs/concepts/why-morarix.md
🧭 Usage guide: morarix-docs/docs/usage-guide.md
🧪 Examples: morarix-examples

If it saves you a "is staging up" Slack thread, a star helps other people find it. If it breaks on your setup, open an issue — that's exactly the feedback this stage needs.

The Golden Pipeline for AI/ML Systems in Production

Parth Sarthi Sharma — Sun, 28 Jun 2026 09:45:37 +0000

Most AI/ML tutorials stop at training a model.

Real systems start after that.

In production, the hardest problems are not modeling — they are:

Data quality drift
Evaluation reliability
Deployment safety
Monitoring failure modes
Continuous improvement loops

This article breaks down a practical Golden Pipeline for AI/ML systems based on real production engineering practices.

1. The Golden Pipeline (End-to-End View)

A real production ML/AI system looks like this:

Data Ingestion → Validation → Feature Engineering → Training →
Evaluation → Model Registry → Deployment →
Shadow Testing → A/B Testing → Monitoring → Feedback Loop

Each stage is independently versioned and testable.

2. Data Ingestion Layer

Core Principle:

Never trust raw data.

Best Practices:

Use streaming ingestion (Kafka / Kinesis / PubSub)
Store raw + processed data separately
Enforce schema validation at ingestion time
Track full data lineage

Common Failure:

Most ML failures are NOT model failures — they are data pipeline failures.

3. Data Validation Layer

Before training:

Validate schema
Check missing values
Detect anomalies
Ensure type consistency

Recommended Tools:

Great Expectations
Pandera
Pydantic (very effective in Python systems)

Example:

from pydantic import BaseModel

class Transaction(BaseModel):
    amount: float
    currency: str
    timestamp: str

4. Feature Engineering Layer

=============================

Rule:

If a feature is not reproducible → it does not exist.

Best Practices:

Make feature pipelines deterministic
Avoid inline feature computation during training
Use feature stores when possible:
- Feast
- Tecton

5. Training Pipeline

=====================

Principles:

Training must be stateless
Every run must be reproducible
Log all hyperparameters
Version datasets

Tools:

MLflow
Weights & Biases
DVC
Hydra

6. Evaluation Layer (Critical)

===============================

This is where most systems fail.

Never rely on a single metric.

Use layered evaluation:

1. Exact Metrics

Accuracy
Precision / Recall
F1

2. Task-Specific Metrics

Exact match
Numeric tolerance (important in finance systems)
Structured output validation

3. LLM-Based Evaluation (if applicable)

Pairwise comparison
Rubric scoring
LLM-as-judge (carefully calibrated)

Key Insight:

Exact match is often WRONG in real-world systems.

Example:

Gold: -32%
Prediction: -32.82%

This should be considered correct under tolerance rules.

7. Model Registry

==================

Never deploy models directly.

Use a model registry:

MLflow Model Registry
SageMaker Registry
Custom versioned storage (S3/GCS)

Store:

Model version
Dataset version
Metrics
Git commit hash
Config snapshot

8. Deployment Strategies

=========================

Option 1: Direct deployment

Risky
No rollback

Option 2: Blue-Green Deployment

Two environments
Instant rollback possible

Option 3: Canary Deployment (Best Practice)

Deploy to small % of traffic
Gradually scale
Monitor closely

9. Shadow Mode (Highly Underrated)

===================================

Run new model in parallel with production:

No user impact
Compare outputs silently
Detect silent failures

Why it matters:

Prevents production incidents
Detects drift early
Validates behavior safely

10. A/B Testing

================

After shadow validation:

Split traffic between models
Measure real impact

Metrics:

Accuracy proxies
Latency
User engagement
Business KPIs

11. Monitoring

===============

If you don’t monitor, your model is broken already.

Monitor:

Data drift
Prediction drift
Latency
Error rates
Confidence distributions

Tools:

Prometheus
Grafana
Evidently AI
Arize

12. Feedback Loop

==================

This is where production ML systems improve.

Sources:

User corrections
Human labeling
Implicit feedback (clicks, edits)

This becomes future training data.

13. What Most Engineers Miss

=============================

Everything must be versioned
Assume models will fail
Always have rollback strategy
Data is more important than model
Evaluation is a first-class system

14. Final Takeaway

===================

A production AI system is NOT:

model training + deployment

It is:

a continuous loop of:data → training → evaluation → deployment → monitoring → feedback

The model is just one part of the system.

The pipeline is the product.

If You’re Building This

Start simple:

Add strict data validation first
Build evaluation before improving models
Introduce shadow mode early
Log everything from day one
Always design for failure

9 Practical Ways Senior ML Engineers Reduce Inference Latency

Parth Sarthi Sharma — Sat, 20 Jun 2026 07:37:31 +0000

Most teams blame the model when an AI application feels slow.

In reality, the model is often only one part of the latency budget.

A typical AI request may involve:

User Request
    ↓
Authentication
    ↓
Feature Retrieval
    ↓
Vector Search
    ↓
Agent Orchestration
    ↓
LLM Inference
    ↓
Guardrails
    ↓
Response Generation

By the time the user sees a response, latency has accumulated across multiple layers of the system.

After working on cloud-native systems, GenAI platforms, and distributed architectures, I've noticed that the best AI engineers focus on optimizing the entire pipeline—not just the model.

Here are 9 practical techniques commonly used in production AI systems.

1. Optimize Feature Retrieval Before Touching the Model

Many AI and ML systems spend more time fetching data than generating predictions.

Common examples:

Fraud detection systems fetching customer risk profiles
Recommendation systems retrieving user interaction history
Personalization engines loading customer attributes

A model that takes 50ms to infer becomes a 500ms system if feature retrieval takes 450ms.

Instead of:

Request
 ↓
Database Queries
 ↓
Model

Use:

Request
 ↓
Online Feature Store
 ↓
Model

Technologies commonly used:

Redis
DynamoDB
Feast Online Store
Tecton Online Store

The fastest prediction is often achieved by reducing feature lookup latency.

2. Separate Real-Time and Batch Features

Not every feature needs to be calculated at request time.

Bad:

Request
 ↓
Calculate 30-day spending history
 ↓
Model

Good:

Nightly Batch Pipeline
 ↓
Precompute Features
 ↓
Store in Feature Store

Request
 ↓
Feature Lookup
 ↓
Model

Examples of batch features:

Average spend last 30 days
Customer lifetime value
Product affinity scores

Examples of real-time features:

Transactions in last 5 minutes
Products viewed in current session
Failed login attempts

This reduces inference latency dramatically.

3. Cache Aggressively

One of the highest ROI optimizations.

Many requests are repetitive.

Examples:

Frequently asked support questions
Popular product recommendations
Repeated vector search results

Instead of:

Query
 ↓
RAG
 ↓
LLM

Use:

Query
 ↓
Cache Check
 ↓
Return Cached Response

Common technologies:

Redis
CloudFront
Application-level caches

A cache hit often reduces latency from seconds to milliseconds.

4. Reduce Retrieval Latency

In RAG systems, retrieval often becomes the bottleneck.

Typical latency contributors:

Large vector indexes
Excessive top-K retrieval
Poor filtering strategies

Instead of:

Search Entire Knowledge Base

Use:

Metadata Filters
 +
Vector Search

Examples:

Search only banking documents
Search only relevant departments
Search only customer-specific data

Reducing search space significantly improves response times.

5. Use Hybrid Retrieval Carefully

Many teams combine:

Vector Search
+
Keyword Search

which improves quality but increases latency.

Practical approach:

Keyword Search
 ↓
Candidate Set
 ↓
Vector Ranking

instead of searching the entire corpus twice.

Quality matters, but so does speed.

6. Parallelize Tool Calls and Agent Workflows

One of the most common mistakes in agentic systems is sequential execution.

Bad:

Agent
 ↓
Tool A
 ↓
Tool B
 ↓
Tool C

Total latency:

A + B + C

Better:

Agent
 ↓
Parallel Execution
 ↓
Tool A
Tool B
Tool C

Total latency:

max(A,B,C)

This can reduce response time by several seconds.

7. Use Smaller Models Where Possible

Not every task requires a large model.

Examples:

Task	Better Choice
Classification	Small Model
Intent Detection	Small Model
Routing	Small Model
Summarization	Medium Model
Complex Reasoning	Large Model

A common production pattern:

Small Model
 ↓
Route Request
 ↓
Large Model (only when needed)

This reduces both latency and cost.

8. Quantize Models

A technique heavily used in production ML systems.

Instead of:

FP32 Model

Use:

INT8
INT4

or similar quantized formats.

Benefits:

Smaller memory footprint
Faster inference
Lower infrastructure costs

Especially useful for:

Edge deployments
Real-time recommendation systems
High-throughput inference workloads

The trade-off is a small accuracy reduction.

9. Measure the Entire Latency Budget

This is where observability becomes critical.

Many teams optimize the model while ignoring everything else.

Track latency across:

Feature Retrieval
Vector Search
Agent Routing
Tool Calls
LLM Inference
Guardrails
Response Validation

A typical breakdown might look like:

Feature Retrieval      50ms
Vector Search         120ms
Tool Calls            300ms
LLM Inference        2200ms
Guardrails            150ms

Without tracing, teams often optimize the wrong component.

Platforms such as Langfuse, HoneyHive, Arize Phoenix, and OpenTelemetry-based observability stacks make these bottlenecks visible.

The Real Lesson

The fastest AI systems are rarely the ones with the fastest models.

They are the systems with:

Efficient feature retrieval
Smart caching
Optimized retrieval pipelines
Parallel execution
Right-sized models
Strong observability

Senior AI engineers optimize the entire system.

Because users don't care whether the delay comes from a vector database, a feature store, an agent, or an LLM.

They only notice one thing:

How long it takes to get an answer.

I Compared 7 AI Observability Platforms So You Don’t Have To (2026 Edition)

Parth Sarthi Sharma — Thu, 11 Jun 2026 05:50:50 +0000

The AI tooling ecosystem is exploding.

Every week there seems to be a new platform promising:

Better traces
Better evaluations
Better prompt debugging
Better monitoring
Better cost visibility

The challenge isn’t finding an AI observability tool anymore.

The challenge is choosing one.

If you’re building AI applications today, chances are you’ve come across names like Langfuse, LangSmith, HoneyHive, Helicone, Arize, Braintrust, or Phoenix.

After exploring these platforms, I noticed something interesting:

Most tools overlap in functionality, but each one is optimized for a very different workflow.

This article focuses on comparing the tools themselves—not explaining AI observability concepts.

Let’s dive in.

⸻

Evaluation Criteria

For this comparison I evaluated each platform across:

Tracing and debugging
Prompt monitoring
Evaluations (Evals)
Cost tracking
Dataset management
Self-hosting support
Enterprise readiness
Ease of adoption

⸻

Quick Comparison Table

Tool	Open Source	Tracing	Evaluations	Cost Monitoring	Self Host	Best For
Langfuse	✅ Yes	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	✅ Yes	Most teams
HoneyHive	❌ No	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	❌ No	Enterprise AI
LangSmith	❌ No	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐	❌ No	LangChain users
Helicone	⚠️ Partial	⭐⭐⭐	⭐⭐	⭐⭐⭐⭐⭐	✅ Yes	Cost visibility
Arize	⚠️ Partial	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⚠️ Limited	Large production systems
Braintrust	⚠️ Partial	⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐	⚠️ Limited	Evaluation-first workflows
Phoenix	✅ Yes	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐	✅ Yes	Lightweight OSS setups

⸻

Langfuse

What Stands Out

Langfuse has become one of the most popular choices for AI engineering teams.

It combines:

Tracing
Prompt management
Evaluations
Dataset tracking
Cost analytics

in a single platform.

The biggest advantage is flexibility.

Unlike many commercial products, Langfuse does not lock you into a specific framework.

You can use:

OpenAI
Anthropic
Gemini
Bedrock
LangChain
LangGraph
Custom agents

without major friction.

Strengths

✅ Open source

✅ Self-hosting available

✅ Strong evaluation workflows

✅ Framework agnostic

✅ Excellent developer experience

Weaknesses

❌ More setup than fully managed platforms

❌ Enterprise features may require additional work

Best For

Teams wanting a long-term observability platform without vendor lock-in.

⸻

HoneyHive

What Stands Out

HoneyHive focuses heavily on enterprise AI quality and testing.

The platform goes beyond simple tracing and emphasizes:

Evaluation pipelines
Regression testing
Prompt experimentation
AI system quality measurement

This makes it particularly attractive for organizations deploying AI into production at scale.

Strengths

✅ Enterprise-grade workflows

✅ Strong evaluation capabilities

✅ Regression testing

✅ Production monitoring

Weaknesses

❌ Less attractive for hobby projects

❌ Commercial-first offering

Best For

Organizations that treat AI systems like mission-critical software.

⸻

LangSmith

What Stands Out

If your stack is already built around LangChain or LangGraph, LangSmith feels almost automatic.

The integration is excellent.

You get:

Agent traces
Execution paths
Prompt inspection
Chain debugging

with minimal effort.

Strengths

✅ Best LangChain integration

✅ Excellent trace visualization

✅ Fast setup

✅ Agent debugging experience

Weaknesses

❌ Less attractive outside LangChain ecosystems

❌ Limited self-hosting options

Best For

Teams deeply invested in LangChain or LangGraph.

⸻

Helicone

What Stands Out

Helicone is probably the easiest way to understand where your AI budget is going.

Its focus is much more operational than evaluation-centric.

You get visibility into:

Request volume
Token usage
Model consumption
Cost breakdowns

without significant complexity.

Strengths

✅ Excellent cost analytics

✅ Quick integration

✅ OpenAI proxy model

✅ Lightweight deployment

Weaknesses

❌ Evaluation capabilities lag competitors

❌ Less sophisticated tracing

Best For

Startups trying to control AI infrastructure costs.

⸻

Arize

What Stands Out

Arize comes from the machine learning observability world.

As a result, it brings strong production monitoring capabilities that many AI-native tools still lack.

The platform is particularly strong when organizations combine:

Traditional ML systems
Recommendation systems
LLM applications

inside the same environment.

Strengths

✅ Mature monitoring platform

✅ Strong evaluation tooling

✅ Enterprise scale

✅ ML + LLM support

Weaknesses

❌ Can feel overwhelming for small teams

❌ Higher operational complexity

Best For

Large-scale AI platforms operating in production.

⸻

Braintrust

What Stands Out

Braintrust takes a different approach.

Rather than starting with traces, it starts with evaluations.

The philosophy is simple:

“If you can’t measure quality, you can’t improve quality.”

This makes Braintrust especially useful for teams focused on:

Prompt optimization
Model comparisons
Benchmarking
Continuous evaluation

Strengths

✅ Excellent evaluation workflows

✅ Dataset management

✅ Benchmarking capabilities

✅ Model comparison workflows

Weaknesses

❌ Less focused on operational monitoring

❌ Tracing is not the primary strength

Best For

Teams building evaluation-driven AI development processes.

⸻

Phoenix

What Stands Out

Phoenix is one of the strongest open-source alternatives available.

It provides:

Tracing
Evaluation workflows
Debugging capabilities

without introducing significant operational overhead.

Many engineers adopt Phoenix because they want observability without committing to a larger commercial ecosystem.

Strengths

✅ Open source

✅ Lightweight deployment

✅ Good tracing

✅ Simple adoption

Weaknesses

❌ Smaller ecosystem

❌ Fewer enterprise features

Best For

Engineers wanting lightweight observability with minimal complexity.

⸻

My Recommendations

If I had to choose today:

My Recommendations

Scenario	Recommendation
Best Overall	Langfuse
Best Enterprise Choice	HoneyHive
Best LangChain Experience	LangSmith
Best Cost Tracking	Helicone
Best Evaluation Platform	Braintrust
Best Production Monitoring	Arize
Best Lightweight Open Source Option	Phoenix

⸻

Final Thoughts

The interesting thing about AI observability tools is that most of them solve similar problems.

The real difference is where they place their emphasis.

Langfuse focuses on flexibility.
HoneyHive focuses on enterprise quality.
LangSmith focuses on developer productivity.
Helicone focuses on costs.
Arize focuses on production monitoring.
Braintrust focuses on evaluations.
Phoenix focuses on lightweight open-source adoption.

There is no universally “best” platform.

The right choice depends on what bottleneck you’re trying to solve:

Debugging?
Evaluation?
Monitoring?
Cost optimization?
Enterprise governance?

Choose the tool that aligns with that bottleneck, and you’ll likely get far more value than chasing feature checklists.

What AI observability platform are you currently using, and what made you choose it?

How Senior Engineers Use AI Without Burning Through Token Limits - Reduce AI Token Usage by 60–90%

Parth Sarthi Sharma — Sat, 06 Jun 2026 12:16:25 +0000

Last month I watched a developer exhaust their Claude usage limit in less than a week.

They weren't generating massive applications.

They weren't building complex AI systems.

They were simply asking AI to repeatedly scan the same repository, read the same files, and explain the same architecture over and over again.

Sound familiar?

As AI-assisted development becomes mainstream, many teams are discovering a new engineering challenge:

Token efficiency.

Just as experienced engineers learned to optimize cloud spend, senior engineers are now learning to optimize AI context.

The difference between a developer who runs out of tokens every few days and one who comfortably works all month often isn't the AI model.

It's how they manage context.

Here's the toolkit and workflow I've seen work consistently.

The Hidden Cost of Vibe Coding

Imagine you ask:

Fix a bug in PaymentService.ts

Your AI assistant proceeds to:

Scan the entire repository
Read infrastructure code
Explore frontend folders
Traverse documentation
Load previous conversations
Inspect unrelated dependencies

You asked about one file.

The model consumed context from hundreds.

That's where your tokens disappear.

The goal isn't to reduce intelligence.

The goal is to reduce unnecessary context.

1. RTK: Stop Paying For Useless Command Output

One of the biggest hidden token sinks is terminal output.

Many AI coding agents automatically consume:

npm install logs
build outputs
test results
deployment logs
dependency resolution messages

Most of this information is irrelevant.

Tools like RTK solve this problem.

What RTK Does

RTK acts as a proxy layer between your development environment and the LLM.

Instead of forwarding everything:

npm install

RTK filters:

redundant messages
repeated warnings
progress indicators
noise

before they ever reach the model.

Benefits

Reported reductions:

60–90% reduction in token consumption for common development workflows
Faster agent reasoning
Cleaner context windows

The principle is simple:

If a human wouldn't read it, the model probably shouldn't either.

2. Lean-CTX: Compress Context Before It Reaches The Model

Most developers optimize prompts.

Few optimize files.

Large source files often contain:

generated code
comments
repetitive structures
boilerplate

Lean-CTX dynamically compresses and optimizes file content before it gets sent to the model.

Why It Matters

Instead of sending:

4,000 line file

you might send:

Relevant functions
Dependencies
Symbols
Interfaces

The AI receives the information it needs while consuming significantly fewer tokens.

Think of it as:

gzip for AI context.

3. AI Codex & Repository Indexers

One of the most expensive activities in AI coding is:

"Explore my codebase."

The model begins reading dozens of files trying to understand:

routes
APIs
schemas
services
components

This exploratory phase can easily burn tens of thousands of tokens.

Repository indexing tools solve this.

What They Generate

Instead of scanning everything:

Generate:

ROUTES.md
DATABASE_SCHEMA.md
COMPONENTS.md
SERVICES.md
DEPENDENCIES.md

Now the AI can understand the system from five small files instead of 500 source files.

Typical Savings

Many teams report avoiding:

30k–50k tokens

during initial codebase exploration.

This is one of the highest ROI improvements you can make.

The Caveman Rule: My Favorite Token Hack

This sounds ridiculous.

But it works.

When you need code, you don't need essays.

You don't need:

Certainly! Here's a detailed explanation...

You need:

Bug here.
Fix this.
Run test.
Done.

The Caveman Rule instructs the AI to:

skip conversational filler
avoid lengthy summaries
communicate with minimal words

Example:

Instead of:

I've identified several possible root causes...

You get:

Null value here.
Add guard clause.
Problem solved.

The technical accuracy remains.

The verbosity disappears.

Many developers report output token reductions approaching 75%.

Create A Project Brain

One of the biggest mistakes I see:

Developers repeatedly explaining their project.

Every new session starts with:

We're using:
- Node.js
- PostgreSQL
- Kubernetes
- OpenTelemetry
- GitHub Actions

Again.

And again.

Instead create:

CLAUDE.md
AGENTS.md
PROJECT_CONTEXT.md
ARCHITECTURE.md

Store:

architecture
conventions
coding standards
deployment patterns
repository structure

Now every session starts with shared understanding.

The AI spends less time learning.

You spend fewer tokens teaching.

The Fragmented Code Approach

Another expensive habit:

Rewrite the entire file.

The AI responds with:

2,000 lines

You pay for all of it.

Instead ask:

Modify only lines 120–150.
Return patch only.
No summary.

Benefits:

fewer output tokens
smaller future context
easier reviews
lower costs

The best AI engineers increasingly think in patches, not rewrites.

Native IDE Features Most Developers Ignore

Many modern AI IDEs already provide token optimization features.

Most people never use them.

Cost Caps

Set:

maximum tool calls
session budgets
usage limits

Treat tokens like cloud spend.

Because they are.

Compact Sessions

Claude and other tools support context compaction.

Example:

/compact

This removes:

redundant conversation history
obsolete decisions
resolved issues

while preserving important context.

Think:

garbage collection for conversations.

New Session, New Problem

One of the easiest wins:

Start fresh.

When:

a feature is complete
a bug is resolved
you're switching domains

create a new session.

Old conversations become baggage.

The model keeps re-reading:

mistakes
abandoned approaches
irrelevant context

Fresh context often produces better results.

My Personal Context Engineering Checklist

Before asking AI anything:

Repository

Exclude:

node_modules/
dist/
coverage/
build/
.next/
target/

Context

Maintain:

CLAUDE.md
AGENTS.md
ARCHITECTURE.md
PROJECT_CONTEXT.md

Tooling

Use:

RTK
Lean-CTX
AI Codex
Repository Indexers
Semantic Search
Code Graphs

Prompting

Prefer:

Patch only.
No summary.

instead of:

Explain everything.

Sessions

Compact regularly
Start fresh often
Keep contexts small

Final Thoughts

For years we optimized:

cloud costs
compute costs
storage costs
network costs

Now we need to optimize:

context costs

The next generation of high-performing AI engineers won't be the people with the biggest context windows.

They'll be the people who know exactly what context to send.

Prompt engineering helped us talk to AI.

Context engineering helps us scale AI.

And in the age of vibe coding, context is the new compute.

Reflection vs Reflexion Agents: The Next Leap in Agentic AI

Parth Sarthi Sharma — Sun, 22 Mar 2026 03:04:03 +0000

As generative AI systems evolve from simple prompt-response tools into autonomous agents, one capability is becoming increasingly critical:

The ability for AI systems to improve themselves during execution.

This is where two powerful concepts come into play:

Reflection
Reflexion

They sound similar. They are often confused.

But architecturally — and practically — they are very different.

Let’s break them down.

🚀 Why This Matters

If you're building:

AI copilots
Autonomous workflows
Multi-step reasoning systems
Or agentic architectures

Then how your system learns from mistakes will define:

Accuracy
Reliability
Cost efficiency
User trust

🧠 What is Reflection?

Reflection is when an AI system:

Reviews its own output and improves it within the same execution loop.

🔁 How it works

Generate response
Evaluate response (self-critique or evaluator model)
Refine response
Repeat until acceptable

🧩 Architecture Pattern

User Input
↓
LLM → Output
↓
Self-Evaluation (LLM or rule-based)
↓
Refinement Loop
↓
Final Output

✅ Key Characteristics

Happens within a single session
No memory across runs
Iterative improvement
Often uses:
- Self-critique prompts
- Evaluation models
- Chain-of-thought refinement

💡 Example

User asks:

"Summarize this legal document."

Reflection agent:

Generates summary
Checks:
- Missing clauses?
- Ambiguity?
Refines output

👍 Pros

Improves output quality instantly
No infrastructure complexity
Easy to implement

👎 Cons

No long-term learning
Repeats same mistakes across sessions
Increased latency (multiple LLM calls)

🔁 What is Reflexion?

Reflexion goes a step further.

It enables an AI system to learn from past mistakes and improve future performance.

This concept was popularized by research on self-improving agents with memory.

🔄 How it works

Perform task
Evaluate outcome
Store feedback in memory
Use memory to improve future decisions

🧩 Architecture Pattern

User Input
↓
Agent Execution
↓
Outcome Evaluation
↓
Memory Store (success/failure insights)
↓
Future Runs Use Memory

🧠 Key Difference

Reflection	Reflexion
Session-based	Cross-session
No memory	Persistent memory
Improves current output	Improves future outputs
Stateless	Stateful

💡 Example

AI agent writing grant applications:

Attempt 1: Rejected ❌
Stores feedback:
- "Too generic"
- "Lacks domain-specific references"

Next attempt:

Uses stored insights
Produces better output ✅

🔥 Why Reflexion is a Big Deal

Reflexion introduces something critical:

Learning without retraining the model

Instead of fine-tuning:

You store experiences
You adapt behavior dynamically

🏗️ Real-World Implementation

Reflection (simple)

Prompt chaining
Self-critique prompts
ReAct-style loops

Reflexion (advanced)

Requires:

Memory layer:
- Vector DB (e.g., embeddings)
- Key-value store
Feedback signals:
- Human feedback
- Automated scoring
Retrieval mechanism:
- Inject past learnings into prompts

⚙️ Example Stack

LLM: Claude / GPT / Nova
Memory: Vector DB (FAISS, OpenSearch)
Orchestration: LangChain / custom agents
Evaluation: Rule-based or LLM-as-judge

⚖️ When to Use What?

Use Reflection when:

You need better answers now
No need for memory
Simpler workflows

Use Reflexion when:

Tasks are repetitive and evolving
Feedback is available
Long-term improvement matters

🧠 Combining Both (Best Practice)

The most powerful systems use both:

Reflexion (long-term learning)
+
Reflection (short-term refinement)

👉 This creates:

Immediate quality improvement
Continuous learning over time

🧪 Real-World Use Cases

AI coding assistants
Customer support agents
Financial advisory copilots
Healthcare decision support
Autonomous research assistants

⚠️ Challenges

Reflection

Cost (multiple LLM calls)
Latency

Reflexion

Memory design complexity
Signal quality (bad feedback = bad learning)
Retrieval accuracy

🧭 Final Thoughts

We are moving from:

Prompt → Response

to:

Prompt → Reason → Reflect → Learn → Improve

🔥 Key Insight

Reflection makes AI smarter in the moment

Reflexion makes AI smarter over time

✍️ Closing

If you're building next-gen AI systems,

understanding this difference is not optional — it's foundational.

The future of AI is not just about better models.

It’s about better systems around those models.

💬 Curious how to implement Reflexion in production?

Happy to share a deep dive in the next post.

Prompt Engineering Is Not Enough: Enter Flow Engineering for Production LLM Systems

Parth Sarthi Sharma — Sat, 07 Mar 2026 03:20:46 +0000

Large Language Models have unlocked a new generation of applications — copilots, assistants, RAG systems, autonomous agents, and internal AI tools.

But many teams building with LLMs hit the same wall.

Their application works in demos… but becomes unreliable in production.

Why?

Because prompt engineering alone is not enough.

To build reliable AI systems, we need something more powerful:

Flow Engineering.

In this article, we'll explore:

Why prompt engineering alone fails in production
What Flow Engineering actually means
The architecture of real-world LLM systems
Practical examples engineers can implement today

The Era of Prompt Engineering

When GPT-style models first became popular, the focus was on prompt engineering.

Prompt engineering is the art of crafting instructions to guide the LLM to produce better responses.

Example:

You are a helpful assistant. 
Summarise the following meeting transcript in bullet points.
Focus only on action items.

Developers quickly discovered techniques like:

Few-shot prompting
Chain-of-thought prompts
Role prompting
Structured output prompts

These techniques improve individual LLM calls.

But they only solve part of the problem.

Prompt engineering optimises one interaction.

Real applications involve many interactions and system components.

The Problem with Prompt-Only Systems

Let's imagine we are building a simple customer support AI assistant.
A naive architecture might look like this:

User Question
      ↓
     LLM
      ↓
   Response

This works in simple demos.

But real systems quickly require more complexity.

For example:

Retrieve relevant documents
Use tools (APIs, databases)
Validate outputs
Retry on errors
Maintain conversation context
Apply guardrails
Log reasoning steps

Suddenly, our architecture looks more like this:

User Question
      ↓
Context Retrieval (RAG)
      ↓
Tool Selection
      ↓
LLM Reasoning
      ↓
Output Validation
      ↓
Response Generation

This multi-step pipeline is where Flow Engineering comes in.

What Is Flow Engineering?

Flow Engineering is the design of structured execution flows around LLMs.

Instead of focusing on a single prompt, engineers design end-to-end reasoning pipelines.

Think of it as:

Prompt Engineering = How the LLM thinks

Flow Engineering = How the system operates

Flow engineering involves designing:

Execution pipelines
Tool orchestration
State management
Error handling
Validation
Feedback loops

In other words:

Flow engineering treats LLM applications as distributed systems, not chatbots.

A Real Production Flow

Let's look at a simplified production AI flow.

User Question
   ↓
Input Guardrails
   ↓
Context Retrieval (Vector DB)
   ↓
Tool Routing
   ↓
LLM Reasoning
   ↓
Tool Execution
   ↓
Response Validation
   ↓
Final Answer

Each step solves a real engineering problem.

Guardrails

Prevent prompt injection or malicious input.

Context Retrieval

Fetch relevant documents using vector search.

Tool Routing

Determine which tools the AI should use.

Validation

Ensure output matches schema or safety rules.

Without this flow, AI systems become unpredictable.

Example: Prompt vs Flow

Let's compare two implementations.

Prompt Engineering Only

response = llm.invoke(
    "Summarise this transcript and extract action items."
)

This may work sometimes.

But what if:

transcript is too long
model hallucinate action items
output format changes
context is missing

Now let's see a flow-based approach.

Example: Flow Engineered System

def generate_meeting_summary(transcript):

    chunks = split_transcript(transcript)

    summaries = []

    for chunk in chunks:
        summary = llm.invoke(
            f"Summarise this transcript section:\n{chunk}"
        )
        summaries.append(summary)

    combined_summary = llm.invoke(
        f"Combine these summaries and extract action items:\n{summaries}"
    )

    validated_output = validate_schema(combined_summary)

    return validated_output

Now we have:

chunking
intermediate reasoning
structured validation

This dramatically improves reliability.

Key Components of Flow Engineering

Most production LLM flows include these components.

1. State Management
Flows maintain state across steps.

Example:

Conversation History
Retrieved Documents
Tool Results

Frameworks like LangGraph model this using state machines.

2. Tool Orchestration

LLMs often interact with tools.

Examples:

databases
APIs
search engines
internal systems

Flow engineering controls:

which tool to use
when to call it
how to merge results

3. Retry & Error Handling

LLMs are probabilistic.

Sometimes outputs are invalid.

A flow can automatically:

retry generation
correct formatting
request clarification

4. Guardrails & Validation

Before returning outputs, systems often validate:

JSON schema
safety policies
hallucinations

This prevents unreliable responses.

Flow Engineering Frameworks

Several frameworks help engineers implement LLM flows.

LangGraph

Models AI workflows as state machines.

Great for:

complex agent workflows
branching logic
memory management

Semantic Kernel

Popular in enterprise environments.

Supports:

planners
function calling
workflow orchestration

Custom Orchestration

Many teams implement flows directly using:

Python
Node.js
serverless pipelines

Because flows are essentially application logic.

Why Flow Engineering Matters

Companies deploying production AI systems quickly discover:

The challenge is not the model.

The challenge is system design around the model.

Flow engineering provides:

✔ reliability
✔ reproducibility
✔ observability
✔ safety
✔ scalability

Without it, LLM applications behave unpredictably.

The Shift AI Engineers Must Make

Early LLM development focused on prompts.

But the industry is moving toward AI systems engineering.

That means thinking in terms of:

pipelines
workflows
orchestration
tool ecosystems

In short:

AI applications are evolving from prompt-driven apps to flow-driven systems.

Final Thoughts

Prompt engineering is still important.

But in production systems, prompts are only one component.

The real power of modern AI systems comes from well-designed execution flows.

If you want reliable AI applications, start thinking like a systems engineer, not just a prompt writer.

What’s Next

In upcoming articles, we'll dive deeper into:

Reflection vs Reflexion agents
LangGraph state machines
Semantic Kernel orchestration
Model Context Protocol (MCP)

These concepts build on flow engineering to create more capable AI systems.

Secrets Management for LLM Tools: Don’t Let Your OpenAI Keys End Up on GitHub 🚨

Parth Sarthi Sharma — Sat, 14 Feb 2026 04:04:56 +0000

"A practical guide to securing LLM API keys, embeddings, vector

TL;DR: If you're building with LLMs and you're not treating secrets as first-class infrastructure, you're already at risk.

Every week, we see:

OpenAI keys pushed to GitHub
API keys logged in CloudWatch
Secrets hardcoded in Streamlit demos that later go to production

LLM systems multiply secrets quickly. If you don’t design for this early, things get messy fast.

This is a production-ready blueprint for securing LLM systems properly.

The Problem: LLM Secrets Multiply Fast 🐰

One LLM integration turns into dozens of credentials:

1 LLM API key (OpenAI / Anthropic)
→ 3 embedding endpoints
→ 5 vector store connections (Pinecone / Weaviate)
→ 2 RAG databases
→ 10 external tools (SerpAPI, Wolfram, etc.)
→ 50 microservices
= 70+ secrets

The bigger your AI system gets, the larger your attack surface becomes.

1️⃣ Never Hardcode Secrets

❌ Wrong (guaranteed leak eventually)

# NEVER DO THIS
from openai import OpenAI

client = OpenAI(api_key="sk-123...")

Hardcoded secrets:

End up in git history
Get copied into logs
Leak via screenshots or stack traces

✅ Right: Runtime Environment Injection

# config.py

import os
from openai import OpenAI

OPENAI_API_KEY = os.getenv("OPENAI_API_KEY")

client = OpenAI(api_key=OPENAI_API_KEY)

Principle:
Secrets should be injected at runtime, never committed to source code.

2️⃣ Use Cloud-Native Secrets Managers

If you're in production, use a managed secrets service.

AWS Secrets Manager + Lambda Example

# lambda_function.py
import json
import boto3
from openai import OpenAI

def get_secrets():
    client = boto3.client("secretsmanager")
    secret = client.get_secret_value(SecretId="llm-prod/openai")
    return json.loads(secret["SecretString"])

def lambda_handler(event, context):
    secrets = get_secrets()
    client = OpenAI(api_key=secrets["OPENAI_API_KEY"])
    # LLM logic here

Benefits:

Centralized storage
IAM-based access control
Audit logs
Automatic rotation support

Terraform for Secret Infrastructure

resource "aws_secretsmanager_secret" "llm_keys" {
  name = "llm-prod/openai"
  tags = {
    Environment = "Production"
    Team        = "AI"
  }
}

resource "aws_secretsmanager_secret_version" "llm_keys_version" {
  secret_id     = aws_secretsmanager_secret.llm_keys.id
  secret_string = jsonencode({
    OPENAI_API_KEY    = "sk-..."
    ANTHROPIC_API_KEY = "sk-ant-..."
    PINECONE_API_KEY  = "pxl-..."
  })
}

Infrastructure-as-Code ensures:

Repeatability
Auditability
No manual copy-paste secret management

3️⃣ Prefer Dynamic Credentials Over Static API Keys ⚡

Static API keys are long-lived and high risk.

Dynamic credentials reduce blast radius.

IAM Roles for Service Accounts (Kubernetes + AWS IRSA)

apiVersion: v1
kind: ServiceAccount
metadata:
  name: llm-worker
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/llm-worker-role
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: llm-worker
spec:
  template:
    spec:
      serviceAccountName: llm-worker
      containers:
        - name: llm-worker
          env:
            - name: OPENAI_API_KEY
              valueFrom:
                secretKeyRef:
                  name: llm-secrets
                  key: openai-key

Even better: eliminate API keys entirely where possible and use workload identity federation.

4️⃣ Secure CI/CD with OIDC (No Long-Lived AWS Keys)

Never store AWS credentials in GitHub secrets if you can avoid it.

Use OIDC federation instead:

name: Deploy LLM Pipeline

on: [push]

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
    steps:
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/github-actions-llm-deploy
          aws-region: us-east-1

      - run: python deploy.py

This avoids:

Static AWS access keys
Manual credential rotation
CI secret sprawl

5️⃣ Agentic LLM Systems Need Scoped Secrets 🧠

When building multi-agent systems:

Each agent should have scoped credentials
Short-lived tokens preferred
No shared global API key across agents

Example pattern:

class LLMAgentSecrets:
    def __init__(self, sm_client):
        self.sm_client = sm_client

    def get_agent_secret(self, agent_id: str):
        secret_name = f"llm-agent-{agent_id}"
        secret = self.sm_client.get_secret_value(SecretId=secret_name)
        return secret["SecretString"]

Design for:

Isolation
Least privilege
Auditable access

✅ Production Security Checklist

☐ No hardcoded secrets (git grep -i "sk-")
☐ Cloud secrets manager in use
☐ IAM roles preferred over static keys
☐ OIDC for CI/CD
☐ Secrets scanning enabled (TruffleHog, GitGuardian)
☐ Log sanitization in place
☐ Rotation policy defined (≤ 90 days)
☐ Audit logging enabled
☐ Least privilege enforced

Common Leak Vectors 🚫

Leak Vector	Detection	Prevention
Git commits	`git log -p	grep sk-`	Pre-commit hooks
Logs	CloudWatch Insights	Log scrubbing
Docker images	Inspect image layers	Multi-stage builds
Memory dumps	`/proc/[pid]/environ`	Container hardening

Cost vs Risk 💰

Typical monthly cost for secure secrets management:

AWS Secrets Manager: ~$0.40 per secret
Secret scanning tools: modest monthly fee
OIDC: no additional cost
Compare that to:
Revoking leaked keys
Service outages
Customer trust damage

Security is cheaper than cleanup.

Key Takeaways 🎯

Dynamic > Static
Inject at runtime, never commit
Audit secret access
Rotate regularly
Scan continuously
Apply least privilege everywhere

LLMs are powerful.

But API keys are still just credentials — treat them like production infrastructure.

Have you ever dealt with an exposed LLM API key in production? What happened?
Let’s discuss 👇

Observability in AI Systems

Parth Sarthi Sharma — Tue, 27 Jan 2026 13:17:25 +0000

Why RAG Pipelines Fail Silently (and How to See It)

Traditional software taught us a hard lesson:

If you can’t observe it, you can’t operate it.

AI systems — especially RAG pipelines — are repeating the same mistakes we made with distributed systems a decade ago.

They look fine.
They respond fast.
They return answers.

And yet — they are quietly wrong.

This article explains:

Why observability is fundamentally harder in AI systems
What observability actually means for RAG pipelines
What signals matter (and which ones don’t)
How mature teams design observable AI systems

No dashboards for the sake of dashboards — only what helps you debug reality.

Why AI Observability Is Different From Traditional Observability

In classic systems, we observe:

CPU
memory
latency
error rates

In AI systems, the hardest failures are:

Semantic
Probabilistic
Contextual

A RAG pipeline can:

return HTTP 200
respond in 300ms
use the correct model

…and still give a wrong answer.

That’s why AI observability must go deeper.

The Core Problem With RAG Pipelines

A basic RAG flow looks like this:

User Query
↓
Embedding
↓
Vector Search
↓
Top-K Chunks
↓
Prompt Assembly
↓
LLM Generation

When the output is wrong, where did it fail?

Bad query?
Wrong chunks?
Missing chunks?
Prompt formatting?
Model hallucination?

Without observability, you’re guessing.

What “Observability” Means in the AI World

AI observability is the ability to answer:

Why did the system produce this answer for this input at this time?

That requires traceability, not just metrics.

The Four Pillars of RAG Observability

1️⃣ Query Observability

You must log:

Original user query
Rewritten / normalized query (if any)
Detected intent or routing decision

Why it matters

Many failures start with:

ambiguous questions
underspecified intent
bad query rewriting

If you can’t see the effective query, you can’t debug retrieval.

2️⃣ Retrieval Observability (Most Important)

This is where most RAG systems fail.

You should observe:

Retrieved chunk IDs
Source documents
Similarity scores
Chunk rank
Retrieval strategy used (vector, keyword, hybrid)

Example questions observability should answer:

Which chunks were retrieved?
Which chunk influenced the answer most?
Was relevant information missing?

If you don’t log retrieved chunks, you don’t have RAG observability.

3️⃣ Prompt Observability

Your prompt is your runtime program.

You must capture:

Final prompt sent to the LLM
Context size and token count
Chunk ordering
System instructions

Why?
Because subtle changes in:

ordering
truncation
formatting

can completely change answers.

4️⃣ Generation & Answer Observability

Beyond the final answer, log:

Model name & version
Temperature / decoding params
Token usage
Latency
Safety or refusal triggers

Advanced systems also track:

Answer confidence
Self-evaluation scores (Self-RAG)
Groundedness signals

The Most Common RAG Failure Modes (Seen in Production)

❌ “The model hallucinated”

Usually false.

More often:

Wrong chunk retrieved
Right chunk ranked too low
Context truncated
Outdated document used

Observability makes this visible.

❌ “Vector search is bad”

Often:

Chunking is wrong
Embedding mismatch
Query rewriting failed

Again — visible with the right signals.

Tracing a Single RAG Request (What Good Looks Like)

A single request trace should show:

Request ID: 9f23...

Query:
"Can I carry forward unused leave?"

Rewritten Query:
"Leave carry forward policy Australia"

Retrieved Chunks:

handbook.md#leave-carry-forward (score: 0.89)

policy.md#exceptions (score: 0.81)

Prompt Tokens:
3,214

Model:
gpt-4.1-mini

Answer:
"Yes, up to 10 days can be carried forward..."

Confidence:
High

If you can’t reconstruct this — you can’t debug.

Why Traditional Metrics Are Not Enough

Latency and cost are necessary — but insufficient.

AI systems need semantic metrics:

Groundedness
Faithfulness
Retrieval coverage
Answer stability over time

These are harder — but essential.

Observability Enables Advanced RAG Patterns

You cannot safely implement:

Adaptive RAG
Corrective RAG
Self-RAG

without observability.

Why?
Because all of them rely on feedback signals:

Was retrieval good?
Was the answer grounded?
Should we retry?

No signals → no control loop.

A Simple Observability Checklist

If you’re building RAG in production, you should be able to answer:

Which document influenced this answer?
Why was this chunk chosen over others?
What changed compared to yesterday?
Would a different retrieval strategy help?
Can I replay this request?

If the answer is “no” — observability is missing.

Final Thought

RAG pipelines don’t usually fail loudly.

They fail:

quietly
confidently
at scale

The future of AI systems isn’t just better models.

It’s systems that can explain themselves.

And observability is how that starts.

If you’ve debugged a RAG issue that turned out to be “invisible” at first, I’d love to hear what signal finally revealed it.

Self-RAG vs Adaptive RAG vs Corrective RAG

Parth Sarthi Sharma — Thu, 22 Jan 2026 11:24:30 +0000

How Retrieval Systems Are Learning to Fix Themselves

Retrieval-Augmented Generation (RAG) started simple:

Retrieve documents → add them to the prompt → generate an answer.

That worked… until it didn’t.

As RAG systems moved into production, teams began to see the same failures again and again:

Hallucinations despite having “good” data
Irrelevant chunks polluting the prompt
Silent failures that were hard to debug
High token costs with low answer quality

The response wasn’t just better embeddings.

It was smarter control loops.

That’s how Self-RAG, Adaptive RAG, and Corrective RAG emerged.

They all share one idea:

RAG shouldn’t be static.

It should reason about its own failure.

But they solve different layers of the problem.

The Core Problem With Traditional RAG

Classic RAG makes three assumptions:

The user query is well-formed
Retrieved chunks are relevant
More context leads to better answers

In reality:

Queries are vague or underspecified
Vector search returns plausible but wrong chunks
LLMs answer confidently even when context is poor

Traditional RAG has no self-awareness.

Modern RAG patterns add it.

Self-RAG: “Should I Even Answer This?”

What it is

Self-RAG teaches the model to evaluate its own generation using explicit self-reflection.

Instead of blindly answering, the model asks:

Did I actually use the retrieved context?
Is this answer supported by evidence?
Should I revise, regenerate, or refuse?

How it works (conceptually)

Retrieve documents
Generate a draft answer
Run self-critique prompts such as:
- Is this answer grounded in the retrieved text?
- Is there missing or contradictory information?
Regenerate or abstain if confidence is low

What it’s good at

Reducing hallucinations
Citation-aware answers
Knowledge-intensive question answering

Limitations

Still depends on retrieval quality
Adds latency
Reflection quality depends heavily on prompt design

Mental model

Self-RAG adds a judge after generation.

Adaptive RAG: “Do I Even Need Retrieval?”

What it is

Adaptive RAG dynamically changes the pipeline itself based on the query.

Instead of:

Always retrieve → always generate

It asks:

Is retrieval needed at all?
How much context is enough?
Should the query be rewritten?

Typical adaptations

Skip retrieval for simple or well-known facts
Increase retrieval depth for complex queries
Rewrite ambiguous questions
Route between different tools (search, DB, memory)

Why this matters

Many RAG systems are:

Over-fetching
Overstuffing prompts
Burning tokens unnecessarily

Adaptive RAG optimizes for cost and accuracy.

Mental model

Adaptive RAG adds a router before retrieval.

Corrective RAG: “Something Went Wrong — Fix It”

What it is

Corrective RAG focuses on detecting and repairing retrieval failures.

It assumes failure is inevitable and designs for recovery.

Common corrective strategies

Detect low-quality or irrelevant chunks
Drop contradictory context
Trigger re-retrieval with a refined query
Switch retrieval strategies (BM25 ↔ vector search)

Key difference from Self-RAG

Self-RAG critiques the answer
Corrective RAG critiques the context

Why this matters

In production, most RAG failures come from:

Wrong chunks
Missing chunks
Outdated information

Corrective RAG attacks the root cause.

Mental model

Corrective RAG adds a repair loop around retrieval.

Putting It All Together

These approaches are not competing ideas.

They are layers.

A mature RAG system often looks like this:

User Query
↓
Adaptive Router (Do we retrieve? How?)
↓
Retrieval
↓
Corrective Check (Are these chunks good?)
↓
Generation
↓
Self-RAG Evaluation (Is this answer grounded?)
↓
Final Response (or retry / refuse)

Each layer addresses a different failure mode.

Why This Matters in Real Systems

If you’re building:

Enterprise search
Customer support assistants
Internal knowledge bots
Agentic workflows

Static RAG will fail — often quietly.

The future of RAG is not:

Bigger models or longer prompts

It is:

Systems that know when they are wrong.

Final Thought

RAG is evolving from a simple pipeline into a control system.

The teams that succeed won’t be the ones with the largest models —

but the ones with the tightest feedback loops.

If you’re experimenting with Self-RAG, Adaptive RAG, or Corrective RAG in production,

I’d love to hear what worked (or broke) for you.

LangChain vs LangGraph vs Semantic Kernel vs Google AI ADK vs CrewAI

Parth Sarthi Sharma — Tue, 20 Jan 2026 12:57:54 +0000

Choosing the Right LLM Framework Without the Hype

The LLM ecosystem is moving fast. Every few weeks, a new framework promises to “simplify AI agents,” “orchestrate reasoning,” or “make production-ready AI easy.”

But if you’re building real systems, you’ve probably asked:

Why do I need so many frameworks for what feels like the same thing?

I’ve worked with multiple LLM stacks and this article is my attempt to cut through the noise and explain:

What problem each framework actually solves
Where they shine
Where they become liabilities
Which one you should choose depending on your use case

This is not a feature checklist. It’s a mental model.

The Big Picture: What Problem Are We Solving?

All these frameworks exist because LLMs are not applications.
They are components.

Real-world LLM systems need:

Prompt orchestration
Tool calling
Memory
Retrieval (RAG)
Control flow
Observability
Failure handling

Each framework makes different trade-offs around these problems.

LangChain: The Swiss Army Knife (and its curse)

What it is:
LangChain is a high-level abstraction layer for building LLM-powered apps quickly.

What it does well:

Rapid prototyping
Huge ecosystem of integrations
Easy chaining of prompts, tools, retrievers
Strong community momentum

Where it struggles:

Hidden control flow
Debugging is painful at scale
Abstractions leak under complex logic
Performance tuning is hard

When to use LangChain

MVPs
Hackathons
POCs
Teams new to LLMs

When to avoid

Complex, stateful workflows
Systems needing precise control or observability

LangChain is optimized for speed of development, not clarity of execution.

LangGraph: When You Realize LLMs Are State Machines

What it is:
LangGraph is LangChain’s answer to the criticism: “LLM workflows aren’t linear.”

It models AI systems as graphs instead of chains.

What it does well:

Explicit state transitions
Cycles, retries, branching
Long-running agents
Better reasoning visibility

Trade-offs:

More complex mental model
Still tied to LangChain ecosystem
Steeper learning curve

When LangGraph shines

Multi-step agents
Tool-heavy workflows
Systems with retries and loops
Human-in-the-loop scenarios

LangGraph is what you reach for when LangChain starts to feel “magical.”

Semantic Kernel: Engineering-first, AI-second

What it is:
Microsoft’s take on LLM orchestration, designed for software engineers, not prompt hackers.

Key strengths:

Strong typing
Explicit planners
Native support for C# and Python
Enterprise-friendly architecture

Weaknesses:

Smaller ecosystem
Less “plug-and-play”
Slower iteration for experiments

Best fit

Enterprise teams
Strong engineering discipline
Systems that need maintainability over speed

Semantic Kernel feels like it was designed by people who maintain systems at 3am.

Google AI ADK: Opinionated and Cloud-native

What it is:
Google’s Agent Development Kit focuses on structured agent workflows, tightly integrated with Google Cloud and Gemini.

Strengths:

Clear agent lifecycle
Strong observability hooks
Cloud-native design
Production-aligned abstractions

Limitations:

Less flexible outside Google’s ecosystem
Smaller open-source community (for now)
More opinionated architecture

Best fit

Teams already on GCP
Production-first AI systems
Regulated or large-scale environments

ADK assumes you care about deployment and monitoring from day one.

CrewAI: The “Multi-Agent” Narrative

What it is:
CrewAI focuses on orchestrating multiple agents with roles, mimicking human teams.

What it’s good at:

Role-based agent design
Easy mental model
Content generation pipelines

Where it falls short:

Limited control
Less suitable for complex state handling
Not ideal for deeply engineered systems

Use CrewAI if

You’re building collaborative agent demos
Content or research workflows
Experimenting with agent behavior

CrewAI is great for storytelling, not systems engineering.

A Practical Decision Framework

Instead of asking “Which framework is best?”, ask:

1. Do I need speed or control?

Speed → LangChain
Control → Semantic Kernel / LangGraph

2. Is this production-critical?

Yes → Semantic Kernel / Google ADK
No → LangChain / CrewAI

3. Is the workflow stateful and complex?

Yes → LangGraph
No → LangChain

4. Enterprise or startup?

Enterprise → Semantic Kernel / ADK
Startup → LangChain

The Uncomfortable Truth

Most mature AI teams eventually:

Start with LangChain
Outgrow it
Move to custom orchestration or graph-based systems

Frameworks should accelerate learning, not lock you in.

Final Thought

LLM frameworks are evolving because we still don’t fully understand how to engineer AI systems.

Choose tools that:

Make failure visible
Encourage explicit design
Don’t hide complexity forever

Because eventually, complexity always shows up.

If this helped you think more clearly about the LLM ecosystem, feel free to share or comment with your experience. I’d love to learn how others are navigating this space.

Local RAG vs Cloud RAG: What Changes When You Leave the Demo

Parth Sarthi Sharma — Mon, 12 Jan 2026 11:25:38 +0000

Local RAG feels free.
Until your first production incident.

If you’ve built any RAG system recently, chances are it started locally.

A small dataset.
A local vector store.
Fast queries.
Clean answers.

Everything feels under control.

And for a while — it is.

This article is about what quietly changes when RAG systems move from demos to real usage, and why the Local vs Cloud RAG decision is less about tools and more about operational guarantees.

Why Local RAG Feels Like the Right Choice (At First)

Local RAG optimises for exactly what you want early on:

Zero infra friction
Near-zero cost
Tight iteration loops
Full control over data and logic

You can:

Restart the process
Rebuild the index
Tune chunk sizes
Experiment freely

For:

Prototypes
POCs
Internal tools
Early-stage features

Local RAG is not just acceptable — it’s ideal.

So where does it go wrong?

The Problem: Local RAG Doesn’t Fail Loudly

Local RAG rarely explodes.

It degrades.

Slowly.

Subtly.

In ways that are hard to reproduce.

At first:

One user
Sequential queries
Index fits comfortably in memory

Then usage grows:

Concurrent requests increase
Memory pressure rises
Index rebuilds take longer
Latency becomes inconsistent

Nothing is “broken”.

But the system becomes unpredictable.

And unpredictability is the worst failure mode in production.

What Actually Breaks First (And Surprises Teams)

1. Concurrency

Most local vector stores are optimised for:

Single-process access
Limited parallelism

Under load:

Queries queue
Writes block reads
Latency spikes

2. Memory & Resource Contention

Local RAG competes with:

The app runtime
The LLM client
Other background processes

A single spike can:

Trigger OOM
Kill the process
Lose in-memory state

3. Index Lifecycle Management

Rebuilding indexes locally often means:

Blocking reads
Restarting services
Manual intervention

This is fine once. It’s painful at scale.

Why Teams Jump to Cloud RAG Too Early

On the flip side, many teams move to cloud RAG before they need to.

Common reasons:

Fear of future scale
“Production readiness” anxiety
Over-indexing on best practices

The result:

Paying for capacity you don’t use
Higher baseline latency
Vendor lock-in decisions too early

Cloud RAG is not “better RAG”. It’s RAG with guarantees.

And guarantees come with cost.

What Cloud RAG Actually Buys You

Cloud-managed RAG systems exist to solve operational problems, not retrieval quality.

They give you:

Concurrency handling
Persistence and durability
Observability hooks
Backups and recovery
Predictable performance envelopes

What they don’t magically fix:

Poor chunking
Bad retrieval logic
Overstuffed prompts
Weak context engineering

If ingestion is broken locally, it will be broken in the cloud — just more expensively.

The Real Decision Axis (This Is the Key)

The Local vs Cloud RAG decision is not about:

Chroma vs Pinecone
FAISS vs Weaviate

It’s about answering four questions honestly:

How many concurrent users do I expect?
How painful is downtime or degraded answers?
Do I need observability and auditability?
How often will my index change?

Local RAG optimises for:

Speed
Control
Learning

Cloud RAG optimises for:

Reliability
Predictability
Scale

Neither is “correct” in isolation.

A Practical Migration Pattern That Works

Mature teams rarely jump straight from local to fully managed cloud RAG.

Instead, they:

Start local
Learn their retrieval patterns
Stabilise chunking and routing
Introduce cloud RAG only when operational pain appears

This keeps:

Cost low early
Architecture flexible
Decisions reversible

Final Takeaway

Local RAG fails quietly.
Cloud RAG fails expensively.

The right choice depends on when you’re willing to pay:

With engineering effort
Or with infrastructure cost

The worst choice is deciding too early — in either direction.

What’s Next

In the next article, we’ll dive into one of the most under-discussed problems in RAG systems:

Observability in RAG Pipelines: Knowing Which Chunk Failed (and Why)

We’ll explore:

Why “LLM hallucinated” is usually a monitoring failure
What should be traced in a RAG request (retrieval, ranking, prompt, tokens)
How to identify:

Wrong chunk retrieval
Empty or partial context
Latency bottlenecks
Silent failures in agents and tools

How tools like OpenTelemetry, LangSmith, and custom tracing fit together

Because you can’t fix what you can’t see — and most RAG systems today are completely blind.