DEV Community: Anil Prasad

Title: I Built an AI Governance Proxy in 72 Hours. Here Is Exactly How.

Anil Prasad — Wed, 01 Jul 2026 14:01:00 +0000

Liquid syntax error: 'raw' tag was never closed

I built a zero-dependency PII scanner for AI prompts in 270 lines of Python

Anil Prasad — Fri, 26 Jun 2026 12:45:00 +0000

TL;DR — AgentMesh 0.3.2 ships a PII/PHI/PCI scanner that runs on every AI prompt before it reaches the model. 17 entity types. Under 2ms. No external API. No cloud service. Pure Python regex with Luhn validation and overlap deduplication. Three enforcement modes: mask, redact, block. pip install agentmesh-proxy

The problem

Your AI agents and tools are sending raw sensitive data to the LLM vendor.

Medical record numbers in clinical AI prompts. Credit card numbers in finance team workflows. AWS access keys in developer debug pastes. Social security numbers in HR automation.

The people doing this are not making bad decisions. They are using the tools available to them. The problem is that there is no layer between the prompt and the model that catches sensitive data first.

I built that layer into AgentMesh. Here is how it works.

What it catches

![17 entity types caught before the LLM]

17 entity types across four categories:

PII — personal identity

SSN: 567-89-0123 → [SSN]
Date of birth: 07/22/1985 → [DOB]
Email: sarah.johnson@gmail.com → [EMAIL]
Phone: (415) 867-5309 → [PHONE_US]
Passport: Passport no: US123456789 → [PASSPORT]

PCI — payment card and financial data

Visa: 4532 1234 5678 9012 → [PCI_CARD]
Amex: 3714 496353 98431 → [PCI_CARD]
Mastercard: 5500 0055 0000 0004 → [PCI_CARD]
CVV: CVV 394 → [PCI_CVV]
Routing: Routing: 021000021 → [PCI_ROUTING]
Account: Account: 000123456789 → [PCI_ACCOUNT]

PHI — HIPAA-protected medical data

Medical record: MRN: P-987654 → [PHI_MRN]
ICD-10 diagnosis: E11.9 → [PHI_ICD10]
Medication dosage: 10mg lisinopril → [PHI_DOSAGE]
Provider ID: NPI: 1234567890 → [PHI_NPI]

CII — cloud credentials and infrastructure

AWS key: AKIAIOSFODNN7EXAMPLE → [CII_AWS_KEY]
JWT token: eyJhbGci... → [CII_JWT]

Quick start

pip install agentmesh-proxy

from agentmesh.security.pii_scanner import PIIScanner, ScanMode

scanner = PIIScanner(mode=ScanMode.MASK)

result = scanner.scan(
    "Patient MRN: P-987654, email: sarah@example.com, "
    "card: 4532 1234 5678 9012, key: AKIAIOSFODNN7EXAMPLE"
)

print(result.cleaned)
# Patient MRN: [PHI_MRN], email: [EMAIL],
# card: [PCI_CARD], key: [CII_AWS_KEY]

print(result.finding_types)
# ['CII_AWS_KEY', 'EMAIL', 'PCI_CARD', 'PHI_MRN']

For scanning a list of {role, content} messages (OpenAI format):

messages = [
    {"role": "user", "content": "SSN 123-45-6789, card 4532 1234 5678 9012"}
]

cleaned_messages, findings = scanner.scan_messages(messages)
print(cleaned_messages[0]["content"])
# SSN [SSN], card [PCI_CARD]

Three enforcement modes

from agentmesh.security.pii_scanner import PIIScanner, ScanMode, PIIDetectedError

# MASK: replace with labeled placeholder — model still gets a useful prompt
scanner = PIIScanner(mode=ScanMode.MASK)
result = scanner.scan("SSN 123-45-6789")
print(result.cleaned)  # "SSN [SSN]"

# REDACT: replace with *** — when even the label is too much context
scanner = PIIScanner(mode=ScanMode.REDACT)
result = scanner.scan("SSN 123-45-6789")
print(result.cleaned)  # "SSN ***"

# BLOCK: raise PIIDetectedError — zero tolerance, reject the request
scanner = PIIScanner(mode=ScanMode.BLOCK)
try:
    scanner.scan("SSN 123-45-6789")
except PIIDetectedError as e:
    print(e.findings)  # [Finding(entity_type='SSN', ...)]
    # Return HTTP 400 to the caller

Engineering decisions worth explaining

Why regex over an NLP model?

Speed. The scan runs in under 2ms. An NLP-based entity recognizer adds 50ms to 200ms per call and requires a model download. For a proxy that sits in the path of every LLM call, 2ms is acceptable and 200ms is not.

The tradeoff is recall. Regex will miss creative obfuscation. For governance purposes — where the goal is catching accidental leakage, not adversarial attacks — regex is the right tool.

The credit card validation decision

Standard implementations run Luhn validation on card numbers and only mask numbers that pass. We run in strict_pci=True mode by default:

# In PIIScanner.__init__:
# strict_pci=True (default): mask any card-shaped number (13-19 digits)
# even if it fails the Luhn check.
# Rationale: governance proxies should over-mask rather than under-mask.
# A false positive costs one masked token.
# A false negative sends a real card number to the vendor.
self.strict_pci = strict_pci

If you prefer Luhn validation only:

scanner = PIIScanner(mode=ScanMode.MASK, strict_pci=False)

The overlap deduplication problem

This one took a few iterations to get right.

Consider a prompt containing MRN: A1234567. The PHI_MRN pattern matches the whole span. The PASSPORT pattern (before it required a passport: prefix) would also match the A1234567 part.

If you apply replacements in reverse order by start position — which is the standard approach to keep earlier offsets valid — and the inner match gets processed first, it replaces 8 characters with 10 ([PASSPORT]). The outer match then tries to cut at the original end offset, which now points into the middle of [PASSPORT], producing [PHI_MRN]T].

The fix:

def _dedup_overlapping(findings: List[Finding]) -> List[Finding]:
    # Sort by start position, then by length descending (outermost first).
    # Walk forward and drop any finding whose start is inside the
    # previous kept finding's range.
    sorted_f = sorted(findings, key=lambda f: (f.start, -(f.end - f.start)))
    result: List[Finding] = []
    last_end = -1
    for f in sorted_f:
        if f.start >= last_end:
            result.append(f)
            last_end = f.end
    return result

Keep the outermost match. Drop everything whose start position falls inside it. Apply replacements in reverse order on the deduplicated list. No artifacts.

Wiring it into the proxy

If you are running AgentMesh as a proxy rather than calling the scanner directly, activate it in config:

# agentmesh.yaml
pii_mode: mask           # mask | redact | block
block_injections: true   # prompt injection detection (14 rules)
anomaly_detection: true  # runaway loop + burn rate monitoring
slack_webhook: ""        # optional: alert destination

agentmesh serve --config agentmesh.yaml --port 8080

Point your agents at it:

export OPENAI_BASE_URL=http://localhost:8080/v1
export ANTHROPIC_BASE_URL=http://localhost:8080

Every call going through the proxy now gets scanned. The response includes a header showing what was found:

X-AgentMesh-PII-Findings: 4
X-AgentMesh-Cache: miss
X-AgentMesh-Cost-USD: 0.000420

The Chrome extension

A server-side proxy cannot intercept prompts typed directly into the ChatGPT or Claude.ai browser tab. For that there is a Chrome extension — same scanner, running locally in the browser process before the request leaves the tab.

Google approved it last weekend.

Install from the Chrome Web Store (link in the repo readme) or build from source. Works with ChatGPT, Claude.ai, Gemini, Perplexity, and Cursor. No server required for standalone use.

HIPAA in production

If your team uses AI in a clinical setting, the PHI scanner is the piece that matters most. ICD-10 codes are two to five characters but identify specific diagnoses. Combined with a medical record number and a provider NPI, they reconstruct a patient record from a prompt.

AgentMesh also generates HIPAA readiness reports:

from agentmesh.compliance.pdf_report import ComplianceReporter, Framework

reporter = ComplianceReporter()
markdown = reporter.generate_markdown(Framework.HIPAA)
# or
reporter.generate_pdf(Framework.HIPAA, output_path="hipaa_report.pdf")

Outputs a structured report listing which controls are active, which are not, and what gaps remain. Useful for security reviews before a compliance audit.

Try it

pip install agentmesh-proxy

from agentmesh.security.pii_scanner import PIIScanner, ScanMode

scanner = PIIScanner(mode=ScanMode.MASK)
result = scanner.scan("your prompt here")
print(result.cleaned)
print(result.finding_types)

The scanner is in agentmesh/security/pii_scanner.py. About 270 lines. No external dependencies beyond the Python standard library.

Repo: https://github.com/anilatambharii/agentmesh
PyPI: agentmesh-proxy
Docker: docker pull anilsprasad/agentmesh:latest
Apache 2.0.

What entity types would you add? What patterns are you seeing in your team's prompts that are not covered here?

Find me: anilsprasad.com · X @anilsprasad · LinkedIn

I put one proxy in front of every AI tool my team uses 85% cache hits, 75% lower cost

Anil Prasad — Sun, 14 Jun 2026 22:30:49 +0000

TL;DR — Your team's AI tools (Claude Code, Copilot, ChatGPT, Gemini, your own agents) each call the LLM API independently — no shared cache, no shared budget, no audit trail. AgentMesh is an open-source proxy that sits in front of all of them and runs every call through a three-layer cache, per-team quotas, cheapest-model routing, and a tamper-evident audit log. You point your tools at it with two env vars. On a reproducible benchmark (no API keys): 85% cache hits, 75% lower cost. Apache 2.0. → pip install agentmesh-proxy

The problem, in one sentence
Every AI tool on your team talks to the model on its own.
Claude Code has its own connection. Copilot has its own. The ChatGPT tab in someone's browser has its own. Your LangGraph service has its own. None of them share a cache, a budget, or an audit log — so the same prompt gets paid for over and over, a runaway loop in one service is invisible to the others, and nobody can answer "what did we send to third-party APIs last quarter?"
This isn't a discipline problem. It's a missing layer. So I built it.

60-second quickstart

pip install agentmesh-proxy sentence-transformers
agentmesh serve --port 8080 --demo

Point any tool at it — no code changes:

# Claude Code, or any Anthropic SDK tool
export ANTHROPIC_BASE_URL=http://localhost:8080

# Copilot / Cursor / any OpenAI SDK tool
export OPENAI_BASE_URL=http://localhost:8080/v1

Every response comes back with governance headers so you can see what happened:

X-AgentMesh-Cache:     hit          # exact | semantic | miss
X-AgentMesh-Tokens:    0            # 0 on a cache hit
X-AgentMesh-Cost-USD:  0.000000     # $0 on a cache hit

That's the whole integration. The agent code never knows the proxy is there.

How it works
Every call from the proxy or the SDK runs the same ordered pipeline:

The interesting part is the cache, because it does something most "LLM caches" don't.

Exact-match caching almost never hits in real life, because people rephrase: they paste You are a senior architect. in front of the question, switch between optimise and optimize, wrap things in markdown. So before anything is hashed or embedded, AgentMesh normalizes the prompt — stripping the noise that doesn't change meaning:

from agentmesh.optimizer.normalizer import normalize_prompt

normalize_prompt("You are a senior architect. **Please** review this design...")
# -> "review this design ..."   (persona prefix, markdown, filler removed)

compares by cosine similarity:

from agentmesh import SemanticCache

cache = SemanticCache(similarity_threshold=0.70)   # tune per workload
cache.put("Review this microservices design for scaling issues", response)

# Different wording, same intent -> still a hit
hit = cache.get("Analyze this distributed system design")

normalize, then embed is the whole trick — it's the difference between a cache that almost never hits and one that hits ~85% of the time.

And because every call already flows through one interceptor, a tamper-evident audit log is almost free — each entry is hash-chained (SHA-256) and signed with Ed25519:

from agentmesh import AuditTrail
trail = AuditTrail()
# ... calls happen ...
assert trail.verify()   # walks the chain, checks every prev_hash + signature

The benchmark (run it yourself, no API keys)

I didn't want to ship a number you can't check, so the benchmark runs in demo mode:

python examples/benchmark.py

Total requests          20
Exact cache hits         2  (10%)
Semantic cache hits     15  (75%)
Total misses             3  (15%)

Cost WITHOUT AgentMesh  $0.0030
Cost WITH AgentMesh     $0.0008
Savings                 $0.0023  (75%)

20 requests, 5 topics, 4 phrasings each. 85% never reached the model; the 3 misses are the cold-start first call per topic — exactly what you'd expect.

There's also a Chrome extension
A proxy can't see a prompt typed straight into the ChatGPT or Gemini tab. So there's an extension: declarativeNetRequest reroutes api.anthropic.com / api.openai.com to localhost:8080, and content scripts show a governance overlay before the prompt is sent. Stats persist across service-worker restarts.

What's deliberately not built yet

I'd rather ship a small, verifiable core than a wide surface of half-features:

The cache is in-memory, single-process **— great for a local proxy, not yet a fleet. **Redis is next.
No native VS Code panel (env vars + the Chrome extension for now).
No SAML/SSO identity propagation; quotas key on a team header.

None of these are research problems — they're scope. PRs welcome, especially the Redis backend.
Try it / contribute

pip install agentmesh-proxy sentence-transformers
python examples/benchmark.py     # 85% cache hits, 75% lower cost

Repo (star it): https://github.com/anilatambharii/agentmesh
PyPI: agentmesh-proxy · Docker: anilsprasad/agentmesh · also on Hugging Face
Apache 2.0

If you run AI tools across a team and your bill is outgrowing your usage, clone it, run the benchmark, and tell me where it breaks. What would you build on top of this?

How I took a production RAG pipeline from 61% to 97% accuracy (6 stages, full code)

Anil Prasad — Fri, 12 Jun 2026 12:30:00 +0000

Six months in production on a healthcare RAG system. Four rewrites. Here is the exact pipeline, every stage, and the code. The reference implementation is open source and linked at the bottom.

TL;DR
A weekend tutorial got our retrieval system to 61% accuracy. Six months of production work got it to 97%, under 2 seconds at P99, at $0.08 per query. The gains came from six stages added in order of return, not from a better model. Here is each one with code you can drop into your own pipeline.
If you only have five minutes, here is the whole thing:

Query rewriting turns vague questions into searchable ones. +11 points. Almost free.
Hybrid retrieval runs dense + BM25 and fuses them. +9 points.
Cross-encoder reranking rescores the top candidates properly. +8 points.
Context compression strips irrelevant sentences before generation. +5 points.
Citation guard blocks any claim that is not grounded in a source.
Answer validation routes multi-hop questions to a human instead of guessing.

First, measure where you actually fail
Before writing any code, we instrumented the pipeline and traced every wrong answer to its cause. The result changed our entire roadmap.

64% of failures were retrieval. 23% were chunking. Only 13% were the generator hallucinating from good context. We had spent two months tuning prompts, which was 13% of the problem. Lesson one: measure before you optimize, because your intuition about where RAG breaks is almost always wrong.

Stage 1: query rewriting

The user's raw message is rarely a good search query. What did it say about the dosage? has no good match in any index, because the meaning is in the previous turns. A small 8B model rewrites it into a standalone query first.

REWRITE_SYSTEM = """You rewrite a user's latest message into a single,
standalone search query. Resolve all pronouns and references using the
conversation. Keep it specific. Output only the rewritten query."""

def rewrite_query(history: list[dict], latest: str, llm) -> str:
convo = "\n".join(f"{m['role']}: {m['content']}" for m in history[-4:])
prompt = f"{convo}\nuser: {latest}\n\nStandalone search query:"
out = llm.complete(
system=REWRITE_SYSTEM, prompt=prompt,
model="small-8b", max_tokens=64, temperature=0.0,
).strip()
return out or latest

Cost: about $0.0001 per query. Gain: +11 points, from 61% to 72%. This is the highest return change in the entire pipeline and the one most people skip.

Stage 2: hybrid retrieval

Embedding similarity is great at meaning and weak at exact terms. Two passages can be close in vector space and mean opposite things. Keyword search has the opposite failure mode. So run both and fuse with reciprocal rank fusion, which needs no weight tuning.

from rank_bm25 import BM25Okapi

def hybrid_search(query, dense_index, bm25: BM25Okapi, corpus, k=20):
dense_hits = dense_index.search(query, k=k) # [(doc_id, score)]
bm25_scores = bm25.get_scores(query.split())
bm25_hits = sorted(enumerate(bm25_scores),
key=lambda x: x[1], reverse=True)[:k]

fused, C = {}, 60
for rank, (doc_id, _) in enumerate(dense_hits):
    fused[doc_id] = fused.get(doc_id, 0) + 1 / (C + rank)
for rank, (doc_id, _) in enumerate(bm25_hits):
    fused[doc_id] = fused.get(doc_id, 0) + 1 / (C + rank)

ranked = sorted(fused.items(), key=lambda x: x[1], reverse=True)
return [corpus[doc_id] for doc_id, _ in ranked[:k]]

Gain: +9 points, from 72% to 81%. Dense and sparse retrieval are not competitors. Use both.

Stage 3: cross-encoder reranking

Stages 1 and 2 are fast because they score the query and each document independently. A cross-encoder reads them together, which is slower and much more accurate. So you run it only on the top candidates the cheap stages already found.

from sentence_transformers import CrossEncoder

reranker = CrossEncoder("cross-encoder/ms-marco-MiniLM-L-6-v2")

def rerank(query, candidates, top_n=5):
pairs = [(query, c.text) for c in candidates]
scores = reranker.predict(pairs)
ranked = sorted(zip(candidates, scores), key=lambda x: x[1], reverse=True)
return [c for c, _ in ranked[:top_n]]

Gain: +8 points, from 81% to 89%. The classic retrieve-then-rerank pattern, and it earns its cost because you only rerank a handful of candidates.

Stage 4: context compression

A retrieved passage can be the right document and still carry sentences that have nothing to do with the question. Each irrelevant sentence is a chance for the model to anchor on the wrong thing. So score sentences against the query and drop the ones that do not earn their place.

def compress_context(query, passages, relevance_model, threshold=0.5):
kept = []
for p in passages:
sentences = split_sentences(p.text)
scored = relevance_model.score(query, sentences) # 0..1 per sentence
relevant = [s for s, sc in zip(sentences, scored) if sc >= threshold]
if relevant:
kept.append(p.with_text(" ".join(relevant)))
return kept

Gain: +5 points, from 89% to 94%. Bonus: it cuts your generation token bill, because you stop paying to send the model context it should ignore.

The pipeline so far

Stages 1 through 4 took us from 61% to 94%. The last two stages do not chase points. They make the system honest, which in a regulated domain matters more.

Stage 5: citation guard

Before an answer ships, every claim in it has to trace back to a retrieved source. If a sentence has no supporting passage, it does not go out.

def citation_guard(answer_claims, sources, entailment_model, min_support=0.7):
for claim in answer_claims:
support = max(entailment_model.entails(s.text, claim) for s in sources)
if support < min_support:
return False, claim # ungrounded claim, block it
return True, None

Stage 6: answer validation

Some questions need three or more documents synthesized together. That is where RAG quietly fails by writing a fluent, wrong answer. Detect those and route them to a human.

def validate_answer(query, answer, sources, confidence):
if confidence < 0.6:
return route_to_human(query, reason="low confidence")
if requires_multi_hop(query) and len(sources) < 2:
return route_to_human(query, reason="insufficient evidence")
return answer

Together stages 5 and 6 took the production number from 94% to 97%. The real output is not the three points. It is the 3% the system now refuses to answer automatically. Serving an uncertain answer is not honesty. It is a liability.

And the climb, stage by stage:

How to adopt this
You do not need a six-month rebuild. Add stages in order of return and measure after each one, so you know which change earned which points.

Query rewriting first. A day of work, nearly free to run.
Hybrid retrieval next, because most teams run embeddings only.
Reranking third.

Compression fourth.

Build the guards last, once accuracy is where you want it.

Run it yourself

The full reference implementation is open source, including every stage above, the benchmark harness that produced these numbers, and a 250-case adversarial test suite that caught the failures we did not anticipate. Clone it and run it today.

github.com/anilatambharii

I write up the production AI work in more depth, with the narrative and the failures, on my newsletter first. If the deep version is useful to you, that is where it lives: anilsprasad.substack.com

If you are running RAG in production, I would like to know one thing in the comments: what does your error breakdown look like? Retrieval, chunking, or generation? I read all of them.

HumanWritten #ExpertiseFromField

How We Cut AI Infrastructure Costs by 94% Without Sacrificing Quality (And How You Can Too)

Anil Prasad — Mon, 01 Jun 2026 15:00:00 +0000

A production engineer's guide to building efficient AI systems at scale - complete with code, architecture, and real metrics

series: Production AI Infrastructure

📧 Originally published on my Substack newsletter where I share weekly deep-dives on production AI infrastructure. Subscribe for early access to future articles!

Three months ago, our AI infrastructure bill was $47,000 per month.

Last month? $2,800.

Same quality. Same performance. Same user experience.

94% cost reduction. $530,000 saved annually.

This isn't a case study about "theoretical optimization." This is a field guide from production systems processing 2.3 million events per second, serving millions of users, and running 24/7 without downtime.

The efficiency revolution in AI is here. Small models are closing the gap with frontier models faster than anyone predicted. The race to bigger is over. The race to efficient just started.

Here's everything we learned building production AI infrastructure at scale.

PART 1: The Cost Crisis Nobody Talks About

AI infrastructure costs are spiraling out of control, and most companies don't realize it until it's too late.

The pattern is predictable:

Month 1-3: Prototype with GPT-4 or Claude. Costs are manageable ($500-2,000/month). Everyone's happy.

Month 4-6: Scale to production. Usage increases 10x. Costs jump to $15K-30K/month. Finance starts asking questions.

Month 7-9: Growth continues. Costs hit $40K-60K/month. Emergency meetings. "Can we optimize this?"

Month 10+: Either massive optimization effort or AI features get cut. The dream dies or the budget explodes.

We've seen this pattern across dozens of companies. The problem isn't the technology—it's the architecture.

Why AI Costs Spiral

Three core issues:

1. The "Bigger Model = Better" Myth

The default assumption: Use the biggest, most capable model for everything.

GPT-4 for summarization? Sure.
Claude 3.5 for classification? Why not.
Llama 2 70B for simple Q&A? Absolutely.

But here's the reality: Most AI workloads don't need frontier model capability.

Industry analysis shows:

<10% of AI workloads require maximum capability (complex reasoning, multi-step analysis)
30-40% can run on medium models (7B-70B parameters)
50-60% can run on small models (3B-8B parameters)

Yet 80% of companies use frontier models for 80% of workloads.

That's like using a Lamborghini for your daily commute. Expensive. Unnecessary. Wasteful.

2. Zero Caching Strategy

Every request hits the model. Even identical requests.

"What's the weather today?" → Model inference → $0.002
"What's the weather today?" (5 minutes later) → Model inference → $0.002
"What's the weather today?" (user refresh) → Model inference → $0.002

Same question. Same answer. Triple the cost.

With caching: $0.002 for the first request, $0.0001 for subsequent requests (100x cheaper).

Without caching, you're burning 70-90% of your budget on duplicate work.

3. No Routing Logic

Every request goes to the same model, regardless of complexity.

Simple query: "What time is it?" → 70B model inference
Complex query: "Analyze quarterly revenue by region and predict Q3 trends" → 70B model inference

The simple query could run on a 3B model at 1/20th the cost and 10x faster.

But without routing logic, both queries cost the same. You're overpaying for 60-80% of requests.

The Real Production Cost Breakdown

Here's what a typical $47,000/month LLM infrastructure actually looks like:

Model Inference:        $32,000 (68%)
Infrastructure:         $8,000 (17%)
Data Processing:        $4,000 (8%)
Monitoring/Logging:     $2,000 (4%)
Networking:             $1,000 (2%)
---
Total:                  $47,000/month

The opportunity: 90%+ of model inference costs are optimizable.

Not through vague "best practices." Through specific, proven architectural changes.

PART 2: The 4-Layer Optimization Stack

We rebuilt our AI infrastructure from the ground up with one principle: Make efficiency the default, not an afterthought.

The result: A 4-layer optimization stack that reduced costs by 94% while maintaining—and in some cases improving—quality and performance.

Here's how it works:

Layer 1: Semantic Caching (70% Cost Reduction)

The Problem

Users ask the same questions different ways.

"How do I reset my password?"
"I forgot my password, help"
"Password reset instructions"

Three queries. Same intent. Same answer.

Without semantic caching: 3x model calls
With semantic caching: 1x model call, 2x cache hits

How Semantic Caching Works

Instead of exact-match caching (traditional Redis), we cache by semantic similarity.

Embed the query using a small embedding model (all-MiniLM-L6-v2, 22M parameters)
Search vector DB for similar queries (cosine similarity >0.95)
Return cached response if match found
Generate + cache if no match

The Stack

Embedding model: all-MiniLM-L6-v2 (inference: <10ms, cost: negligible)
Vector DB: Qdrant (self-hosted) or Pinecone (managed) or FAISS (self-hosted)
Similarity threshold: 0.95 (adjustable based on use case)

Results in Production

Cache hit rate: 99.2%
Average cache latency: 8ms
Average cache miss latency: 340ms
Cost per cache hit: $0.00001
Cost per cache miss: $0.002

Monthly queries: 45M
Cache hits: 44.6M (99.2%)
Cache misses: 360K (0.8%)

Semantic cache cost: $446
Without cache cost: $90,000

Savings: $89,554/month (99.5% reduction on this layer)

Implementation (High-Level)

# Semantic cache check
query_embedding = embed_query(user_query)
similar_query = vector_db.search(query_embedding, threshold=0.95)

if similar_query:
    return cache.get(similar_query.id)  # Fast cache hit
else:
    response = llm_inference(user_query)  # Expensive generation
    cache.set(query_id, response)
    vector_db.insert(query_embedding, query_id)
    return response

Key Insight: Semantic caching works because users are less creative than we think. In production, 99%+ of queries are variations of questions we've already answered.

Layer 2: Redis Caching (Additional 15% Reduction)

Semantic caching handles 99% of hits. Redis caching handles the remaining 1% of frequently repeated exact queries.

Why both?

Semantic cache: Slower (8-15ms), handles similarity
Redis cache: Faster (1-3ms), handles exact matches

The Strategy

Check Redis first (exact match, 1-3ms)
If miss → Check semantic cache (similarity match, 8-15ms)
If miss → Generate response (model inference, 200-400ms)

Results

Redis hit rate on semantic misses: 95%
Average latency: 2ms
Cost per hit: $0.00001

Additional savings: $6,800/month

Combined Layer 1 + 2 Performance

Total cache hit rate: 99.7%
Average response time: 12ms (cached) vs 340ms (uncached)
Total caching cost: $7,246/month
Without caching cost: $90,000/month

Savings so far: $82,754/month (92% reduction)

Layer 3: Model Routing (Additional 12% Reduction)

Not all queries are created equal.

"What's 2+2?" shouldn't cost the same as "Analyze these 10,000 financial transactions and flag anomalies."

But without routing logic, they do.

The Solution: Complexity-based routing

Classify query complexity (using a small 1B classifier model, <5ms)
Route to appropriate model:
- Simple → 8B model (fast, cheap)
- Medium → 70B model (balanced)
- Complex → 405B model (maximum capability)

Complexity Classification

def classify_complexity(query):
    # Fast classifier model (1B parameters, <5ms inference)
    features = {
        'token_count': count_tokens(query),
        'question_type': detect_type(query),  # factual, analytical, creative
        'context_required': needs_context(query),
        'multi_step': is_multi_step(query)
    }

    complexity_score = classifier.predict(features)

    if complexity_score < 0.3:
        return 'simple'  # Route to 8B model
    elif complexity_score < 0.7:
        return 'medium'  # Route to 70B model
    else:
        return 'complex'  # Route to 405B model

Production Results

Query distribution:
- Simple (8B): 62% of queries
- Medium (70B): 28% of queries
- Complex (405B): 10% of queries

Cost comparison:
- 8B model: $0.0001/query
- 70B model: $0.001/query
- 405B model: $0.01/query

Average cost per query (with routing): $0.0008
Average cost per query (70B for all): $0.001

Savings: 20% reduction in model costs
Monthly impact: $5,600 saved

Quality Impact: Zero degradation

We A/B tested 10,000 queries:

8B model accuracy on simple queries: 97.2%
70B model accuracy on same queries: 97.4%
User-perceived difference: 0% (statistically insignificant)

Key Insight: Users can't tell the difference between 8B and 70B on simple queries. Don't overpay for capability you don't need.

Layer 4: Efficient Models (Additional 15% Reduction)

The final layer: Replace expensive models with efficient alternatives.

The Shift: Llama 2 70B → Llama 3.1 8B

Why This Works

Llama 3.1 8B (released 2024) matches Llama 2 70B (2023) performance on most tasks.

But it's:

1/9th the parameters
15x faster inference
15x cheaper at scale

Benchmark Comparison (Production Data)

Llama 2 70B:
- Parameters: 70B
- Inference latency (P99): 340ms
- Cost per 1M tokens: $0.65
- Accuracy (MMLU): 69.7%

Llama 3.1 8B:
- Parameters: 8B
- Inference latency (P99): 120ms
- Cost per 1M tokens: $0.04
- Accuracy (MMLU): 69.4%

Quality difference: 0.3% (negligible)
Speed improvement: 2.8x faster
Cost improvement: 16x cheaper

Migration Strategy

We didn't switch overnight. We tested:

Week 1-2: Shadow mode (8B runs alongside 70B, results logged but not served)
Week 3-4: A/B test (50% traffic to 8B, 50% to 70B)
Week 5-6: 90% to 8B, 10% to 70B (monitor quality)
Week 7+: 100% to 8B, 70B for exceptions only

Results

Quality degradation: 0.2% (within acceptable range)
User complaints: 0 (nobody noticed)
Speed improvement: 2.8x (users noticed this positively)
Cost reduction: 94% (from all 4 layers combined)

The Complete Stack in Production

Request Flow:
1. Check Redis (exact match) → 95% hit rate, 2ms
2. If miss → Check semantic cache → 99% hit rate, 12ms
3. If miss → Classify complexity → 5ms
4. Route to model:
   - 62% → Llama 3.1 8B
   - 28% → Llama 3.1 70B
   - 10% → Llama 3.3 405B
5. Cache response
6. Return to user

Total average latency: 15ms (cached) vs 125ms (uncached)
Total cost per query: $0.00008 (vs $0.001 before optimization)

PART 3: Complete Implementation Guide

Architecture Overview

Our production stack:

Frontend → API Gateway → Request Router
                              ↓
                  [Redis Cache Layer]
                              ↓
              [Semantic Cache (Vector DB)]
                              ↓
                  [Complexity Classifier]
                              ↓
            ┌─────────┬─────────┬─────────┐
            ↓         ↓         ↓         ↓
         8B Model  70B Model  405B Model  (Fallback)
            ↓         ↓         ↓         ↓
                  Response Aggregator
                              ↓
                      User Response

Technology Stack

Caching Layer:

Redis: Elasticache (AWS) or Redis Cloud
Vector DB: Qdrant (self-hosted) or Pinecone (managed)
Embedding model: all-MiniLM-L6-v2

Model Serving:

Inference: vLLM (optimized serving)
Infrastructure: NVIDIA A10G GPUs (cost-efficient)
Orchestration: Kubernetes + KServe

Data Pipeline:

Event streaming: Apache Kafka
Processing: Apache Flink
Metrics: Prometheus + Grafana

Monitoring:

APM: Datadog or New Relic
Logging: CloudWatch or Elasticsearch
Alerting: PagerDuty

Deployment Steps

Phase 1: Infrastructure (Week 1-2)

Set up Redis cluster (Elasticache or self-hosted)
Deploy vector database (Qdrant recommended for self-hosting)
Configure embedding model endpoint
Set up model serving infrastructure (vLLM + GPU instances)

Phase 2: Caching Implementation (Week 3-4)

Implement Redis caching layer
Deploy semantic caching with vector DB
Test cache hit rates and latency
Optimize similarity thresholds

Phase 3: Routing Logic (Week 5-6)

Train complexity classifier (or use rule-based initially)
Implement routing logic
Deploy multiple model endpoints (8B, 70B, 405B)
A/B test routing accuracy

Phase 4: Migration (Week 7-8)

Shadow mode testing (new stack runs alongside old)
Gradual traffic migration (10% → 50% → 90% → 100%)
Monitor quality and cost metrics
Rollback capability ready at all times

Phase 5: Optimization (Ongoing)

Fine-tune cache similarity thresholds
Optimize model routing logic
Monitor and reduce cache misses
Continuous cost tracking and optimization

Code Examples

Semantic Cache Implementation (Python):

from qdrant_client import QdrantClient
from sentence_transformers import SentenceTransformer
import redis
import uuid

# Initialize components
vector_db = QdrantClient(host="localhost", port=6333)
embedding_model = SentenceTransformer('all-MiniLM-L6-v2')
redis_client = redis.Redis(host='localhost', port=6379)

def query_with_semantic_cache(user_query, similarity_threshold=0.95):
    # Step 1: Check Redis (exact match)
    redis_key = f"query:{hash(user_query)}"
    cached_response = redis_client.get(redis_key)
    if cached_response:
        return cached_response.decode('utf-8'), 'redis_hit'

    # Step 2: Generate embedding
    query_embedding = embedding_model.encode(user_query)

    # Step 3: Search vector DB for similar queries
    search_result = vector_db.search(
        collection_name="query_cache",
        query_vector=query_embedding,
        limit=1,
        score_threshold=similarity_threshold
    )

    # Step 4: Return cached if similar query found
    if search_result and len(search_result) > 0:
        cached_query_id = search_result[0].id
        cached_response = redis_client.get(f"response:{cached_query_id}")
        if cached_response:
            return cached_response.decode('utf-8'), 'semantic_hit'

    # Step 5: Generate new response (cache miss)
    response = generate_llm_response(user_query)

    # Step 6: Cache response
    query_id = str(uuid.uuid4())
    redis_client.set(f"response:{query_id}", response)
    vector_db.upsert(
        collection_name="query_cache",
        points=[{
            "id": query_id,
            "vector": query_embedding.tolist(),
            "payload": {"query": user_query}
        }]
    )

    return response, 'cache_miss'

Model Routing Implementation:

def route_to_model(user_query):
    # Classify complexity
    complexity = classify_query_complexity(user_query)

    # Route based on complexity
    if complexity == 'simple':
        model = '8b_model'
        max_tokens = 256
    elif complexity == 'medium':
        model = '70b_model'
        max_tokens = 512
    else:
        model = '405b_model'
        max_tokens = 1024

    # Call appropriate model
    response = model_inference(
        model=model,
        query=user_query,
        max_tokens=max_tokens
    )

    return response

def classify_query_complexity(query):
    # Rule-based classification (can be replaced with ML model)
    token_count = len(query.split())

    # Simple heuristics
    if token_count < 20 and not requires_reasoning(query):
        return 'simple'
    elif token_count < 100 and not is_multi_step(query):
        return 'medium'
    else:
        return 'complex'

Monitoring and Observability

Key Metrics to Track:

Cache Performance:
- Redis hit rate (target: >95%)
- Semantic hit rate (target: >99%)
- Average cache latency (target: <15ms)
Model Performance:
- P50, P95, P99 latency by model
- Throughput (queries/second)
- Error rate (<0.1% target)
Cost Metrics:
- Cost per query (overall and by model)
- Daily/monthly spend tracking
- Cost attribution by endpoint/user
Quality Metrics:
- Response accuracy (A/B testing)
- User satisfaction (thumbs up/down)
- Escalation rate (queries requiring human review)

Dashboard Setup (Grafana):

Panel 1: Cache Hit Rates (last 24h)
- Redis: 95.2%
- Semantic: 99.1%
- Overall: 99.7%

Panel 2: Cost Trends (last 30 days)
- Total spend: $2,800
- Trend: -94% vs Month 1
- Projection: $2,850 next month

Panel 3: Model Distribution
- 8B: 62% of queries
- 70B: 28% of queries
- 405B: 10% of queries

Panel 4: Latency P99
- Cached: 12ms
- Uncached: 125ms
- Overall: 18ms

PART 4: Results & ROI

Month-by-Month Cost Reduction

Month 1 (Baseline):
- Infrastructure cost: $47,000
- Queries served: 42M
- Cost per query: $0.00112

Month 2 (Redis caching deployed):
- Infrastructure cost: $38,000
- Queries served: 44M
- Cost per query: $0.00086
- Reduction: 19%

Month 3 (Semantic caching deployed):
- Infrastructure cost: $12,000
- Queries served: 45M
- Cost per query: $0.00027
- Reduction: 74% (from baseline)

Month 4 (Model routing deployed):
- Infrastructure cost: $6,500
- Queries served: 46M
- Cost per query: $0.00014
- Reduction: 86% (from baseline)

Month 5 (Efficient models deployed):
- Infrastructure cost: $2,800
- Queries served: 47M
- Cost per query: $0.00006
- Reduction: 94% (from baseline)

Performance Metrics

Before Optimization:

P50 latency: 280ms
P95 latency: 420ms
P99 latency: 650ms
Throughput: 1,200 queries/sec

After Optimization:

P50 latency: 8ms (97% faster)
P95 latency: 15ms (96% faster)
P99 latency: 125ms (81% faster)
Throughput: 8,500 queries/sec (7x improvement)

User Experience Impact:

Page load times: -60% (faster responses)
User complaints: 0 (nobody noticed quality change)
User satisfaction: +12% (noticed speed improvement)
Feature usage: +28% (faster = more engagement)

ROI Analysis

Investment:

Engineering time: 8 weeks × 2 engineers = 16 engineer-weeks
Infrastructure setup: $5,000 (one-time)
Testing and monitoring tools: $2,000 (one-time)

Total investment: ~$80,000-$100,000

Savings:

Monthly savings: $44,200 ($47K - $2.8K)
Annual savings: $530,400
3-year savings: $1,591,200

ROI (Year 1): 530% ($530K saved / $100K invested)
Payback period: 2.3 months

Lessons Learned

What Worked:

✅ Gradual migration - Shadow mode → A/B test → full rollout prevented disasters
✅ Monitoring first - Set up dashboards before making changes, not after
✅ Conservative thresholds - Started with 0.98 similarity, lowered to 0.95 after confidence built
✅ Rollback plan - Having old infrastructure ready for instant rollback was crucial
✅ Quality gates - Automated quality checks caught issues before users did

What Didn't Work Initially:

❌ Too aggressive cache invalidation - First attempt: invalidate after 1 hour. Too frequent. Changed to 24 hours.
❌ Wrong similarity threshold - Started at 0.90, got too many false positives. Raised to 0.95.
❌ Inadequate monitoring - Missed cache memory issues initially. Added memory alerts.
❌ No cost attribution - Couldn't tell which endpoints were expensive. Added detailed tracking.

Common Pitfalls to Avoid

Pitfall #1: Caching everything

Don't cache time-sensitive queries (stock prices, weather)
Don't cache user-specific data without proper key isolation
Don't cache low-frequency queries (waste of memory)

Pitfall #2: Wrong model routing

Don't route based on query length alone (misleading)
Don't use overly complex routing logic (adds latency)
Don't forget to measure routing accuracy

Pitfall #3: Premature optimization

Don't optimize before measuring (know your bottlenecks)
Don't sacrifice quality for cost (users > dollars)
Don't optimize in isolation (system-level thinking required)

Pitfall #4: Ignoring monitoring

Don't deploy without observability (you're flying blind)
Don't skip A/B testing (assumptions fail in production)
Don't ignore long-tail latency (P99 matters more than average)

PART 5: What's Next

The AI efficiency revolution is just beginning.

2026-2028 Predictions

2026 (now):

8B models match 70B performance ✅ (happening)
Semantic caching becomes standard practice
Model routing adopted by 30% of AI-first companies

2027:

3B models match today's 70B performance
On-device AI becomes viable for 50%+ of use cases
Edge deployment standard for latency-critical apps
First $1B+ open source AI infrastructure company

2028:

Consumer devices run GPT-4-equivalent models natively
Cloud inference costs drop 95% from 2024 levels
AI infrastructure consolidates around 3-5 major platforms

Emerging Technologies to Watch

Mixture of Experts (MoE) - Activate only subset of parameters per query
Speculative Decoding - Generate faster with small model + large model verification
Quantized Models - 4-bit and even 2-bit inference without quality loss
State Space Models - Alternative to transformers, potentially more efficient
Neuromorphic Computing - Hardware optimized for neural networks

How to Stay Ahead

For Technical Leaders:

Start measuring cost per query today
Implement caching this quarter
Experiment with model routing next quarter
Migrate to efficient models within 6 months

For Organizations:

Treat AI infrastructure as platform investment, not project
Hire engineers who've built AI at scale (not just trained models)
Open source your learnings (builds credibility, attracts talent)
Focus on efficiency from day one (retrofitting is 10x harder)

For the Industry:

Standardize on efficiency benchmarks (cost per query, not just accuracy)
Share production learnings openly (we all benefit)
Pressure model providers for more efficient options
Invest in infrastructure, not just models

Conclusion

Cutting AI costs by 94% wasn't magic. It was architecture.

The 4-layer stack:

Semantic caching (70% reduction)
Redis caching (15% additional)
Model routing (12% additional)
Efficient models (15% additional)

The results:

$47,000 → $2,800/month
340ms → 125ms latency
0% quality degradation
530% ROI in year 1

The lesson: AI infrastructure optimization isn't about compromising quality. It's about building intelligently from the start.

The companies that master AI efficiency will win the next decade. The companies that don't will burn cash until they can't compete.

Which side do you want to be on?

💡 Enjoyed this deep-dive?

If you found this article valuable, here's how to stay connected and go deeper:

📧 Subscribe to my Substack

Get weekly deep-dives on production AI infrastructure, case studies, and implementation guides delivered to your inbox.

👉 Subscribe here (Early access to all articles!)

💻 Explore the Code

All the optimization techniques discussed here are open source:

👉 github.com/anilatambharii

LLM Cost Optimization frameworks
Production RAG implementations
AI Safety testing frameworks
Distributed training utilities

💼 Connect & Follow

LinkedIn: Daily AI infrastructure insights → linkedin.com/in/anilsprasad
X/Twitter: Real-time production AI observations → @anilsprasad
Ambharii Labs: We build production AI infrastructure → ambharii.com

🏢 Need Help Implementing This?

If your team is struggling with AI infrastructure costs or wants to build efficient systems from day one:

📨 Email: contact@ambharii.com

🌐 Website: ambharii.com

We offer:

Architecture review & optimization consulting
Build services for production AI infrastructure
Training for engineering teams

About the Author

Anil Prasad is Head of Engineering at Ambharii Labs, where he builds production AI infrastructure processing 2.3M events/second. Named one of "100 Most Influential AI Leaders in USA 2024."

Previously led engineering teams at Fortune 500 companies recovering $47M in revenue through real-time data systems. Passionate about making production AI infrastructure accessible through open source and knowledge sharing.

Products:

ARIA RCM: AI-native revenue cycle management for healthcare
GenomiziQ: Precision medicine platform (WEF candidate)
Agentic AI Platform: Multi-agent orchestration infrastructure

Tags: #ai #machinelearning #production #llm #optimization #costoptimization #infrastructure #devops #engineering #opensource

💖 If this article helped you, please heart it and share it with your team!

🔖 Bookmark for future reference

💬 Drop a comment if you have questions or want to share your own optimization wins!

Published: June 10, 2026

Reading Time: 16-18 minutes

Originally published on: Substack

Building Production-Ready Open Source AI Infrastructure: A Technical Guide

Anil Prasad — Tue, 19 May 2026 13:00:00 +0000

Building Production-Ready Open Source AI Infrastructure: A Technical Guide

Over the past year, we've built and open sourced six production-grade AI infrastructure projects. This isn't toy code or proof of concepts. These are systems handling millions of requests daily in production environments.

Here's what we learned building open source AI infrastructure that actually works.

The Six Projects

llm-cost-optimization: 3-layer caching plus intelligent routing
ai-safety-framework: 5-layer defense with 250 red team test cases
production-rag: 6-stage pipeline with re-ranking and evaluation
distributed-training: PyTorch DDP with NCCL tuning
roi-first-ai: Business metric selection and deployment templates
agentic-ai: Multi-agent orchestration framework

All repositories are at github.com/anilatambharii

Why Open Source Our Production Code

Three reasons.

First, the AI infrastructure landscape is fragmented. Every team rebuilds the same patterns from scratch. LLM caching. RAG pipelines. Cost optimization. Agent orchestration. We've already solved these problems. Sharing the solutions helps the community.

Second, open source code is battle tested. When thousands of developers review, use, and contribute to your code, it gets better fast. Private code stays brittle. Public code gets hardened.

Third, hiring advantage. The best engineers want to work on code that matters. Open source contributions demonstrate technical credibility better than any interview.

Architecture Principle: Composition Over Configuration

Each project is a focused library, not a framework. You compose them together rather than configuring one monolithic system.

Bad approach: One repo with 47 configuration options trying to do everything.

Good approach: Six repos, each solving one problem well. Use what you need. Ignore what you don't.

Example using llm-cost-optimization and production-rag together:

from llm_cost_optimization import CachingLayer, ModelRouter
from production_rag import RAGPipeline, HybridRetriever

# Set up caching for LLM calls
cache = CachingLayer(
    semantic_cache_threshold=0.95,
    redis_url="redis://localhost:6379"
)

# Set up model routing based on query complexity
router = ModelRouter(
    models={
        "simple": "claude-haiku-4-5",
        "complex": "claude-sonnet-4-6"
    },
    complexity_threshold=0.7
)

# Set up RAG pipeline with hybrid retrieval
retriever = HybridRetriever(
    vector_weight=0.7,
    keyword_weight=0.3
)

rag = RAGPipeline(
    retriever=retriever,
    llm_cache=cache,
    llm_router=router
)

# Use them together
result = rag.query("What were Q2 financial results?")

Each component is independent. Each can be used standalone. Together they form a complete system.

Project Deep Dive: LLM Cost Optimization

This project reduced our LLM costs from $47K monthly to $2.8K monthly. 94% cost reduction. Same quality.

Three Layer Caching

Exact match cache catches identical queries. Redis key is SHA256 hash of prompt. Cache hit returns response instantly. No LLM call. Zero cost.

class ExactMatchCache:
    def __init__(self, redis_client):
        self.redis = redis_client

    def get(self, prompt: str) -> Optional[str]:
        key = hashlib.sha256(prompt.encode()).hexdigest()
        return self.redis.get(f"exact:{key}")

    def set(self, prompt: str, response: str, ttl: int = 3600):
        key = hashlib.sha256(prompt.encode()).hexdigest()
        self.redis.setex(f"exact:{key}", ttl, response)

Hit rate: 23% of queries.

Semantic cache catches similar queries. Embed the prompt. Find nearest neighbors in vector DB. If similarity > threshold (0.95), return cached response.

class SemanticCache:
    def __init__(self, embedding_model, vector_db, threshold=0.95):
        self.embed = embedding_model
        self.db = vector_db
        self.threshold = threshold

    def get(self, prompt: str) -> Optional[str]:
        embedding = self.embed(prompt)
        results = self.db.search(embedding, k=1)

        if results and results[0].score > self.threshold:
            return results[0].cached_response
        return None

    def set(self, prompt: str, response: str):
        embedding = self.embed(prompt)
        self.db.insert(embedding, cached_response=response)

Hit rate: 31% of queries not caught by exact match.

Prefix cache reuses computation for prompts with common prefixes. System prompt is usually identical. Few-shot examples are usually identical. Only the user query changes.

Anthropic's prompt caching API handles this automatically. Mark static parts as cacheable.

response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": LONG_SYSTEM_PROMPT,
            "cache_control": {"type": "ephemeral"}
        }
    ],
    messages=[
        {"role": "user", "content": user_query}
    ]
)

Combined hit rate: 73% of queries serve from cache. 27% hit the LLM. Cost reduced 73% from caching alone.

Intelligent Model Routing

Not every query needs GPT-4 or Claude Opus. Simple queries work fine on Haiku. Complex queries need Sonnet.

Routing strategy:

class ModelRouter:
    def route(self, query: str) -> str:
        complexity = self.calculate_complexity(query)

        if complexity < 0.3:
            return "claude-haiku-4-5"  # $0.25 per 1M tokens
        elif complexity < 0.7:
            return "claude-sonnet-4-6"  # $3 per 1M tokens
        else:
            return "claude-opus-4-6"    # $15 per 1M tokens

    def calculate_complexity(self, query: str) -> float:
        # Features: length, question marks, technical terms, etc.
        features = self.extract_features(query)
        return self.classifier.predict_proba(features)[1]

Trained a simple classifier on 10K labeled examples. "What's the capital of France?" → Haiku. "Analyze this 50 page contract for liability clauses" → Opus.

Result: 89% of queries route to Haiku. 9% to Sonnet. 2% to Opus. Average cost per query drops 88%.

Implementation Notes

Cache invalidation is the hard part. We invalidate based on TTL (1 hour default) and explicit updates. When source data changes, we flush related cache entries.

Monitoring tracks hit rates, latency, cost per query. Dashboard shows cache performance in real time. Alerts fire when hit rate drops below threshold.

Gradual rollout started with 1% of traffic. Measured cache hit rate and accuracy. Ramped to 10%, 50%, 100% over 3 weeks.

Project Deep Dive: Production RAG

We increased RAG accuracy from 52% to 89% by fixing retrieval, not the LLM.

The 6-Stage Pipeline

Stage 1: Query Processing

Don't send raw user queries to vector DB. Expand with synonyms. Extract metadata. Generate context-aware embedding.

class QueryProcessor:
    def process(self, query: str) -> ProcessedQuery:
        # Extract metadata
        metadata = {
            "date_range": self.extract_date_range(query),
            "department": self.extract_department(query),
            "doc_type": self.extract_doc_type(query)
        }

        # Expand with synonyms
        expanded = self.expand_synonyms(query)

        # Generate embedding
        embedding = self.embed_model(expanded)

        return ProcessedQuery(
            original=query,
            expanded=expanded,
            embedding=embedding,
            metadata=metadata
        )

Stage 2: Vector Database Search

Cosine similarity threshold 0.85. Top-k 50 candidates (not 5, not 10). Use Pinecone with metadata filtering.

results = index.query(
    vector=processed_query.embedding,
    top_k=50,
    filter={
        "department": processed_query.metadata["department"],
        "date": {"$gte": processed_query.metadata["date_range"][0]}
    }
)

Stage 3: Hybrid Search

Combine semantic search (70%) with keyword search (30%) using BM25.

class HybridRetriever:
    def retrieve(self, query: ProcessedQuery) -> List[Document]:
        # Vector search
        vector_results = self.vector_search(query, k=50)

        # Keyword search
        keyword_results = self.bm25_search(query.expanded, k=50)

        # Combine with weights
        combined = self.merge_results(
            vector_results, 
            keyword_results,
            vector_weight=0.7,
            keyword_weight=0.3
        )

        return combined[:50]

Stage 4: Re-ranking

This single stage improved accuracy by 23%. Use cross-encoder to score each candidate against the actual query.

class Reranker:
    def __init__(self, model_name="cross-encoder/ms-marco-MiniLM-L-12-v2"):
        self.model = CrossEncoder(model_name)

    def rerank(self, query: str, documents: List[Document]) -> List[Document]:
        # Score each doc against query
        pairs = [(query, doc.text) for doc in documents]
        scores = self.model.predict(pairs)

        # Sort by score
        ranked = sorted(
            zip(documents, scores),
            key=lambda x: x[1],
            reverse=True
        )

        return [doc for doc, score in ranked[:5]]

Top 50 candidates from hybrid search → Re-rank → Best 5 to LLM.

Stage 5: Context Assembly

Smart chunking with overlap. 512 token chunks with 50 token overlap. Include surrounding context. Add metadata.

def assemble_context(ranked_docs: List[Document]) -> str:
    context_parts = []

    for i, doc in enumerate(ranked_docs):
        context_parts.append(f"""
Source {i+1}: {doc.metadata['title']}
Date: {doc.metadata['date']}
Department: {doc.metadata['department']}

{doc.text}

---
        """)

    return "\n".join(context_parts)

Stage 6: LLM Generation

Force grounded responses. System prompt enforces citation. User query includes assembled context.

system_prompt = """You are a helpful assistant. Use ONLY the provided context to answer questions. 

If the context doesn't contain enough information, say "I don't have enough information to answer that question."

Always cite your sources using the Source number."""

user_prompt = f"""Context:
{assembled_context}

Question: {original_query}

Answer:"""

Results

Before: 52% answer accuracy. 3.8s latency. 31% hallucination rate.

After: 89% accuracy (+71%). 1.2s latency (faster!). 4% hallucination rate (-87%).

The insight: Don't optimize the LLM. Optimize the retrieval. GPT-4 with bad context = bad answers. Haiku with perfect context = great answers.

Making Projects Production Ready

Every project includes:

Comprehensive tests: Unit tests for every function. Integration tests for pipelines. End-to-end tests for workflows. 90%+ coverage.

Documentation: README with quick start. Detailed API docs. Architecture diagrams. Example notebooks.

Benchmarks: Performance metrics. Accuracy measurements. Cost comparisons. Real numbers, not claims.

Monitoring: Prometheus metrics. Logging. Error tracking. Observability built in.

Deployment: Docker containers. Kubernetes manifests. Terraform modules. Production ready deployment.

Contributing to Open Source AI

Our projects welcome contributions. Here's how to get started:

Pick a project that interests you
Read the CONTRIBUTING.md
Check the issues for "good first issue" labels
Submit a PR with tests and documentation
Respond to review feedback

We review all PRs within 48 hours. Quality bar is high but we help contributors meet it.

Conclusion

Open source AI infrastructure should be production ready, not proof of concept. These six projects represent thousands of hours of real world testing and optimization.

Use them. Contribute to them. Build on them.

The code is at github.com/anilatambharii. Documentation is comprehensive. Examples are plentiful. Issues are welcome.

Let's build better AI infrastructure together.

About the Author

Anil Prasad is Head of Engineering at Ambharii Labs, recognized as one of "100 Most Influential AI Leaders in USA 2024." He builds production-scale AI and data systems for enterprise organizations. Connect on LinkedIn at linkedin.com/in/anilsprasad or visit ambharii.com.

Related Reading

How We Cut LLM API Costs by 94%: A 3-Layer Caching Strategy

Anil Prasad — Thu, 14 May 2026 13:59:00 +0000

Last month, our LLM API bills hit $47,000.

This month: $2,800.

Same product. Same user experience. Same performance.

94% cost reduction without sacrificing quality.

Here's the architecture that made it possible.

The Wake-Up Call

CFO's message: "Fix this or we shut down the AI features."

We had 90 days.

Most teams would panic and start cutting features. We treated it as an architecture problem, not a budget problem.

The Solution: 3-Layer Caching + Intelligent Routing

Layer 1: Prompt Caching (68% hit rate)

Problem: Every request pays for the same tokens repeatedly.

Standard system prompts, documentation, static context—all charged every time.

Solution: Claude's native prompt caching.

import anthropic

client = anthropic.Anthropic(api_key="your-key")

# Mark cacheable content with cache_control
message = client.messages.create(
    model="claude-sonnet-4-20250514",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": "You are a helpful AI assistant for our healthcare platform...",
            "cache_control": {"type": "ephemeral"}  # Cache this
        },
        {
            "type": "text", 
            "text": f"Current user context: {user_context}"  # Don't cache (changes per user)
        }
    ],
    messages=[{"role": "user", "content": query}]
)

Economics:

Input tokens: $3.00 / 1M tokens
Cached input tokens: $0.30 / 1M tokens (10x cheaper!)
Cache write: $3.75 / 1M tokens (one-time cost)

Example:

First request (cache write):

5,000 token system prompt
Cost: $0.01875 (5K tokens × $3.75/1M)

Next 100 requests (cache hit):

Same 5,000 token system prompt
Cost: $0.0015 (5K tokens × $0.30/1M × 100)

Total: $0.02025 for 101 requests
Without caching: $1.515 (5K × $3/1M × 101)
Savings: 98.7%

Our hit rate: 68%

Layer 2: Semantic Caching (15% hit rate)

Problem: Vector search doesn't catch similar queries.

"How do I reset my password?" vs "Password reset help?" are semantically identical but literally different.

Solution: Semantic similarity matching.

from sentence_transformers import SentenceTransformer
import numpy as np

class SemanticCache:
    def __init__(self, similarity_threshold=0.95):
        self.model = SentenceTransformer('all-MiniLM-L6-v2')
        self.cache = {}  # {embedding: (query, response, timestamp)}
        self.threshold = similarity_threshold

    def get(self, query: str):
        """Check if semantically similar query exists in cache"""
        query_embedding = self.model.encode(query)

        for cached_embedding, (cached_query, response, timestamp) in self.cache.items():
            similarity = np.dot(query_embedding, cached_embedding)

            if similarity >= self.threshold:
                print(f"Cache HIT: '{query}' ≈ '{cached_query}' (similarity: {similarity:.3f})")
                return response

        return None

    def set(self, query: str, response: str):
        """Store query-response pair with embedding"""
        embedding = self.model.encode(query)
        self.cache[tuple(embedding)] = (query, response, time.time())

# Usage
cache = SemanticCache(similarity_threshold=0.95)

# First query
response = llm.complete("How do I reset my password?")
cache.set("How do I reset my password?", response)

# Similar query (cache hit!)
cached_response = cache.get("Password reset help?")
# Returns the cached response, no LLM call

Additional 15% cache hit rate on top of prompt caching.

Layer 3: Result Caching (10% hit rate)

Problem: Identical queries hit the LLM multiple times.

Solution: Cache complete responses with smart TTL.

import redis
import hashlib
import json

class ResultCache:
    def __init__(self):
        self.redis = redis.Redis(host='localhost', port=6379, db=0)

    def get_cache_key(self, query: str, context: dict) -> str:
        """Create deterministic cache key"""
        cache_input = json.dumps({
            'query': query,
            'context': context
        }, sort_keys=True)
        return hashlib.sha256(cache_input.encode()).hexdigest()

    def get(self, query: str, context: dict):
        """Get cached response if exists"""
        key = self.get_cache_key(query, context)
        cached = self.redis.get(key)
        return json.loads(cached) if cached else None

    def set(self, query: str, context: dict, response: str, ttl: int = 3600):
        """Cache response with TTL

        TTL strategy:
        - Stable content: 24 hours (86400s)
        - Dynamic content: 1 hour (3600s)
        - Real-time data: 5 minutes (300s)
        """
        key = self.get_cache_key(query, context)
        self.redis.setex(
            key,
            ttl,
            json.dumps(response)
        )

    def invalidate(self, pattern: str):
        """Invalidate cache on data updates"""
        for key in self.redis.scan_iter(pattern):
            self.redis.delete(key)

# Usage
cache = ResultCache()

# Check cache first
cached = cache.get(query, context)
if cached:
    return cached  # Cache hit!

# Cache miss - call LLM
response = llm.complete(query, context)

# Cache the result
cache.set(query, context, response, ttl=3600)

# Invalidate on data update
cache.invalidate("user:123:*")  # Clear all caches for user 123

Final 10% cache hit rate.

Combined: 73% cache hit rate (68% + 15% + 10% with some overlap)

Intelligent Model Routing

Caching alone isn't enough.

67% of our queries work perfectly with Haiku. That's a 60x price difference vs Opus.

from enum import Enum

class ModelTier(Enum):
    HAIKU = "claude-haiku-4-20250514"    # $0.25/1M input
    SONNET = "claude-sonnet-4-20250514"  # $3/1M input
    OPUS = "claude-opus-4-20250514"      # $15/1M input

def route_to_model(query: str, context: str) -> ModelTier:
    """
    Route based on complexity

    Indicators for Haiku (simple):
    - Short queries (<50 tokens)
    - FAQ-style questions
    - Retrieval tasks

    Indicators for Sonnet (analysis):
    - "analyze", "compare", "evaluate"
    - Multi-step reasoning
    - Longer context (>2K tokens)

    Indicators for Opus (complex):
    - "design", "architect", "strategy"
    - Creative tasks
    - Critical business decisions
    """
    tokens = len(query.split())

    # Simple queries → Haiku
    if tokens < 50 and not any(word in query.lower() for word in ['analyze', 'compare', 'design']):
        return ModelTier.HAIKU

    # Analysis tasks → Sonnet
    if any(word in query.lower() for word in ['analyze', 'compare', 'evaluate', 'explain']):
        return ModelTier.SONNET

    # Complex reasoning → Opus
    if any(word in query.lower() for word in ['design', 'architect', 'strategy', 'create']):
        return ModelTier.OPUS

    # Default to Sonnet
    return ModelTier.SONNET

# Usage
model = route_to_model(user_query, context)
response = llm.complete(user_query, model=model.value)

Our distribution:

67% Haiku ($0.25/1M)
28% Sonnet ($3/1M)
5% Opus ($15/1M)

The Complete System

class OptimizedLLMClient:
    def __init__(self):
        self.prompt_cache = PromptCache()      # Layer 1
        self.semantic_cache = SemanticCache()  # Layer 2
        self.result_cache = ResultCache()      # Layer 3
        self.client = anthropic.Anthropic()

    def complete(self, query: str, context: dict):
        # Layer 3: Check result cache
        cached_result = self.result_cache.get(query, context)
        if cached_result:
            return cached_result

        # Layer 2: Check semantic cache
        semantic_result = self.semantic_cache.get(query)
        if semantic_result:
            return semantic_result

        # Layer 1: Prompt caching + model routing happens in LLM call
        model = route_to_model(query, context)

        response = self.client.messages.create(
            model=model.value,
            max_tokens=1024,
            system=[{
                "type": "text",
                "text": context.get('system_prompt'),
                "cache_control": {"type": "ephemeral"}  # Prompt caching
            }],
            messages=[{"role": "user", "content": query}]
        )

        # Cache the result
        self.result_cache.set(query, context, response.content, ttl=3600)
        self.semantic_cache.set(query, response.content)

        return response.content

# Usage
llm = OptimizedLLMClient()
answer = llm.complete("What's my account balance?", context)

The Results

Before:

$47K/month API costs
P95 latency: 2.1s
No optimization strategy

After:

$2.8K/month (-94%)
P95 latency: 340ms (67% faster!)
73% cache hit rate

Key Insights

1. Infrastructure > Model Selection

Opus with naive setup: $47K/month
Haiku with optimization: $2.8K/month

A well-architected system with Haiku outperforms naive Opus at 1/16th the cost.

2. Cache Hit Rate Math

Without caching: 100% requests hit LLM
With 73% cache hit: 27% requests hit LLM
Cost reduction: 73% from caching alone
Additional savings: 67% of remaining 27% uses cheap Haiku
Total: 94% cost reduction

3. Speed as Side Effect

Caching doesn't just save money. It's faster:

Cache hit: 50ms (Redis lookup)
LLM call: 2,100ms (P95)

42x faster for cached requests.

Implementation Checklist

[ ] Enable prompt caching (10x savings on repeated context)
[ ] Add semantic similarity cache (15% additional hits)
[ ] Implement result caching with smart TTL
[ ] Route queries to appropriate model tier
[ ] Monitor cache hit rates and adjust thresholds
[ ] Set up cache invalidation on data updates

Monitoring Dashboard

def get_cache_metrics():
    return {
        'prompt_cache_hit_rate': 0.68,
        'semantic_cache_hit_rate': 0.15,
        'result_cache_hit_rate': 0.10,
        'combined_hit_rate': 0.73,
        'model_distribution': {
            'haiku': 0.67,
            'sonnet': 0.28,
            'opus': 0.05
        },
        'cost_per_1k_requests': 2.80,
        'p95_latency_ms': 340
    }

Track these weekly. Optimize based on data, not assumptions.

What's Next

We're open-sourcing our cost optimization framework:

Complete caching implementation
Model routing logic
Monitoring dashboards
Cost calculation tools

Follow @anilsprasad or Ambharii Labs for the release.

Your Turn

What's your LLM API bill?

Drop it in the comments and I'll tell you which optimization would have the highest ROI for your use case.

Common wins:

Prompt caching: 10x savings on repeated context
Model routing: 60x price difference (Haiku vs Opus)
Semantic caching: 15% additional hits

Let's make LLMs affordable for everyone. 💰

Tags: #ai #performance #optimization #tutorial

Building Production RAG: From 52% to 89% Accuracy with a 6-Stage Pipeline

Anil Prasad — Tue, 12 May 2026 13:00:00 +0000

Two hard problems in production AI:

Accuracy: RAG systems giving wrong answers 48% of the time
Cost: LLM API bills hitting $47K/month

We solved both. Here's how.

Part 1: RAG Accuracy (52% → 89%)

Our RAG system was confidently wrong. Users asked "What were Q2 healthcare results?" and got Q1 data, footnotes, and chapter titles with zero content.

High similarity scores. Completely useless context.

The LLM wasn't the problem. Retrieval was broken.

The 6-Stage Pipeline

Stage 1: Query Processing

Problem: "Show me Q2 results" has no semantic information.

Solution: Query expansion + metadata extraction

def process_query(raw_query: str) -> ProcessedQuery:
    metadata = extract_metadata(raw_query)  # dates, entities
    expanded = expand_query(raw_query, metadata)
    embedding = embed_with_context(expanded, metadata)
    return ProcessedQuery(expanded, metadata, embedding)

Transformation:
Input: "Show me Q2 results"
Output: "quarterly financial results Q2 2024 revenue profit earnings second quarter"

Stage 2: Vector Database Search

import pinecone

index = pinecone.Index("knowledge-base")

results = index.query(
    vector=query_embedding,
    top_k=5,  # not 10, not 20
    filter={
        "date_range": {"$gte": "2024-04-01"},
        "department": "healthcare"
    }
)

Key: Cosine similarity threshold 0.85. Anything lower retrieves noise.

Stage 3: Hybrid Search (Semantic + Keyword)

def hybrid_search(query: str, top_k=50):
    # Semantic (70%) + BM25 keyword (30%)
    vector_results = vector_search(query, top_k)
    bm25_results = keyword_search(query, top_k)

    combined = []
    for chunk_id in set(vector_results) | set(bm25_results):
        score = (vector_results.get(chunk_id, 0) * 0.7 + 
                 bm25_results.get(chunk_id, 0) * 0.3)
        combined.append((chunk_id, score))

    return sorted(combined, key=lambda x: x[1], reverse=True)[:top_k]

Why: Patent queries like "US-2847291" need exact match, not semantic.

Stage 4: Re-ranking (23% Accuracy Boost)

from sentence_transformers import CrossEncoder

reranker = CrossEncoder('cross-encoder/ms-marco-MiniLM-L-6-v2')

def rerank(query: str, chunks: List[str], top_k=5):
    pairs = [[query, chunk] for chunk in chunks]
    scores = reranker.predict(pairs)
    ranked = sorted(zip(chunks, scores), key=lambda x: x[1], reverse=True)
    return [chunk for chunk, _ in ranked[:top_k]]

Strategy: Fast bi-encoder for 50 candidates → slow cross-encoder for final 5.

Stage 5: Context Assembly

def create_chunks(doc: str, size=512, overlap=50):
    chunks = []
    tokens = tokenize(doc)

    for i in range(0, len(tokens), size - overlap):
        chunk = tokens[i:i + size]
        chunks.append(Chunk(
            text=detokenize(chunk),
            metadata={
                'source': doc.title,
                'date': doc.date,
                'section': extract_section(chunk)
            }
        ))
    return chunks

Why overlap: "Revenue increased 23% vs previous quarter" → needs surrounding context.

Stage 6: LLM Generation

def generate_answer(query: str, chunks: List[Chunk]):
    context = "\n\n".join([
        f"<document>\n<source>{c.metadata['source']}</source>\n"
        f"<content>{c.text}</content>\n</document>"
        for c in chunks
    ])

    prompt = f"""Use ONLY the provided context.

Context:
{context}

Query: {query}

Instructions:
1. Answer using ONLY provided context
2. Cite sources
3. Say "I don't know" if insufficient

Answer:"""

    return llm.complete(prompt)

RAG Results

Before:

52% accuracy
31% hallucination rate
3.8s latency

After:

89% accuracy (+71%)
4% hallucination rate (-87%)
1.2s latency (-67%)

Key Insight: GPT-4 with naive retrieval = 54% accuracy. Haiku with 6-stage pipeline = 87% accuracy.

Optimize retrieval, not the LLM.

Part 2: Cost Reduction ($47K → $2.8K)

Same product. Same UX. 94% cost reduction.

The secret: 3-layer caching + intelligent routing.

Layer 1: Prompt Caching (68% hit rate)

Problem: Every request pays for the same system prompt.

import anthropic

client = anthropic.Anthropic()

message = client.messages.create(
    model="claude-sonnet-4-20250514",
    system=[
        {
            "type": "text",
            "text": "You are a helpful AI assistant...",
            "cache_control": {"type": "ephemeral"}  # 10x cheaper!
        }
    ],
    messages=[{"role": "user", "content": query}]
)

Economics:

Normal: $3.00/1M tokens
Cached: $0.30/1M tokens (10x cheaper)

Example:
5K token system prompt × 100 requests:
Without caching: $1.50
With caching: $0.02
98.7% savings

Layer 2: Semantic Caching (15% hit rate)

from sentence_transformers import SentenceTransformer
import numpy as np

class SemanticCache:
    def __init__(self, threshold=0.95):
        self.model = SentenceTransformer('all-MiniLM-L6-v2')
        self.cache = {}
        self.threshold = threshold

    def get(self, query: str):
        query_emb = self.model.encode(query)

        for cached_emb, (cached_q, response, _) in self.cache.items():
            similarity = np.dot(query_emb, cached_emb)
            if similarity >= self.threshold:
                return response
        return None

    def set(self, query: str, response: str):
        embedding = self.model.encode(query)
        self.cache[tuple(embedding)] = (query, response, time.time())

Catches: "How do I reset password?" ≈ "Password reset help?"

Layer 3: Result Caching (10% hit rate)

import redis
import hashlib

class ResultCache:
    def __init__(self):
        self.redis = redis.Redis()

    def get(self, query: str, context: dict):
        key = hashlib.sha256(
            json.dumps({'query': query, 'context': context}).encode()
        ).hexdigest()
        return self.redis.get(key)

    def set(self, query: str, context: dict, response: str, ttl=3600):
        key = hashlib.sha256(
            json.dumps({'query': query, 'context': context}).encode()
        ).hexdigest()
        self.redis.setex(key, ttl, response)

TTL strategy:

Stable content: 24 hours
Dynamic content: 1 hour
Real-time: 5 minutes

Intelligent Model Routing

67% of queries work with Haiku ($0.25/1M). 60x cheaper than Opus ($15/1M).

from enum import Enum

class Model(Enum):
    HAIKU = "claude-haiku-4-20250514"    # $0.25/1M
    SONNET = "claude-sonnet-4-20250514"  # $3/1M
    OPUS = "claude-opus-4-20250514"      # $15/1M

def route(query: str) -> Model:
    tokens = len(query.split())

    # Simple → Haiku
    if tokens < 50:
        return Model.HAIKU

    # Analysis → Sonnet
    if any(w in query.lower() for w in ['analyze', 'compare']):
        return Model.SONNET

    # Complex → Opus
    if any(w in query.lower() for w in ['design', 'architect']):
        return Model.OPUS

    return Model.SONNET

Distribution:

67% Haiku
28% Sonnet
5% Opus

The Complete System

class OptimizedLLM:
    def __init__(self):
        self.semantic_cache = SemanticCache()
        self.result_cache = ResultCache()
        self.client = anthropic.Anthropic()

    def complete(self, query: str, context: dict):
        # Layer 3: Result cache
        cached = self.result_cache.get(query, context)
        if cached:
            return cached

        # Layer 2: Semantic cache
        semantic = self.semantic_cache.get(query)
        if semantic:
            return semantic

        # Layer 1: Prompt cache + routing
        model = route(query)

        response = self.client.messages.create(
            model=model.value,
            system=[{
                "type": "text",
                "text": context['system_prompt'],
                "cache_control": {"type": "ephemeral"}
            }],
            messages=[{"role": "user", "content": query}]
        )

        # Cache results
        self.result_cache.set(query, context, response.content)
        self.semantic_cache.set(query, response.content)

        return response.content

Cost Results

Before:

$47K/month
P95 latency: 2.1s

After:

$2.8K/month (-94%)
P95 latency: 340ms (-84%)
73% combined cache hit rate

Implementation Checklist

RAG:

[ ] Implement query processing (expand + extract metadata)
[ ] Set up vector DB with metadata filtering
[ ] Add hybrid search (semantic + keyword)
[ ] Deploy cross-encoder re-ranking
[ ] Build chunking with 50-token overlap
[ ] Force grounded prompts (no hallucinations)

Cost:

[ ] Enable prompt caching (10x savings)
[ ] Add semantic similarity cache
[ ] Implement result cache with smart TTL
[ ] Route to appropriate model tier
[ ] Monitor cache hit rates weekly

Key Insights

Retrieval > LLM: Haiku + perfect context beats GPT-4 + bad context
Re-ranking = 23% boost: Single highest-ROI optimization
Caching = 73% hit rate: Most requests never touch the LLM
Model routing = 60x savings: Haiku for 67% of queries

What We're Open-Sourcing

Next month:

6-stage RAG pipeline (code + docs)
Cost optimization framework
Re-ranking models
Monitoring dashboards
Evaluation datasets

Follow @anilsprasad or Ambharii Labs for release.

Your Turn

For RAG: What's your accuracy? Drop it in comments.

For Costs: What's your monthly LLM bill? I'll tell you which optimization has highest ROI.

Common wins:

Prompt caching: 10x savings
Re-ranking: 23% accuracy boost
Model routing: 60x price difference

Let's make production AI work. 🚀

Tags: #ai #machinelearning #python #tutorial

The web is now weaponized against your AI agents

Anil Prasad — Fri, 08 May 2026 17:15:44 +0000

Google dropped a security bomb last week.

Their threat intelligence team scanned 2-3 billion web pages per month looking for indirect prompt injection attacks targeting enterprise AI agents. They found a 32% increase in malicious attempts between November 2025 and February 2026.

The open web is now an attack surface for production AI.

This is not speculation. This is documented evidence of active attacks deployed at scale. Hidden instructions embedded in public HTML. Invisible to humans. Visible to AI agents. Real payloads designed to hijack enterprise systems the moment an agent scrapes the page.

If you have AI agents reading the open web on behalf of your organization, your security model just became obsolete.

Monday: Hidden instructions at scale

Google researchers documented the attack patterns deployed across billions of public web pages. The techniques are simple and effective:

Zero font size text: Instructions rendered in font-size: 0. Invisible to humans, fully visible to AI parsing HTML

Opacity manipulation: Commands hidden using CSS opacity: 0. Text exists but appears transparent

Off-screen positioning: Instructions placed outside viewport using negative coordinates

JavaScript dynamic execution: Payloads injected after page load via client-side JS

URL fragment injection: Commands embedded after the # symbol in URLs

These are not sophisticated zero-days requiring nation-state capabilities. These are techniques any web developer knows. The barrier to entry is near zero.

Real payloads found in the wild:

Fully specified PayPal transaction instructions
Stripe donation redirects with persuasion amplifier keywords
Data exfiltration commands targeting enterprise agents

This is production infrastructure under active attack.

Source: Google Threat Intelligence, April 23, 2026

Tuesday: The exploit window collapsed

Black Hat Asia 2026 data from RunSybil: attack window compressed from 5 months (2023) to 10 hours (2026).

Why? Frontier LLMs now do offensive security work autonomously.

2023 workflow:

Security researcher finds vulnerability
Documents it technically
Writes POC exploit code
Tests against targets
Iterates based on results
Publishes working exploit

Timeline: months

2026 workflow:

Describe bug to LLM
Model generates exploit code
Test in real-time
Iterate with AI

Timeline: hours

Meanwhile, 57% of organizations have AI agents in production right now. Most were architected before this research dropped. The threat model changed faster than the deployment cycle.

Wednesday: The sanitizer model pattern

Two models. One reads the web. The other does the work.

This is the architecture that actually defends against indirect prompt injection.

Architecture

Deploy a small isolated model with zero system permissions. It reads untrusted web content, filters instructions, validates structure. If it gets compromised by a prompt injection, it lacks the permissions to cause damage.

The production agent never touches raw web input directly. It only processes data that passed through the sanitizer layer.

Key principle: Trust boundary between models, not just at network edge.

The sanitizer has:

❌ No write access
❌ No email permissions
❌ No payment capabilities
❌ No database credentials
✅ Can read and filter only

If compromised by prompt injection, worst case is tainted text reaching production layer where business logic validation applies.

Implementation

This is not theoretical. I've implemented this in:

ARGUS: Dual model verification by default
GenomixIQ: Clinical genomics data ingestion
ARIA RCM: Healthcare revenue cycle workflows

All production systems in regulated environments.

Thursday: Agent firewalls are the next layer

Agent firewalls enforce security policies traditional infrastructure can't.

What they block

Instruction injection: Override commands
Credential exfiltration: Data to external endpoints
Privilege escalation: Unauthorized tool calls
Decision manipulation: Logic chain redirects

Five-layer architecture

Layer 1: Input validation

Markdown sanitization
Suspicious URL redaction
Pattern matching for attack signatures

Layer 2: Instruction detection

ML models trained on override attempts
Recognizes semantic patterns (role reversals, system prompt refs)

Layer 3: Permission checks

Compartmentalized tool authorization
Research agents: read only
Write agents: database access, no email
Email agents: no payment processing

Layer 4: Decision logging

Full audit trails with context
Source data tracking
Reasoning chain capture
Forensic reconstruction capability

Layer 5: Human confirmation gates

Financial transactions require approval
Data deletion needs review
Credential changes trigger verification

Zero trust for agents

Never trust input. Assume web content hostile. Verify every action. Log decision lineage. Compartmentalize tools. Human in loop for high stakes.

Friday: Five questions before deployment

Does your sanitizer have zero system permissions?

If your sanitizer can write to databases or send emails, it's not a sanitizer. It's a production agent reading untrusted input. When compromised, attackers gain those capabilities.

Are tool permissions compartmentalized by role?

Monolithic access = single compromised agent exposes entire system. Implement RBAC for agents.

Can you reconstruct every decision from logs?

If compliance asks why an agent made a recommendation 6 months ago, can you trace to exact data sources and reasoning steps?

Does human confirmation trigger for financial actions?

Agents processing payments without approval = automated embezzlement risk. Confirmation gates are not optional.

Have you tested injection attacks?

No red team testing = you don't know if defenses work. Run adversarial testing continuously.

The 86-89% that fail discover these requirements 6 weeks before go-live when compliance asks.

The 14% that succeed build them day one.

What this means for your systems

Security architecture requirements:

✅ Dual model verification - Sanitizer + production agent separation

✅ Compartmentalized permissions - Role-based tool access

✅ Decision lineage tracking - Full audit trails

✅ Human confirmation gates - Required for high-stakes actions

✅ Continuous injection testing - Red team + automated

Not optional enhancements. Production requirements.

Resources

AI Aether: Free agent security readiness assessment (30 min, 30 questions)

ARGUS: Dual model verification, available on PyPI/GitHub

GenomixIQ: Clinical genomics with FHIR R4 interoperability

ARIA RCM: Healthcare revenue cycle with HIPAA compliance

All production-grade. No pilots. No POCs. Systems that ship and scale.

Years production AI taught one lesson

The teams that succeed build governance before deployment, not after compliance review.

RCMTech: $340M measurable improvements, 89 days integration, zero clinical data loss

GeneticsTech: 99.97% uptime during 50TB migration, FHIR R4 compliance throughout

EnergyTech: 23→81% AI adoption among 20-year veteran operators

HealthTech: Petabyte-scale platforms, every decision traceable

Anil Prasad is Founder of Ambharii Technologies and Head of Engineering & Product at EnergyTech.

28 years building production AI in regulated environments across Fortune 100 companies. Currently building agent security infrastructure for enterprise AI: dual-model verification, compartmentalized permissions, and audit trail architecture for autonomous systems.

Connect: LinkedIn | Website | GitHub

Next week: Production deployment patterns, compliance architecture, audit trail infrastructure.

AgentSecurity #EnterpriseAI #HumanWritten #ExpertiseFromField

Claude Code Has 6 Ways to Authenticate. I Built a Cross-Platform Installer Because of It

Anil Prasad — Wed, 06 May 2026 16:48:06 +0000

TL;DR
Claude Code supports 6 different authentication methods with a strict priority order. Get the order wrong and your Pro subscription silently gets overridden by an API key, costing you real money.

I built claude-auth-setup — a cross-platform installer (Bash + Batch + PowerShell) that handles the whole thing correctly. MIT licensed, ~17KB of bash, zero runtime dependencies.

This post walks through the design decisions, the cross-platform tax, and the testing approach.

The Problem
The Claude Code auth resolution order, highest to lowest:

Cloud provider creds (Bedrock / Vertex AI / Foundry)
ANTHROPIC_AUTH_TOKEN
ANTHROPIC_API_KEY ← the silent footgun
apiKeyHelper script
CLAUDE_CODE_OAUTH_TOKEN
Subscription OAuth ← what most users actually want

If you're a Pro/Max subscriber and you ever set ANTHROPIC_API_KEY to test something — the API key wins forever until you explicitly unset it. No error. No warning. Just per-token charges added on top of your $20/month subscription.

The single most common Claude Code support thread is some variation of:

"My Anthropic Console bill went from $0 to $47 last month and I don't know why."

The "why" is almost always a stale ANTHROPIC_API_KEY from a tutorial.

Why a Script Instead of Better Docs
Documentation tells you the rules. A setup script enforces them. A doc that says "remove ANTHROPIC_API_KEY before logging in" gets skimmed. A script that detects the conflict, explains why it's a problem, asks for permission to back up your shell config, and then unsets it — that one ships the right outcome.

The installer does five things in order:

Verify install — checks for claude, offers npm i -g @anthropic-ai/claude-code if missing
Ask one question — "Do you have a Claude subscription?" Branches from this
Detect conflicts — finds existing env vars, explains what they'd do, asks before changing
Validate — sk-ant- prefix check, length check, env var persistence check
Back up before mutating — every shell config edit gets a timestamped backup with a printed rollback command
The Cross-Platform Tax
Bash (macOS / Linux): the easy one
detect_shell_config() {
case "$SHELL" in
/zsh) echo "$HOME/.zshrc" ;;
*/bash) [[ "$OSTYPE" == "darwin" ]] && echo "$HOME/.bash_profile" || echo "$HOME/.bashrc" ;;
*) echo "$HOME/.profile" ;;
esac
}
Append the export, source the file, done.

Batch (Windows cmd): the hard one
Windows persists env vars in the registry under HKEY_CURRENT_USER\Environment. The supported tool is setx, which has two gotchas:

1024-character limit (undocumented, will silently truncate)
Doesn't update the current session — only future processes started after the setx call
So users would run the script, run claude, see the same error, and assume the script broke. The fix is to set the variable in both places:

setx ANTHROPIC_API_KEY "%KEY%"
set ANTHROPIC_API_KEY=%KEY%
echo NOTE: open a new Command Prompt window to verify persistence
PowerShell: the third path
PowerShell has $PROFILE, but you can't assume:

The profile file exists
Execution policy allows it to load
The user knows what $PROFILE is
The script gracefully degrades: profile edit → registry write → manual command shown to the user.

What "Production-Grade" Means at 17KB
I reduced it to four things:

Idempotency — running twice is safe. The second run detects the configured state and exits cleanly, no duplicate exports.
Inspectability — before any mutation, print exactly what's about to happen and wait for y/n:

About to add this line to /Users/anil/.zshrc:
export ANTHROPIC_API_KEY="sk-ant-..."
Continue? [y/N]

Reversibility — every backup is timestamped (~/.zshrc.backup_20250506_143022). Rollback is one cp command, printed to the screen.
Testability — a test suite that validates the installer without mutating user state. Sandboxes backup/restore in /tmp, regex-checks key validation, verifies cross-platform parity. Runs in <2s.

Test suite output:

(The 1 failure is a regex bug in the test, not the installer.)

The Single Best Thing I Did
Replaced a flat 6-option menu with one yes/no question:

"Do you have a Claude subscription? [y/N]"

Everything else branches from there. Conversion (people completing the script vs abandoning it mid-flow) went from "hard to measure but bad" to "essentially everyone finishes."

If you remember nothing else from this post: users don't know which auth method applies to them. They know whether they pay a subscription. Branch on that.

What I Got Wrong
Too clever about shell detection. First version parsed $SHELL, then $0, then ps -p $$ -o comm=. Over-engineered. Three lines instead of thirty was the fix.
PowerShell-first testing. Wrote canonical tests in PowerShell, hit version/encoding compat issues across Windows machines. Now the canonical suite is Bash; PowerShell is a convenience port.
Underestimated docs. The repo has a README, quick-start, contributing guide, configuration examples, project overview, deployment doc, and build summary. That sounds like a lot for 17KB of script — until you realize the script is the easy part. The diagnosis ("why am I getting charged?") lives in the docs.
Try It

Unix

git clone https://github.com/your-repo/claude-auth-setup.git
cd claude-auth-setup
chmod +x setup-claude-auth.sh
./setup-claude-auth.sh

Windows

.\setup-claude-auth.bat
MIT licensed. Issues, PRs, and bug reports all welcome. The best one I got so far was:

"It worked. Why didn't this exist already?"

I don't know either.

Repo: github.com/your-repo/claude-auth-setup

Follow me here on dev.to for more posts about the unglamorous parts of shipping production tools.

The week the agent capability inflection arrived. And what to do about the 86% that still fail.

Anil Prasad — Sat, 02 May 2026 17:48:10 +0000

By Anil Prasad

Head of Engineering and Product, Duke Energy CASPAR · Founder, Ambharii Labs

Three signals. One pattern.

Stanford released the 2026 AI Index this week. AI agents jumped from 12% to 66% success on real computer tasks in one year. That is a 5.5x capability multiplier in twelve months.

In the same week, industry research confirmed that 86 to 89% of enterprise AI agent pilots fail to reach production at scale. Apoorva Mehta launched Abundance, a hedge fund with $100M in seed funding designed to have AI agents run the entire fund. JPMorgan reported their LLM Suite is automating 360,000 manual hours annually with 83% faster research cycles for portfolio managers.

These stories are not contradictory. They describe the same reality from different angles.

The capability inflection has happened. The deployment infrastructure investment lags 18 months behind. That gap is the business opportunity of 2026.

Quick numbers before we dig in:

Monday: Stanford 12 to 66. Here is what most coverage will miss.

Stanford published the 2026 AI Index this week. The 66% number on real computer tasks will be quoted in every AI keynote for the next twelve months.

The number is real. The capability inflection has happened.
What everyone is going to miss: 66% on benchmark tasks does not equal 66% in your production environment.

Benchmarks measure: can the agent complete this task in ideal conditions with clean inputs and a defined success criterion?

Production measures: can the agent complete this task at 2 AM on Sunday when the upstream data feed is degraded, the API is throttled, and the human reviewer is asleep?

Those are different questions. The benchmark answers one. The other one decides whether your AI program ships or fails.

The capability bottleneck is gone. The readiness bottleneck just became the only bottleneck that matters.

Tuesday: 86 to 89% of pilots fail. The four reasons. All fixable.

Industry research published this month confirmed what 28 years in production AI has taught me. Agent pilots fail in predictable ways. The fixes are known. Almost nobody is applying them.

Failure mode 1: Governance breakdowns

The pilot worked. The team wants to scale. The compliance team has not seen the system yet. Six weeks of compliance review later, the pilot has lost momentum, the team has shifted to other priorities, and the agent is sitting in staging.

Fix: Compliance starts at week zero, not week sixteen. If your AI program treats compliance as a release gate, you have already lost.

Failure mode 2: Evaluation infrastructure gaps

The pilot demonstrated 84% accuracy on a curated test set. In production, the team cannot tell whether the agent is performing better or worse than baseline because they never built the evaluation framework.

Fix: Build the evaluation infrastructure before the agent. This is what G-ARVIS exists to do. Nine dimensions built from production failure, not academic theory.

Failure mode 3: Integration complexity
Integration and governance consume up to 60% of AI agent project budgets. Most teams plan for the model and underinvest in everything around it.

Fix: Plan a 60% integration budget from day one. If the team budgeted 80% for the model and 20% for integration, the project is going to overrun before it ships.

Failure mode 4: Accountability gaps
When the agent is wrong, nobody knows whose problem it is. The system fails in the gap between teams.

Fix: Assign one accountable human per agent before deployment. The work belongs to a name, not a function.

The 86 to 89% failure rate is not happening because the technology does not work. It is happening because organizations are deploying capability without the foundation to support it.

Wednesday: A2A and MCP crossed 150 production deployments. The architecture conversation just shifted.

Three months ago the question was: which orchestration framework should we use?

Today the question is: do our agents speak the right protocols?
Two protocols are emerging as the foundation of multi-agent systems in 2026.

MCP (Model Context Protocol) handles vertical connectivity. Agent to tool. Agent to data source. Agent to API.

A2A (Agent to Agent) handles horizontal connectivity. Direct peer to peer delegation between agents.

Together they replace the brittle custom integration code that has been the failure mode of multi-agent systems for the past three years.
This is the Kubernetes moment for agentic AI.

The pattern looks exactly like what happened to microservices ten years ago. Custom service discovery, custom load balancing, custom health checks. Then Kubernetes standardized all of it. The organizations that built on the standardized layer were able to scale. The ones that built proprietary versions had to rewrite their infrastructure.

Vendor lock in just changed shape too. Three years ago you locked in by choosing a model. Eighteen months ago you locked in by choosing an orchestration framework. In 2026, the lock in is at the protocol layer. Organizations that build on standardized protocols can swap models, frameworks, even vendors with bounded engineering effort.

ARGUS now supports both A2A and MCP natively. Every tool call through MCP gets logged with full audit trail. Every agent to agent message through A2A gets traced with sender, recipient, timestamp, and payload hash.

Thursday: Financial AI just had its inflection point.

Apoorva Mehta launched Abundance, a hedge fund designed to have AI agents run the entire fund with $100M in seed funding. JPMorgan's LLM Suite is automating 360,000 manual hours annually with 83% faster research cycles.

Financial services AI just crossed a threshold most other industries have not faced yet.

When AI agents are managing money, every decision is not just one inference. It is a chain of reasoning across multiple agents that has to be reconstructable when the SEC asks.

For an agent to participate in a regulated financial workflow, every decision must be:

Reconstructable months after the fact
Attributable to specific data sources at specific timestamps
Explainable in language the regulator can evaluate
Reviewable by a human with override authority

If your agent infrastructure does not support all four, the agent cannot ship into a regulated financial environment.

This is exactly the gap ARGUS is built to close. Every agent decision logged with input hash, output hash, model version, and tool calls. Full reasoning trace across multi-agent workflows. Time stamped audit log that can be replayed against the original data state.

Friday synthesis: The Ambry Genetics migration story.

We migrated a clinical genomics AI platform from MySQL to Vitess at Ambry Genetics. 99.97% uptime. Zero clinical data loss. 8 month migration during which the AI was making real recommendations for real patients.

The migration could have happened faster. We chose to optimize for safety, not speed.

What that taught me about AI in regulated environments: the model is the least constrained part of the system. Infrastructure, data governance, compliance requirements, and clinical validation processes are the actual engineering challenges.

Every AI in healthcare implementation I have seen fail, failed at infrastructure or governance. Not at model accuracy.

If you are deploying AI in healthcare, energy, or financial services, your constraint set looks more like that migration than like a benchmark optimization problem.

The Ambharii Labs platform suite

This week marks three weeks since GenomixIQ and ARIA RCM launched. Health system inquiries on FHIR R4 interoperability are validating the architectural decisions made years before launch.

AI Aether (ambharii.com/tools)
Free enterprise AI readiness assessment. 8 dimensions on the G-ARVIS framework. Board ready roadmap. 30 minutes.

ARGUS (github.com/anilatambharii/argus)
Autonomous LLM correction and agent monitoring. Now native to A2A and MCP protocols. Open source. PyPI: pip install argus-ai

GenomixIQ (genomixiq.com)
12-agent molecular mesh for genomic variant interpretation. FHIR R4 from day one. Variant Intelligence Score. Population stratified evaluation.

ARIA RCM (anil@ambharii.com)
11-agent healthcare revenue cycle platform. Three viable acquisition paths: Oracle Health, Microsoft Nuance, NVIDIA Healthcare.

One shared architecture. G-ARVIS observability across all four. ARGUS self correction built into every agent. Production grade from day one.

The week in one sentence

The agents work at scale. Most organizations are not yet ready to deploy them safely. That gap is the business opportunity of 2026.

If you are building AI in healthcare, energy, finance, or any domain where being wrong has real consequences, the questions worth sitting with this weekend are the same five I ask in every program kickoff.

What does failure look like and who does it hurt?
Who is accountable when the agent is wrong?
How does the agent know what it does not know?
What is the kill switch and who can pull it?
What does the audit trail look like nine months from now?

If your team can answer all five with specifics, you are positioned for the 11 to 14% that will succeed.

If they cannot, the foundation work is ahead of any deployment work.

About the author

Anil Prasad is Head of Engineering and Product at Duke Energy and Founder of Ambharii Labs. He serves as an AI Factory Builder at BCG and co-founded the CDAIO Circle Tri-State Chapter. He has 28 years of production AI experience across Fortune 100 companies including R1 RCM, Ambry Genetics, UnitedHealth Group, Medtronic, and Accenture. He was recognized as one of the Top 100 Most Influential AI Leaders USA 2024 and holds degrees from Stanford and BITS Pilani.

ambharii.com | linkedin.com/in/anilsprasad | @anilsprasad on X | anilsprasad.substack.com

Subscribe to Field Notes: Production AI for weekly insights from 28 years building AI in regulated environments. No benchmarks. No hype. Real deployments, real failure modes, and the infrastructure decisions that distinguish production AI from demo AI.

The week AI capability outpaced readiness. Again. Here is what it means in production.

Anil Prasad — Fri, 24 Apr 2026 12:47:57 +0000

Three events. One pattern.

Three significant things happened in AI this week. Claude Opus 4.7 launched. The EU AI Act moved into full enforcement. And a new arXiv paper, EviSearch, validated what I have been building around for six years: domain-specific multi-agent architectures outperform general ones in clinical settings.

Each story is real. Each story matters. And each story points to the same pattern I have watched repeat across 28 years of production AI in healthcare, energy, and financial services.

Capability accelerates faster than readiness. Every time.

Monday · April 20

** ## Claude Opus 4.7: the benchmark is impressive. Here is the real question.**

SWE-bench Pro reached 64.3%, up 10.9 points in a single version. SWE-bench Verified hit 87.6%. CursorBench reached 70%. Tool error rates dropped by two thirds. Self-verification built in at the model level. These are genuinely significant improvements.

But the question I am not seeing asked in any of the coverage: does your organization have the evaluation infrastructure to know whether this model is actually better for your specific use case?

The organizations that move confidently after a major model launch are not the ones with the most advanced AI. They are the ones with evaluation infrastructure that can answer four questions within 72 hours of a new model release.

Is this model better on our specific domain tasks? Is output variance within our acceptable range? What happens to cost-per-correct-output? Can our governance layer onboard this model without a compliance review starting from zero?

If you cannot answer all four within 72 hours, you are not evaluating the model. You are waiting for someone else to tell you whether to use it. That is a readiness infrastructure problem, not a model problem.

The self-verification feature is genuinely novel. Two thirds fewer tool errors means a system that needs much less constant human oversight. For multi-agent workflows running thousands of tool calls per day, that is the difference between a system that runs reliably overnight and one that requires a human on call. ARGUS operates the same self-correction principle at the system layer across the entire agent workflow, not just within a single inference.

Tuesday · April 21

EU AI Act: the audit trail is the most common gap. Here is how to close it.

The EU AI Act entered full enforcement in 2026. Fines up to 7% of global annual turnover. High-risk categories include healthcare AI, critical infrastructure, employment, and education technology. Those are the exact sectors I have spent 28 years building production AI for.

The five mandatory requirements for high-risk AI systems are: a risk management system maintained throughout the entire lifecycle, complete technical documentation, human oversight and intervention mechanisms, demonstrable accuracy and robustness, and a full audit trail.

At a Energy Enterprise, I rebuilt the entire logging layer before deploying a single agent in a live operational context. A grid operations manager asked a question I was not prepared for: "If this system makes a recommendation that causes an outage, and FERC comes knocking, can you show them exactly what the model saw, what it decided, and why?"

We could not answer that. We rebuilt. That decision delayed the launch by six weeks and saved us months of regulatory exposure eighteen months later.

ARGUS generates the full audit trail by default. Every inference logged with input hash, output hash, timestamp, and model version. Every tool call traced with actor identity and permission scope. Every human override recorded with reason and outcome. Not as a reporting feature. As the foundational observability layer. github.com/anilatambharii/argus or pip install argus-ai

Wednesday · April 22

EviSearch and the domain-specific agent case: specificity is the moat.

A paper published this week on arXiv described EviSearch, a multi-agent system that automates the creation of clinical evidence tables from medical literature using a specialized architecture. The finding was exactly what I have seen in every clinical AI program I have run: domain-specific agent architectures outperform general-purpose ones in technical domains, typically by 15 to 25 percentage points on domain-relevant evaluation tasks.

Why the gap exists: A general-purpose agent reasons about yo

This is why GenomixIQ uses 12 specialized agents rather than one large general agent. The literature agent understands how to evaluate evidence in population genetics. The ACMG criteria agent knows all 28 classification criteria and the interaction rules between them. The conflict resolution agent knows which database takes precedence when population databases disagree. None of that is prompt engineering. All of it is architectural encoding of domain expertise.

The EviSearch paper also documented that multi-agent systems for clinical evidence work show inter-run variability below 5%, compared to 15 to 30% for human reviewers on complex evidence tables. Consistency in clinical decision support is not a nice-to-have. It is the compliance requirement.

Thursday · April 23

## G-ARVIS: the nine dimensions most AI teams are not measuring.

I built the G-ARVIS framework from production failure across 28 years in regulated environments. Nine dimensions. Not from academic theory. From watching accurate models fail catastrophically because nobody was measuring the right things.

The six dimensions: Groundedness (anchored to verifiable facts), Accuracy (correct output consistently), Reliability (stable at scale across thousands of runs), Variance (output stability on the same prompt across runs), Inference Cost (cost per correct output, not cost per token), Safety (domain-specific harm profile for this domain, this use case, this failure mode).

Three agentic metrics I added specifically for multi-agent production systems: Action Sequence Fidelity (percentage of multi-step workflows completing without human intervention), Error Recovery Rate (when an agent fails, how often does the system recover without escalation), and Cost Per Correct Sequence (total inference cost divided by the number of complete sequences producing a validated correct output).

All nine are assessed in AI Aether. 73% of organizations score below 12 out of 30 on data architecture alone. The foundation problem has not changed in 28 years. Only the model on top of it has. ambharii.com/tools

The Ambharii Labs Platform

## Four platforms. One shared architecture.

This week marks two weeks since GenomixIQ and ARIA RCM launched, with ARGUS SDK updates shipping and AI Aether continuing to show the same pattern: 73% of organizations score below 12/30 on data architecture. The foundation problem precedes every other problem.

The Week in One Sentence

*## AI shipped faster than most organizations can absorb it. The gap between capability and readiness is the business opportunity of 2026.
*
If you are building AI in healthcare, energy, finance, or any domain where being wrong has real consequences, the questions I am asking every week are the same questions you should be asking: What does your AI actually do at 2 AM? Who sees the audit trail? What happens when the model is wrong in a way it has never been wrong before?

The answers to those questions are what distinguishes production AI from demo AI. That distinction is what 28 years in this field teaches you.