DEV Community: Alok Ranjan Daftuar

Multi-Cluster ArgoCD Architecture: Hub-and-Spoke vs. Per-Cluster, Done Right

Alok Ranjan Daftuar — Mon, 10 Aug 2026 05:48:33 +0000

Every ArgoCD tutorial ends with one cluster, one ArgoCD instance, and kubectl config current-context pointing at the same place ArgoCD is installed. That works fine — until you have two clusters. By the time you're at 10 or 15, across AWS and Azure, the architecture you picked on day one is either quietly paying for itself or quietly costing you an incident a quarter.

The two dominant patterns — hub-and-spoke and ArgoCD-per-cluster — are both reasonable in the right context and both wrong when applied past the cluster count and team topology they were designed for.

The Two Bad Defaults Teams Back Into

Rather than choosing deliberately, most teams end up at one of two failure modes:

ArgoCD-per-cluster sprawl — every cluster gets its own ArgoCD because that's what the getting-started guide showed. Nobody has a single view of what's deployed where. Upgrading ArgoCD becomes N separate change requests.
A single hub that becomes a bottleneck — one team stands up ArgoCD once, registers every cluster against it, and doesn't revisit that decision until the application controller is falling behind on reconciliation or a hub outage takes down deployments for every team at once.

Pattern 1: Hub-and-Spoke

One management cluster runs ArgoCD. Every other cluster is registered as a remote destination via a Secret containing that cluster's API server address and credentials.

What you get: single pane of glass, centralized RBAC and SSO, one audit trail.

What it costs you: the hub becomes a scaling bottleneck at high cluster/Application count; blast radius covers every spoke if the hub is compromised; network reachability to every spoke's API server is a real design requirement, not just an IAM policy.

Two blast-radius shapes worth planning for specifically:

Redis under memory pressure — ArgoCD's application controller caches live-vs-desired state in Redis across every Application it manages. An OOM or eviction storm on that single Redis instance stalls reconciliation for every cluster the hub manages simultaneously. From the outside it looks like "ArgoCD is stuck everywhere" — the root cause is capacity planning on a component most teams treat as an implementation detail.
A quietly broken peering path — a security group rule tightened on one spoke's cluster security group doesn't fail loudly. It shows up as that spoke going Unknown in the UI while everything else stays green, easy to dismiss as a blip until someone needs to ship a fix to that cluster and can't.

Network Reachability — The Part Tutorials Skip

On AWS: VPC peering or Transit Gateway gets the hub's control plane traffic to each spoke's private EKS API server endpoint. Private API server endpoints are the right default for spoke clusters, but every private-by-default decision adds a network path the hub now has to be deliberately connected to.

On Azure: VNet peering or Azure Private Link between the hub's VNet and each spoke AKS cluster's VNet. Same shape of problem — the hub's egress needs a routable, authorized path to a spoke's control plane.

Controller Sharding Past 10 Clusters

A hub managing 12 spoke clusters with ~50 Applications each (600 total) on a single unsharded controller will start lagging live cluster state by 3-4 minutes during normal operation, and considerably longer after a bulk change. The fix is multiple controller replicas with shard annotations on cluster secrets:

# argocd-application-controller StatefulSet
spec:
  replicas: 4

# Cluster Secret with shard annotation
metadata:
  annotations:
    argocd.argoproj.io/shard: "2"

With ARGOCD_CONTROLLER_REPLICAS=4 and shard annotations spread across 12 spoke secrets, each replica watches 3 clusters instead of all 12 — reconciliation lag drops back to single-digit seconds. This change isn't complete without also moving to a Redis HA (Sentinel-backed) deployment, since a single Redis becomes the new bottleneck once four controller replicas hit it concurrently.

Pattern 2: ArgoCD-per-Cluster

Each cluster runs its own ArgoCD instance and manages only itself.

What you get: fault isolation, no cross-cluster network dependency, clean blast radius.

What it costs you: N places to upgrade and patch; fragmented visibility; RBAC and project config duplicated N times with all the drift that implies.

Where this genuinely wins: regulated environments where a cluster's isolation boundary is a compliance requirement; air-gapped clusters with no viable network path back to a central hub; edge deployments where each site operates independently.

Cluster Registration — EKS

The clean way to register a spoke EKS cluster is IRSA or EKS access entries — not a static kubeconfig with a long-lived token. The cluster secret uses the aws eks get-token exec plugin:

apiVersion: v1
kind: Secret
metadata:
  name: spoke-eks-prod-us-east-1
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: cluster
type: Opaque
stringData:
  name: spoke-eks-prod-us-east-1
  server: https://EXAMPLE1234567890.gr7.us-east-1.eks.amazonaws.com
  config: |
    {
      "execProviderConfig": {
        "command": "aws",
        "args": [
          "eks", "get-token",
          "--cluster-name", "spoke-eks-prod",
          "--region", "us-east-1",
          "--role-arn", "arn:aws:iam::111122223333:role/argocd-hub-spoke-access"
        ],
        "apiVersion": "client.authentication.k8s.io/v1beta1"
      },
      "tlsClientConfig": { "insecure": false, "caData": "<base64 cluster CA>" }
    }

The full chain: create the IAM role on the spoke account with a trust policy scoped to the hub's IRSA role → create an EKS access entry mapping that role to a Kubernetes group → bind that group to a scoped ClusterRole (not cluster-admin) → grant the hub's IRSA service account sts:AssumeRole → apply the Secret → verify with argocd cluster list. A Successful status confirms the exec plugin chain worked end to end.

Cluster Registration — AKS

On AKS, the equivalent is Azure AD Workload Identity with the kubelogin exec plugin:

apiVersion: v1
kind: Secret
metadata:
  name: spoke-aks-prod-westeurope
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: cluster
type: Opaque
stringData:
  name: spoke-aks-prod-westeurope
  server: https://spoke-aks-prod-dns-a1b2c3d4.hcp.westeurope.azmk8s.io
  config: |
    {
      "execProviderConfig": {
        "command": "kubelogin",
        "args": [
          "get-token",
          "--login", "workloadidentity",
          "--server-id", "6dae42f8-4368-4678-94ff-3960e28e3630"
        ],
        "apiVersion": "client.authentication.k8s.io/v1beta1"
      },
      "tlsClientConfig": { "insecure": false, "caData": "<base64 cluster CA>" }
    }

The full chain: create an Azure AD application + federated identity credential binding the hub's ArgoCD service account to it → grant that application a scoped AKS RBAC role on the spoke cluster → label the hub's ArgoCD service account for workload identity → apply the Secret → verify with argocd cluster list. Auth failures here are almost always a --subject mismatch in the federated credential or the workload identity label missing from the pod spec.

Decision Framework

Cluster count	Compliance boundary	Team topology	Recommended pattern
2	None	Single platform team	Hub-and-spoke
3-5	None	Single or lightly federated	Hub-and-spoke with AppProjects
5-10	Some (staging vs. prod)	Multiple product teams	Hub-and-spoke, watch controller sharding
10-15	Regulatory/contractual isolation on specific clusters	Multiple teams, some regulated	Hybrid — hub for general fleet, per-cluster for isolated outliers
Any	Air-gapped / no viable hub network path	Any	ArgoCD-per-cluster

The hybrid row in practice: a platform team running 13 clusters — 10 standard clusters registering against the hub via IRSA/workload identity, plus 3 PCI-scoped clusters each running their own ArgoCD with no network path back to the hub, syncing from a separate access-restricted Git repository. The platform team accepts fragmented visibility for those 3 clusters in exchange for not having to argue, in every audit cycle, that the hub's blast radius doesn't touch the PCI boundary.

Read the Full Article

This is Article 1 of the GitOps in Practice series. The full article includes:

Hub-and-spoke network reachability deep-dive for EKS (VPC peering, private API server endpoints, Transit Gateway) and AKS (VNet peering, Azure Private Link)
Complete step-by-step EKS auth chain: IAM role creation, EKS access entry, ClusterRoleBinding, hub-side IRSA policy
Complete step-by-step AKS auth chain: Azure AD app, federated credential, AKS RBAC role assignment, workload identity label
Controller sharding mechanics and Redis HA requirements for fleets past 10-15 clusters
The trust-boundary thinking connecting IRSA/Workload Identity to ArgoCD's cluster auth model
What's coming in Article 2: repo structure, App-of-Apps, ApplicationSets, and AppProjects

👉 Multi-Cluster ArgoCD Architecture — Full Article

GitHub Actions OIDC: Eliminating Long-Lived Credentials from Your CI/CD Pipeline

Alok Ranjan Daftuar — Fri, 07 Aug 2026 04:49:30 +0000

Every GitHub Actions workflow that deploys to AWS or Azure needs cloud credentials. The traditional answer — generate an IAM access key or Azure client secret, store it in GitHub secrets — works, but means you have a long-lived credential that's valid until you notice it leaked and manually revoke it.

OpenID Connect eliminates this at the architectural level. Your workflow requests a short-lived token from GitHub's OIDC provider, exchanges it with AWS STS or Azure's token endpoint, and receives temporary credentials valid for the duration of the job. No secret to store. No credential to rotate. No static value to leak.

How It Works

GitHub Actions Job
    │  1. Requests OIDC token from GitHub
    ▼
GitHub OIDC Provider (token.actions.githubusercontent.com)
    │  2. Issues signed JWT (sub, repo, ref, environment, exp: 5min)
    ▼
AWS STS / Azure Token Endpoint
    │  3. Validates JWT, checks trust policy conditions
    │  4. Issues temporary credentials (15min–1hr)
    ▼
GitHub Actions Job (continues with scoped credentials)

The sub claim encodes the repository, branch, and environment — every trust policy decision is a decision about which sub values you trust.

Trust Policy Scoping — The Critical Detail

Most tutorials show the broadest condition that works. Production requires precision:

repo:org/repo:environment:production — strongest for production; coupled to GitHub Environment protection rules (required reviewers, deployment gates)
repo:org/repo:ref:refs/heads/main — good for staging; only main branch
repo:org/repo:* — acceptable for dev/sandbox only
repo:org/* — never use for anything with real permissions

The environment-scoped condition means an unapproved deployment cannot produce the token needed to assume the production role. The gate is enforced at the identity layer.

Per-Job Role Architecture

Because each job gets its own fresh token, you can scope each job to exactly the permissions it needs:

Plan job → read-only role, branch-scoped trust
Build & push job → ECR/ACR push permissions only, branch-scoped trust
Deploy job → deployment permissions, environment-scoped trust with approval gate

One role per responsibility. Minimum permissions per role. The blast radius of any single compromised job is limited to its specific task.

The Audit Trail Static Credentials Cannot Provide

Every OIDC credential issuance produces a CloudTrail event with the full GitHub context — repository, branch, workflow run, commit. The role-session-name encodes the GitHub run ID, so every subsequent API call is traceable to the exact workflow execution.

With static access keys, you see the IAM user name — shared across all workflows, with no way to distinguish which run triggered each API call.

Migration Path

The sequence that eliminates risk:

Create the IAM role / Azure federated credential with correct trust policy
Add id-token: write permission to the workflow job
Add OIDC credential step — leave static credential commented but present
Verify end-to-end on a branch
Remove static credential step
Delete the credential from the cloud provider — not just from GitHub secrets

Step 6 is what most teams defer indefinitely. The credential still exists and could be used by anyone with direct knowledge of the key.

Read the Full Article

This is a condensed version. The full article includes complete, production-ready implementations:

👉 GitHub Actions OIDC: Eliminating Long-Lived Credentials — Full Article

The full article includes:

Complete AWS setup (OIDC provider + IAM role with Terraform)
Complete Azure setup (Entra ID app registration + federated credentials)
Full workflow files for AWS ECR+ECS and Azure ACR+AKS deployments
Reusable workflow federation with job_workflow_ref claim customisation
Common failure modes and debug steps (token expiry, trust policy mismatches)
Production checklist for retiring static credentials

Cloud Security Architecture: From Shared Responsibility to Zero Trust

Alok Ranjan Daftuar — Fri, 31 Jul 2026 10:24:18 +0000

Cloud security incidents that make news are rarely the result of a novel attack technique. They are the result of misconfiguration, over-permissioned identities, and static credentials left in places where attackers have learned to look automatically.

This post covers the architectural decisions that prevent those incidents — made early, before the first breach, rather than in response to one.

1. The Shared Responsibility Model — What You Actually Own

The rows that never move to the provider regardless of service model: identity and access, application configuration, secrets management, and data encryption. Treating "we use managed Kubernetes" as implying "security is largely handled" is the category error that makes managed services into false comfort.

Three items teams most commonly miscategorise as provider responsibility:

Encryption at rest — provider-managed keys mean the provider could theoretically decrypt your data. You own the key management decision.
Network exposure — a LoadBalancer service type provisions a public IP by default. Nothing prevents a developer from exposing an internal service.
IAM overprivilege — the provider supplies IAM. What role gets attached to which workload is entirely yours.

2. IAM Least-Privilege at Scale

IAM posture degrades monotonically — it gets worse over time, never better, unless you actively intervene. Three structural controls:

ABAC over RBAC — evaluate permissions dynamically based on attributes rather than maintaining named roles that accumulate permissions
Permission boundaries — set the maximum permissions a role can ever have, regardless of what policies are attached
SCPs — organisation-wide guardrails that cannot be overridden at the account level

3. Secrets Management — No Static Credentials

70% of leaked secrets remain active 2 years after exposure. The goal: eliminate long-lived static credentials entirely.

IRSA / Workload Identity — pods assume cloud IAM roles without possessing any credential file, via OIDC federation
CSI driver mounts — secrets mounted as files, refreshed on rotation without pod restart
The rule: no secret should ever appear in a Docker image, Kubernetes manifest, GitHub repository, CI/CD log, or environment variable

4. Network Segmentation

Network controls reduce blast radius when an identity is compromised. A well-segmented VPC separates traffic by function and trust level:

Public subnets (ALB/NLB only) → Private app subnets → Private data subnets
VPC endpoints for all cloud services (S3, Secrets Manager, ECR, STS)
No application or data tier resource has a public IP

5. Zero Trust for Kubernetes

Kubernetes ships open-by-default. Three gaps to close:

Default-deny NetworkPolicy in every namespace, with explicit allow policies for required communication
Pod Security Admission — baseline enforced on application namespaces, restricted warned
One ServiceAccount per workload — automountServiceAccountToken: false at SA level, opt-in per pod

6. CI/CD Pipeline Security

OIDC authentication — no long-lived credentials stored in GitHub secrets
Image signing at build, verification at admission — unsigned images rejected
Vulnerability scanning blocking — high/critical CVEs fail the build
Secret scanning on push — any secret in source control treated as compromised

7. Detection — What to Alert On

High-signal events: root account login, IAM policy changes in production, security group rules allowing 0.0.0.0/0, CloudTrail disabled, kubectl exec into production pods, secrets accessed from unexpected roles.

Enable GuardDuty / Defender for Cloud before you need them — post-incident enablement loses the historical baseline.

Read the Full Article

This is a summary of the fifth and final post in the Cloud Architecture series. The full article includes detailed IAM policy examples, IRSA/Workload Identity configuration, NetworkPolicy manifests, Pod Security Admission labels, GitHub Actions OIDC setup, and a comprehensive production-readiness checklist:

👉 Cloud Security Architecture: From Shared Responsibility to Zero Trust — Full Article

The full article includes:

Shared responsibility matrix across IaaS/CaaS/PaaS
Permission boundary and SCP JSON examples
IRSA and Workload Identity ServiceAccount configuration
Secrets Manager CSI driver SecretProviderClass manifest
Default-deny NetworkPolicy with explicit allow rules
Pod Security Admission namespace labels
GitHub Actions OIDC workflow with scoped trust policy
Complete cloud security architecture checklist (25+ items)

Embedding Model Selection for Production: The Decision Nobody Documents

Alok Ranjan Daftuar — Tue, 28 Jul 2026 08:16:17 +0000

Every RAG architecture diagram has a box labeled "embed." Almost nobody documents how that box's contents got chosen, and almost everybody regrets the choice within eighteen months. Changing embedding models means re-embedding your entire corpus — vectors from different models are not compatible.

Why This Decision Matters

Retrieval quality is bounded by embedding quality. A perfectly tuned chunking strategy, re-ranker, and hybrid pipeline cannot retrieve a document whose embedding never placed it near the query in vector space. And the cost of getting this wrong is not a quick fix — it's a migration project.

What MTEB Tells You (and Doesn't)

MTEB is a reasonable first filter — it aggregates performance across retrieval, classification, and clustering tasks. What it does NOT tell you: how a model performs on your documents.

Practical rule: Use MTEB to build a shortlist of 3–5 candidates. Never to make the final decision.

Benchmark on Your Own Corpus

The only benchmark that predicts production retrieval quality is one run against your own documents and representative queries. Build a golden set of 80–100+ query-to-relevant-document pairs, run each candidate through the same pipeline, measure Recall@K and MRR.

The gap between MTEB rank and corpus-specific performance is frequently large enough to flip a recommendation.

Dimensionality and Matryoshka Trade-offs

Matryoshka Representation Learning (supported by most 2026 providers) lets you truncate a 3072-dim vector to 512 or 256 dimensions post-hoc without re-running the model. This enables:

Full dimensions for high-precision compliance search
Truncated dimensions for low-latency autocomplete on the same corpus
No separate embedding pass required

Benchmark the quality drop at each truncation point before committing.

Cost Modeling at Scale

Two components that scale differently:

Indexing cost — one-time, proportional to corpus size
Query cost — ongoing, proportional to traffic volume

A model that looks cheap per-token can be expensive at your actual corpus size. Model cost at your real numbers, not the pricing page.

The Re-Embedding Migration Problem

Vectors from different models are not interchangeable. Switching providers means re-embedding the entire corpus. The mitigation is architectural:

Design the re-indexing pipeline before you need it
Use dual_write strategy: write both old and new vectors during transition
Benchmark new collection against golden set before atomic cutover
Prefer self-hosted models when deprecation risk is the primary concern

When Fine-Tuned Embeddings Beat General-Purpose

Fine-tuning reliably improves retrieval by 10–30% for genuinely specialized domains. But only move to fine-tuning if your corpus benchmark shows a real, sustained gap — not a hypothetical concern.

Check whether a domain-specific model already exists (e.g., code-specific variants) before investing in custom fine-tuning.

Read the Full Article

This is a summary of the seventh post in the RAG and AI Engineering series. The full article includes complete benchmarking code, cost modeling functions, the re-indexing migration architecture, decision matrix, and production checklist:

👉 Embedding Model Selection for Production — Full Article

The full article includes:

Python benchmarking code for corpus-specific Recall@K and MRR evaluation
Matryoshka truncation implementation with re-normalization
Cost modeling function at actual corpus and traffic scale
Re-embedding migration architecture with dual-write cutover strategy
Decision matrix by situation (multilingual, code, regulated, budget-constrained)
Complete embedding selection checklist for production readiness
When fine-tuned domain embeddings are justified vs premature

Cloud Cost Architecture: Engineering FinOps Into the System, Not Onto It

Alok Ranjan Daftuar — Mon, 20 Jul 2026 09:30:40 +0000

Cost is an architectural concern, not a finance concern. The decisions that determine your cloud bill are made in pull requests touching Terraform files and Kubernetes manifests — weeks before the invoice arrives. By the time finance highlights the line items, the spend has already happened.

Cloud waste consumes 30–50% of cloud budgets. The bulk is not accidental extravagance — it is the accumulated result of architectural decisions made without cost visibility at the time they were made.

1. FinOps Maturity — Where You Actually Are

Most organisations overestimate their maturity by one stage. The diagnostic: can you tell, within five minutes, which team or service generated a specific line item on last month's bill? If not, you're in Crawl regardless of how sophisticated your dashboard looks.

Most organisations see 15–20% waste reduction from showback alone — just making costs visible changes behaviour.

2. Commitment Tiers as Architecture Decisions

The commitment model constrains the operational assumptions your workload can make:

On-Demand — unpredictable burst, new workloads not yet baselined
Savings Plans — 20–66% discount, flexible across instance types
Reserved Instances — 40–72% discount, locked to specific instance family
Spot/Preemptible — up to 90% discount, two-minute eviction notice

The rule: baseline on on-demand for 2–4 weeks before committing. Savings Plans before Reserved Instances for flexibility.

3. Cost Allocation Tagging

Only 22% of companies have allocated 75%+ of their cloud costs. The gap is almost always a tagging gap.

Four mandatory tags enforced at provisioning time: team, environment, service, cost-centre. Resources without them are rejected at creation — not documented for later.

4. Showback Before Chargeback

Chargeback requires teams to trust the attribution model. That trust requires correct tags, understood allocation logic, and fair shared-cost treatment. None of that exists at the Crawl stage.

Introduce showback first, run it for a full quarter, fix attribution disputes, then move to chargeback.

5. Kubernetes Cost Attribution

When 50 services share a node pool, standard billing reports are useless. OpenCost (CNCF) and Kubecost provide per-pod and per-namespace cost breakdowns based on actual utilisation relative to node cost.

ResourceQuotas are the Kubernetes-native cost governance primitive — apply one to every tenant namespace.

6. Pipeline Cost Gates

The highest-leverage FinOps capability: a cost gate in CI/CD that shows projected cost impact before merge. Infracost analyses Terraform plans and returns a monthly dollar diff in the pull request.

If the projected increase exceeds a threshold, the check fails and the PR cannot merge without explicit override.

7. Guardrails That Block, Not Just Alert

Instance type restrictions — SCPs/Azure Policy restrict GPU and large families in non-production
Idle resource cleanup — unattached volumes, orphaned IPs detected and remediated by policy
Dev environment cost caps — CronJobs scale non-production to zero outside business hours

8. Structural Wastes to Eliminate First

Egress cost from co-located-on-prem services now crossing AZs
Overprovisioned node pools with untuned autoscaler scale-down
Cross-region data transfer not modelled before architecture decisions
Unused reserved capacity below 70% utilisation
Storage in standard tiers that should be in lifecycle-managed cold storage

Read the Full Article

This is a summary of the fourth post in the Cloud Architecture series. The full article includes Infracost GitHub Actions workflow, Azure Policy JSON for tag enforcement, Kubernetes ResourceQuota and CronJob manifests, commitment tier decision matrix, and a comprehensive cost architecture checklist:

👉 Cloud Cost Architecture: Engineering FinOps Into the System, Not Onto It — Full Article

The full article includes:

FinOps Crawl/Walk/Run maturity assessment with next actions per stage
Commitment tier decision matrix with discount ranges and risk profiles
Azure Policy JSON for mandatory tag enforcement at provisioning
Kubernetes ResourceQuota manifest for namespace cost governance
Infracost GitHub Actions workflow with threshold-based cost gate
CronJob manifest for non-production scale-to-zero outside business hours
Structural waste audit across egress, node pools, data transfer, reservations, and storage
Complete cloud cost architecture checklist (15 items)

I Almost Lost an Entire Blog with git reset --hard (And Git Saved Me)

Alok Ranjan Daftuar — Wed, 15 Jul 2026 11:24:26 +0000

What started as a routine cleanup became a lesson in Git's resilience — and a reminder that understanding the model matters more than memorizing commands.

The Moment Everything Disappeared

I had a feature branch with a freshly committed blog post. I was tidying up my local repository — something I'd done a hundred times before. Then, almost on autopilot:

git checkout blogs/microservices-by-def
git reset --hard 65515962bc35fe08514f0b1dcad58cb89773bd2d

The terminal didn't flinch. No warning. No confirmation prompt.

My article was gone. Hours of writing — vanished in under a second.

What Actually Happened

Before:   A ── B ── C ── D  ← my blog commit
After:    A ── B ── C  ← pointer moved here (D still exists, orphaned)

Git didn't delete my commit. It just moved the branch pointer. The commit was still there — floating, unreachable, but alive.

The Mental Model That Changes Everything

Git doesn't store files. It stores snapshots. A branch is just a pointer. git reset relocates that pointer — it doesn't destroy history.

The commit persists until garbage collection prunes unreachable objects (which doesn't happen immediately).

The Recovery: `git reflog`

git reflog show blogs/microservices-by-def

6551596 reset: moving to 65515962bc35...
0434e98 commit: added blog on Microservices by Default

Recovery took one command:

git reset --hard 0434e98

Everything came back.

The Three Reset Modes

Command	Working Tree	Index	HEAD
`git reset --soft`	✗	✗	✓
`git reset --mixed`	✗	✓	✓
`git reset --hard`	✓	✓	✓

--hard rewrites all three areas. That's why my files disappeared.

Quick Decision Matrix

I want to...	Use
Undo a local commit	`git reset`
Undo a pushed commit	`git revert`
Recover lost work	`git reflog`
Save work temporarily	`git stash`
Restore a single file	`git restore`
Clean up commit history	`git rebase -i`

Key Takeaways

Commit early, commit often. Small commits are cheap insurance.
Push important milestones. Remote refs survive local disasters.
Learn reflog before you need it. In a panic, you won't have time to read docs.
Never panic after a bad Git command. Most mistakes are recoverable.

The full post covers merge vs rebase, interactive rebase, reword, cherry-pick, stash, git fsck, and why linear history matters for CI/CD.

👉 Read the complete guide on my blog

Multi-AZ by Default: When High Availability Costs More Than the Downtime It Prevents

Alok Ranjan Daftuar — Mon, 13 Jul 2026 06:54:00 +0000

"Enable Multi-AZ for all production databases." It appears in every best-practice guide. Like "make everything private," it sounds unambiguously correct. More availability is better.

Multi-AZ for RDS doubles your database instance cost. Exactly doubles. A db.r8g.2xlarge at $700/month becomes $1,401/month. Ten such instances: $84,100/year in availability premium. That number needs a business case before it's treated as a default.

What Multi-AZ Actually Provides (and Doesn't)

Provides:

Synchronous standby in a different AZ (same region)
Automatic failover in 35–60 seconds
Zero data loss (RPO = 0)

Does NOT provide:

Protection against regional outages (standby is same region)
Read scalability (standard standby is not readable — sits idle)
Protection against data corruption or accidental deletion (replicated instantly)

When Multi-AZ Is Unnecessary

Dev/staging/QA — protecting against a problem that doesn't exist. No user impact from staging downtime.
Internal tooling — 50 users, business hours only. 30-minute restore is acceptable.
Batch processing — re-run the job when the database recovers. Retry logic is cheaper than 2x cost.
Stateless app tiers on Kubernetes — topology spread constraints provide multi-AZ resilience at zero cost.

When Multi-AZ IS Worth It

Customer-facing, revenue-generating workloads ($50K/hour revenue loss justifies the premium instantly)
Contractual SLA commitments (99.9%+ uptime)
Regulated industries (HIPAA, PCI-DSS, SOC 2)
Large databases with slow restore (5TB snapshot restore exceeds acceptable RTO)

The Decision Framework

Step 1: What is the business cost of 1 hour of downtime?
Step 2: Multi-AZ annual premium vs expected annual downtime cost
Step 3: Can snapshot restore meet your RTO?
Step 4: Environment rule — dev/staging/QA = Single-AZ, always

If the Multi-AZ premium exceeds the expected annual cost of downtime, Single-AZ with a tested restore procedure is the right answer.

The Environment Rule (No Exceptions)

Production, customer-facing:   Evaluate with framework
Production, internal tooling:  Single-AZ unless justified
Staging:                       Single-AZ, always
Development:                   Single-AZ, always

Disabling Multi-AZ on non-production environments alone saves $3,118/year per database.

Read the Full Article

This is a summary of the second post in the Cloud Defaults Reconsidered series. The full article includes detailed cost breakdowns, cross-AZ transfer calculations, Aurora comparison, automated restore alternatives, and a complete decision framework:

👉 Multi-AZ by Default — Full Article

The full article includes:

Exact RDS pricing comparison across instance types (Single-AZ vs Multi-AZ)
Cross-AZ data transfer cost calculations
Non-production environment savings breakdown
Common misconceptions debunked (99.99% uptime, data loss protection, backups)
Kubernetes topology spread constraint manifest for free multi-AZ resilience
Aurora vs RDS Multi-AZ cost comparison
Break-even calculation template
Practical recommendations table by workload type

Modernising the Lifted Workload: The Architectural Decisions That Separate Cloud-Native from Cloud-Hosted

Alok Ranjan Daftuar — Thu, 09 Jul 2026 09:21:26 +0000

Kubernetes does not make your architecture better automatically. Moving a lifted workload into a Deployment manifest without addressing stateful assumptions, chatty patterns, and observability voids is lift-and-shift at the container level.

This post covers the graduation path from "it's running on VMs" to genuinely cloud-native.

1. Workload Assessment — Four Categories, Four Paths

Not all lifted workloads have the same modernisation path:

Stateless, well-behaved → containerise directly
Stateful, extractable → externalise state first, then containerise
Tightly coupled monolith → strangler fig pattern
Low-ROI legacy → managed service substitution or decommission

The key diagnostic: if we modernise this, what specifically becomes easier to operate, scale, or change? If the answer is "nothing in particular," don't containerise it.

2. Managed Service Substitution

Before containerising anything: does this workload need to run as a custom-deployed service at all?

A self-hosted RabbitMQ cluster in Kubernetes requires provisioning, PV management, PDB configuration, Helm upgrades, TLS rotation, and on-call coverage. SQS or Azure Service Bus handles all of that for you.

The rule: managed services transfer operational complexity to the provider in exchange for reduced control. That trade is almost always worth it for infrastructure that is not a source of competitive differentiation.

3. Stateless Redesign — The Non-Negotiable First Step

Kubernetes's core model depends on pods being disposable. Three standard moves:

Externalise session state — replace in-process stores with Redis
Externalise file storage — replace local filesystem writes with object storage
Externalise scheduled jobs — replace in-process timers with CronJobs (concurrencyPolicy: Forbid)

An application that holds state in process memory will behave incorrectly in Kubernetes in ways that are hard to reproduce in staging.

4. The Strangler Fig Pattern

The only widely proven technique for decomposing a monolith without a big-bang rewrite:

Place a routing layer in front of the monolith
Extract one bounded context at a time
Route that context's traffic to the new service
Validate under production traffic
Repeat until the monolith handles nothing

Three rules: start with the least risky extraction (not the most valuable), never share a database between monolith and extracted service, validate under real traffic before decommissioning the old code path.

5. Kubernetes Readiness Criteria

Before containerising:

Health probes are meaningful — readiness checks actual application state, liveness checks only process health (never external dependencies in liveness)
Resource requests and limits measured — from real profiling, not guesses
Graceful shutdown implemented — SIGTERM handled, in-flight requests complete before pod exits

6. Autoscaling That Reflects Real Load

CPU is a poor proxy for load in most lifted workloads:

CPU-based HPA — only for compute-bound workloads
Custom metrics HPA — for request-rate-driven services
KEDA — for queue consumers and event processors; scales to zero when idle

minReplicaCount: 0 in non-production environments means queue consumers cost nothing when idle.

7. The Modernisation Sequencing

Never stop shipping. Allocate 20–30% of each sprint to modernisation. The order that works:

Stateless redesign
Observability pipeline
Managed service substitutions
Routing layer
First bounded context extraction
Progressive extraction

Observability comes second, not last — you cannot safely extract services you cannot observe.

Read the Full Article

This is a summary of the third post in the Cloud Architecture series. The full article includes workload assessment matrices, managed service substitution tables, strangler fig architecture diagrams, Kubernetes probe configuration, KEDA ScaledObject manifests, and a comprehensive modernisation readiness checklist:

👉 Modernising the Lifted Workload — Full Article

The full article includes:

Four-category workload assessment with recommended paths
Managed service substitution table (message brokers, caches, search, schedulers, secrets)
Stateless redesign patterns with CronJob manifest (concurrencyPolicy: Forbid)
Strangler fig pattern with five-phase ASCII architecture diagram
Kubernetes readiness/liveness probe configuration with anti-patterns
KEDA ScaledObject for SQS-driven autoscaling with scale-to-zero
Modernisation sequencing order with sprint allocation guidance
Complete modernisation readiness checklist (13 items)

GraphRAG vs. RAG: When Knowledge Graphs Earn Their Complexity

Alok Ranjan Daftuar — Thu, 02 Jul 2026 04:55:57 +0000

Vector search tells you which chunks are similar to your query. GraphRAG tells you how entities in your corpus relate to each other. Those are different questions — and most teams reach for the graph before confirming they're actually asking the second one.

The Problem Flat Retrieval Can't Solve

"Which suppliers does our highest-risk vendor share ownership with?" "What's the chain of approvals that led to this incident?" These queries aren't well-served by top-K similar chunks — the answer isn't in any single chunk. It exists in the structure connecting multiple entities across the corpus.

GraphRAG replaces or augments chunk-based retrieval with a knowledge graph — entities as nodes, relationships as edges — that the system can traverse to answer structural questions similarity search cannot.

Benchmark Reality

GraphRAG's advantage is concentrated in multi-hop and relational query classes. On single-fact lookups, it's close to nonexistent — sometimes negative once you account for extraction cost.

Before building anything: classify 200+ real production queries as "relational" vs "single-fact." If relational queries are under 15% of traffic, GraphRAG's benchmark gains won't materialize at your actual query mix — but extraction cost still applies to 100% of documents.

The Cost Problem (and How It Got Solved)

Microsoft's 2024 implementation: $33K indexing cost for large datasets. The fix in 2026:

Selective extraction — only documents likely to contain relational content go through the expensive LLM pass
Cheap-model-first — lightweight model for bulk extraction, expensive model for ambiguous cases only
Hybrid classical NLP + LLM — named-entity recognition handles entity identification, LLM reserved for relationship typing
Relation-free construction — build entity co-occurrence structure first, type relationships only when queries need them

Combined: 10-90% cost reduction depending on corpus characteristics.

GraphRAG vs. Agentic Multi-Hop Retrieval

Both solve multi-hop questions. Different trade-offs:

Agentic retrieval — pays cost at query time, only for queries that need it. No corpus-wide preprocessing. But reasoning paths are probabilistic — two runs can take different paths.

GraphRAG — pays cost at ingestion time, once. Gets deterministic traversal: same query, same path, same answer, every time. Critical for compliance, audit, and risk contexts where "the system gave a different answer last time" is itself a problem.

Decision rule: occasional, varied relational queries → agentic retrieval. Frequent, recurring relational patterns needing consistent answers → graph.

The Hybrid Architecture

In production, GraphRAG is a third retrieval tool alongside vector and BM25, not a replacement. Route per query:

Graph-only: purely relational ("who is connected to X")
Vector-only: content-similarity ("explain concept Y")
Hybrid: use graph to narrow the search space to a relevant neighborhood, then vector-search within it

The Key Insight

GraphRAG is not "RAG, but better." It's a different retrieval primitive — applicable when queries are about relationships rather than content. The graph is a cost center until your query distribution proves otherwise.

Audit the query distribution first. If relational share is small, agentic multi-hop gets most of the benefit at a fraction of the commitment.

Read the Full Article

This is a summary of my deep dive into GraphRAG architecture. The full article covers the complete evaluation and implementation guide:

👉 GraphRAG vs. RAG: When Knowledge Graphs Earn Their Complexity — Full Article

The full article includes:

What a knowledge graph actually adds (and what it doesn't)
Benchmark evidence breakdown — when GraphRAG helps and when it hurts
Graph construction cost anatomy (extraction + community summarization)
Four techniques that cut the 2024 cost problem (selective extraction, cheap-model-first, hybrid NLP, relation-free construction)
Three graph traversal patterns (local, global, multi-hop path)
GraphRAG vs agentic multi-hop retrieval — direct comparison with decision rule
Hybrid architecture with routing (graph + vector together)
Production failure modes specific to graphs (entity resolution drift, stale edges, community cascade)
Decision checklist for committing to graph infrastructure

Context Engineering: The Discipline That Determines What Your LLM Actually Sees

Alok Ranjan Daftuar — Mon, 29 Jun 2026 08:11:02 +0000

Prompt engineering asks: how do I phrase this instruction? Context engineering asks: what information does the model need, in what form, in what order, and how much of it — to produce a correct answer?

For a long time, the implicit mental model was: give the LLM more context and it performs better. This is wrong. A 20,000-token window stuffed with weakly relevant content produces worse answers than a 4,000-token window with precisely curated information. Larger windows do not eliminate context quality problems — they amplify them.

The Context Window Is a Budget

Treat it as a budget with competing line items, not a container you fill. Start with the total window, subtract fixed allocations (system prompt, output reserve, safety margin), and what remains is your dynamic budget split across retrieved chunks, conversation history, and memory.

The first question should always be: "can we get better at selecting less, rather than including more?"

Four Memory Types, Four Purposes

Episodic — conversation history. Highest priority for continuity. Grows unbounded — needs compression.
Semantic — durable facts about the user (role, team, preferences). Compact, injected in system prompt before retrieved content.
Procedural — reusable workflows and SOPs. Retrieved selectively when the query type matches.
Working — intermediate results within a single request (agentic loop output). Ephemeral, request-scoped.

Each type has different durability, update frequency, and token cost. Conflating them into a single undifferentiated store is the most common memory architecture mistake.

Structured Injection Patterns

XML tags for section boundaries (<documents>, <user_context>, <instructions>) — gives the model clear anchors for where information types begin and end
Indexed documents — label chunks with indices so citations can be traced
Ordering matters — most relevant content first (primacy effect), user query last (recency effect)
Grounding instruction is not optional — explicit instruction to use only provided context and signal when insufficient

Lost-in-the-Middle

Models attend more strongly to content near the beginning and end of the context window. Information buried in the middle receives less attention. Mitigations:

Relevance-ordered injection (highest score first)
Sandwich pattern (critical content at both start and end)
Active relevance filtering (exclude low-scoring chunks even if they fit)
Smaller, tighter windows (fewer high-quality chunks > more mediocre chunks)

Conversation Compression

A 100-turn conversation consumes your entire retrieved context budget. Naive truncation loses critical early constraints. Solutions:

Sliding window with pinned turns — critical turns (user constraints, decisions) never truncated
Progressive summarization — compress old segments into 3-5 sentence summaries using Haiku (cheap, mechanical task)

Context Assembly Is Testable

Unit test your assembly layer: budget compliance, ordering preserved, critical turns survive truncation, no mid-chunk truncation. Every assembly failure produces a predictable RAGAS metric signature — context precision drops point to noisy inclusion, faithfulness drops point to contradictions.

Read the Full Article

This is a summary of my deep dive into context engineering. The full article covers the complete discipline with production implementations:

👉 Context Engineering: The Discipline That Determines What Your LLM Actually Sees — Full Article

The full article includes:

Context window budget accounting with Python dataclasses
Four memory types with implementation patterns (episodic, semantic, procedural, working)
Working memory bridge from agentic retrieval loops
XML-structured injection with document indexing
Primacy/recency ordering strategy
Progressive summarization with critical turn pinning
Lost-in-the-middle mitigation (4 strategies with code)
Contradiction detection and resolution
Noise taxonomy (stale, tangential, redundant, over-retrieved)
Unit testing context assembly
AssemblyMetadata integration with RAGAS eval pipeline
RAGAS metric → assembly failure mapping table
Production checklist (19 items)

Agentic RAG: Designing Self-Correcting Retrieval Loops for Production

Alok Ranjan Daftuar — Mon, 22 Jun 2026 05:59:20 +0000

Standard RAG retrieves once and hopes for the best. Agentic RAG retrieves, reflects, decides it was wrong, and tries again — without being told to.

Single-pass RAG has a fundamental flaw: it commits to its first retrieval attempt and generates forward regardless. It has no mechanism to check whether the retrieved chunks actually contain the answer. This works for simple factual queries. It breaks on multi-hop questions, ambiguous intent, and analytical queries requiring sequenced lookups.

The Architecture

An agentic RAG system treats retrieval as a tool available to a reasoning loop. The LLM decides what to retrieve, evaluates what came back, and determines when to stop.

The key component: a reflection agent sits between retrieval and generation. It evaluates the quality and sufficiency of accumulated context and either terminates the loop or sends it back with a refined query.

Three patterns in increasing complexity:

Iterative Query Refinement — single tool, query rewritten per pass
Multi-Tool Orchestration — agent selects between keyword, semantic, hybrid, and filtered search
Hierarchical Decomposition — planner splits multi-hop queries into dependent sub-queries

Routing: The Most Important Decision

Sending every query through the agentic path is the most common mistake. Agentic retrieval adds 2-8s latency and 4-12x cost. Simple factual queries (60-75% of typical traffic) get no quality improvement from it.

Use a hybrid router: deterministic rules first (regex patterns, length heuristics, keyword signals), LLM classification only for ambiguous cases. Use Haiku for routing — it's a classification task, not a reasoning task.

Reflection Agent: Deciding When to Stop

The reflection agent's judgment quality determines the entire system's utility. Calibrate it against real queries:

Iteration 1: 65-75% of queries should terminate (simple queries succeeding on first pass)
Iteration 2: 15-20% (needed one refinement)
Iteration 3: 5-10% (multi-hop or genuinely ambiguous)
Iteration 4+: <5% (forced termination — investigate these)

If significant traffic hits max iterations, either routing is broken or your corpus has coverage gaps.

Failure Isolation and Loop Bounding

Without explicit bounding, misbehaving loops drive latency and cost to unacceptable levels. Non-negotiable limits:

max_iterations: 4 — never exceed
timeout: 12s — wall-clock for entire loop
min_new_chunks_per_iteration: 1 — if retrieval returns nothing new, break immediately
context token budget — stop accepting chunks beyond the budget

On timeout or max iterations: generate with accumulated context + caveat, never return a 500 error.

Cost Reality

Single-pass RAG:     ~$0.003/request
Agentic (2 iter):    ~$0.006/request  (2x)
Agentic (4 iter):    ~$0.010/request  (3-4x)

If 25% of traffic goes agentic at 2.5x cost → 37% total increase (acceptable). If 75% goes agentic → costs triple (likely unacceptable). The router controls your bill.

The Key Insight

An agentic system with no observability is not an improvement over single-pass — it's a more expensive pipeline that's harder to debug. The loop delivers quality improvement only when it is instrumented, bounded, and its behavior is understood at the query level.

Agency without accountability is just unpredictability.

Read the Full Article

This is a summary of my deep dive into agentic RAG architecture. The full article covers the complete system with production implementations:

👉 Designing Self-Correcting Retrieval Loops for Production — Full Article

The full article includes:

Full agentic RAG architecture diagram (router → planner → loop → generation)
Query planner implementation with multi-hop decomposition (Python/Anthropic)
Iterative retrieval loop with async timeout and dedup
Reflection agent prompt and calibration patterns
Multi-tool orchestration with Claude tool-use API
Hybrid router (rules-first + LLM fallback)
Loop bounding with five hard limits
Graceful degradation with context caveats
Per-request cost model (single-pass vs 2-iter vs 4-iter)
Latency budget breakdown and streaming response pattern
Structured loop telemetry with structlog
Alerting metrics for agentic systems
Production deployment checklist

LLM Evaluation in Production: Building the Eval Pipeline That Runs on Every Deploy

Alok Ranjan Daftuar — Wed, 17 Jun 2026 13:22:36 +0000

Everyone ships the RAG system. Almost nobody ships the eval system that tells them when the RAG system starts lying.

You updated the embedding model. Tweaked the system prompt. Swapped the re-ranker. Metrics look fine. Three weeks later, support tickets arrive — the system is drawing inferences the source documents never made. No alarm fired. No test failed. The system drifted silently.

This is not a model quality problem. It is an evaluation infrastructure problem.

The Four Metrics That Matter

Faithfulness — of the claims in the response, what fraction are directly supported by the retrieved context? Your primary hallucination guard. Does not require ground truth.

Answer Relevance — how directly does the response address the user's question? Catches the "technically correct but useless" failure mode. Does not require ground truth.

Context Precision — of the retrieved chunks, what fraction were actually relevant? Requires ground truth. Belongs in offline CI eval.

Answer Correctness — how factually accurate vs the reference answer? Most expensive, requires curated ground truth. Pre-deploy regression suite only.

Operational rule: Faithfulness and Answer Relevance run on every deploy and on sampled production traffic. Context Precision and Answer Correctness run in CI against the golden dataset.

LLM-as-Judge: The Pattern and Pitfalls

RAGAS uses an LLM to evaluate LLM output — the only practical way to evaluate semantic quality at scale.

Pitfalls to manage:

Positional bias — randomize order in pairwise comparisons
Verbosity bias — judge rates longer answers higher even when less accurate
Self-preference — use a different model family as judge than the one generating answers
Calibration drift — pin judge model to a specific version; treat upgrades as baseline resets

Calibrate against human labels using Cohen's Kappa on 50-100 examples. Below 0.4 means your judge prompt needs revision.

CI/CD Integration

The eval pipeline triggers on every PR touching RAG code, prompts, or model configuration:

Run RAG pipeline against golden dataset (100+ curated questions)
Score with RAGAS (faithfulness, relevance, precision, correctness)
Compare against baseline — block deploy if regression exceeds threshold
Post results as PR comment with per-metric scores and pass/fail status

Cost: ~$0.50-$2.00 per full eval run at Claude Sonnet pricing. On PRs, run only faithfulness + relevance (cheapest). Full suite runs nightly.

Production Sampling

CI catches regressions from code changes. Production sampling catches drift from corpus staleness, query distribution shift, and model behavior changes.

Sample 5% of live traffic for async evaluation. Never evaluate synchronously — judge calls add 2-5s per request. Track 7-day rolling faithfulness and answer relevance. Alert when they drop >0.05 from monthly baseline.

The Key Insight

LLM systems do not have stable, deterministic behavior. They drift through corpus changes, model updates, prompt evolution, and query distribution shift. Evaluation is not a checkpoint — it is continuous infrastructure.

Build the eval system before you need it. By the time you need it, it is already too late — you will be debugging a production quality regression with no historical baseline and no automated detection.

Read the Full Article

This is a summary of my deep dive into LLM evaluation infrastructure. The full article covers the complete eval stack with implementation examples:

👉 LLM Evaluation in Production — Full Article

The full article includes:

Evaluation stack architecture (retrieval layer vs generation layer)
Four metrics with RAGAS Python implementations
LLM-as-Judge faithfulness prompt with claim-level scoring
Judge calibration against human labels (Cohen's Kappa)
RAGAS configuration with Claude as judge model
Regression threshold framework (absolute + delta from baseline)
Golden dataset generation, versioning, and holdout partitions
Full GitHub Actions eval pipeline (YAML + runner scripts)
Production sampling with async eval queue worker
Eval observability dashboard schema (PostgreSQL)
Eight failure modes in eval systems and mitigations
Production deployment checklist

DEV Community: Alok Ranjan Daftuar

Multi-Cluster ArgoCD Architecture: Hub-and-Spoke vs. Per-Cluster, Done Right

The Two Bad Defaults Teams Back Into

Pattern 1: Hub-and-Spoke

Network Reachability — The Part Tutorials Skip

Controller Sharding Past 10 Clusters

Pattern 2: ArgoCD-per-Cluster

Cluster Registration — EKS

Cluster Registration — AKS

Decision Framework

Read the Full Article

GitHub Actions OIDC: Eliminating Long-Lived Credentials from Your CI/CD Pipeline

How It Works

Trust Policy Scoping — The Critical Detail

Per-Job Role Architecture

The Audit Trail Static Credentials Cannot Provide

Migration Path

Read the Full Article

Cloud Security Architecture: From Shared Responsibility to Zero Trust

1. The Shared Responsibility Model — What You Actually Own

2. IAM Least-Privilege at Scale

3. Secrets Management — No Static Credentials

4. Network Segmentation

5. Zero Trust for Kubernetes

6. CI/CD Pipeline Security

7. Detection — What to Alert On

Read the Full Article

Embedding Model Selection for Production: The Decision Nobody Documents

Why This Decision Matters

What MTEB Tells You (and Doesn't)

Benchmark on Your Own Corpus

Dimensionality and Matryoshka Trade-offs

Cost Modeling at Scale

The Re-Embedding Migration Problem

When Fine-Tuned Embeddings Beat General-Purpose

Read the Full Article

Cloud Cost Architecture: Engineering FinOps Into the System, Not Onto It

1. FinOps Maturity — Where You Actually Are

2. Commitment Tiers as Architecture Decisions

3. Cost Allocation Tagging

4. Showback Before Chargeback

5. Kubernetes Cost Attribution

6. Pipeline Cost Gates

7. Guardrails That Block, Not Just Alert

8. Structural Wastes to Eliminate First

Read the Full Article

I Almost Lost an Entire Blog with git reset --hard (And Git Saved Me)

The Moment Everything Disappeared

What Actually Happened

The Mental Model That Changes Everything

The Recovery: git reflog

The Three Reset Modes

Quick Decision Matrix

Key Takeaways

Multi-AZ by Default: When High Availability Costs More Than the Downtime It Prevents

What Multi-AZ Actually Provides (and Doesn't)

When Multi-AZ Is Unnecessary

When Multi-AZ IS Worth It

The Decision Framework

The Environment Rule (No Exceptions)

Read the Full Article

Modernising the Lifted Workload: The Architectural Decisions That Separate Cloud-Native from Cloud-Hosted

1. Workload Assessment — Four Categories, Four Paths

2. Managed Service Substitution

3. Stateless Redesign — The Non-Negotiable First Step

4. The Strangler Fig Pattern

5. Kubernetes Readiness Criteria

6. Autoscaling That Reflects Real Load

7. The Modernisation Sequencing

Read the Full Article

GraphRAG vs. RAG: When Knowledge Graphs Earn Their Complexity

The Problem Flat Retrieval Can't Solve

Benchmark Reality

The Cost Problem (and How It Got Solved)

GraphRAG vs. Agentic Multi-Hop Retrieval

The Hybrid Architecture

The Key Insight

Read the Full Article

Context Engineering: The Discipline That Determines What Your LLM Actually Sees

The Context Window Is a Budget

The Recovery: `git reflog`