Abbas Ali

Abbas AliJul 24, 2026

The whole industry runs on agent loops. But a loop is a black box — once it starts, you're blind. 🙈 The fix is a graph. And I found the 2026 research that proves it. 📄🔥 Here's the problem with a plain agent loop: You hit "go." 🏃 The model starts thinking, calling tools, looping on an ever-growing context window... And you? You just... wait. 😐 You can't see inside it. You can't pause it. And if it breaks at step 7 — you restart from step 1. 💀 It's a black box with a spinner. And this isn't just a vibe — a 2026 arXiv paper ("From Agent Loops to Structured Graphs") put hard theory under it. It nails 3 structural flaws every loop has: ⚠️ 1️⃣ Invisible dependencies. Step 5 secretly relies on step 2 — but nothing says so. It's all tangled inside one giant context window. 2️⃣ Runaway recovery. When it fails, it just retries. And retries. No limit. No brakes. 🔁 3️⃣ A history you can't trust. The execution record keeps mutating, so debugging becomes archaeology. 🏺 Then comes the line that reframed it for me: An agent loop is just a scheduler that runs ONE step at a time — and won't tell you WHY it picked that step. 🎰 No parallelism. No inspectable logic. A black box choosing your next move. The fix? Turn the loop into a GRAPH. 🕸️ Instead of one blind loop, you model the agent as a graph: 📍 Nodes = each step (a decision, a tool call, a check) ➡️ Edges = the path between them 💾 State = saved at every node And that unlocks everything the loop couldn't give you: ⏸️ Pause it mid-run. Freeze the agent at any node. 👁️ See what it's thinking. Inspect the exact state, right now. ✏️ Fix it live. Wrong turn at step 4? Correct it and continue. ▶️ Resume from there — not from zero. You're not just running an agent anymore. You're debugging a living process while it's alive. 🧠⚡ The paper's fix matches this exactly: lift the plan out of the messy context and into an explicit graph — where the plan is fixed, the layers are separated, and recovery has a hard limit. And the stat that should wake you up: 👀 ~60% of open-source agent projects still run the naive loop. Meaning: most AI agents shipping right now use the pattern researchers are already moving away from. So the devs who learn graph-based agents today... are building what everyone else copies in 12 months. ⏳🚀 The mental model for this week: 🖐️ Tools = the hands (Day 8) 🔁 Loop = the persistence 🕸️ Graph = the control panel — pause, peek, resume The industry didn't just adopt agents. It's learning to supervise them. 🎛️ Still building loops — or have you moved to graphs? Be honest 👇 #Day9 #AIAgents #AgenticAI #LangGraph #LLM #AIResearch #WebDevelopment #Backend #SoftwareEngineer

Abbas AliAug 9, 2026

OpenAI Interview Question: How to reach 90% Accuracy of RAG? "Your RAG works 50% of the time. Get it to 90%." That's the question. Most people freeze — because they think RAG is one thing. It's actually FOUR upgrades. 🎯 Here's the trap: everyone builds the same basic RAG. Chop docs into chunks → embed → search → dump into the LLM → pray. 🙏 It demos beautifully. Then real users show up and it's wrong half the time. 📉 Getting to 90% isn't a bigger model. It's four surgical fixes to the pipeline 👇 1️⃣ Semantic Chunking 📄 Most people split documents every 500 characters. That slices sentences in half and shreds meaning. ✅ Instead: split where the meaning changes — at section breaks, topic shifts, headers. Each chunk becomes one complete thought, not a random fragment. Same data. Smarter boundaries. Instant accuracy jump. 2️⃣ Hybrid Search (Vector + Keyword) 🔍 Vector search understands meaning — but it fumbles exact terms. Search for error code "ERR_5012" and pure vector search shrugs. 🤷 ✅ Run BOTH: → Vector search catches meaning ("login failure" ≈ "can't sign in") → Keyword search catches exact matches ("ERR_5012", a product name, an ID) Together they cover each other's blind spots. 3️⃣ Add a Reranker 🎯 Here's the mistake: grabbing the top 5 chunks and shipping them straight to the LLM. Those 5 are just "close-ish." ✅ Instead: retrieve 20 candidates → run a reranker that actually scores each one against the query → send only the top 3 to the LLM. Retrieve wide. Filter hard. The LLM only sees gold. 🥇 4️⃣ Query Rewriting ✍️ Real users type garbage: "why is it broken?" Your retriever has no idea what "it" is. ✅ Before searching, a step rewrites that into: "why is the checkout payment API returning 500 errors?" Now retrieval has something real to grab. Fix the question before you go looking for the answer. The big lesson: 🧠 RAG accuracy isn't ONE knob. It's a pipeline, and every stage leaks: Bad chunks → bad retrieval → bad ranking → bad answer. Amateurs tune the LLM. Engineers tune the retrieval. 🔧 Because here's the truth OpenAI is fishing for: In RAG, the model was never the problem. Getting it the RIGHT context was. 🎯 Which of these four have you actually shipped? Or are you still on "chunk-and-pray"? 👇 #Day13 #RAG #AI #LLM #MachineLearning #VectorSearch #InterviewPrep #Backend #SoftwareEngineer

Abbas AliAug 5, 2026

Zepto processes 1 BILLION ad events every day. But here's the scary part: that same pipeline decides how much to charge advertisers. Count one event twice → you overcharge a real customer. 😳 I read Zepto's engineering blog and it reframed how I think about analytics. Most analytics you've built? If a number is off by 0.1%, nobody dies. A dashboard looks slightly wrong. Shrug. 🤷 Now change ONE thing: The analytics engine also runs billing. 💸 Suddenly: ❌ Count an event twice → you overcharged an advertiser (fraud territory) ❌ Miss an event → you undercounted → you lost real revenue ❌ Blow a budget cap → an advertiser spends money they didn't authorize At 1 billion events a day, "mostly accurate" isn't an option. Every event must count exactly once. 🎯 Here's how they pulled it off 👇 Problem 1: Duplicates. 👯 The same click event can arrive twice (retries, network hiccups). Naive counting = double billing. ✅ They dedupe every event before it ever touches a metric. Problem 2: Late events. ⏰ An event fires now but shows up 3 minutes later. If your window already closed, that money vanishes. ✅ Their windowing is built to absorb stragglers, not drop them. Problem 3: The obvious tool didn't scale. 🛠️ Their first instinct — a Flink pipeline with 5-minute windows — is what most of us would reach for. It buckled. ✅ They rebuilt on ClickHouse, and the design choices are chef's kiss: 🔹 Partition by time. Queries rarely look past 2 days, so ClickHouse reads 2 partitions — not a giant monthly slab. 📅 🔹 Order key = your query pattern. They lead with advertiserId + campaignId because that's how 90% of queries filter. The data is physically laid out to match how it's read. 🧭 🔹 Order columns by cardinality → free compression. Similar values cluster together, so they compress harder and scan faster. Same data, a fraction of the size. 🗜️ 🔹 5-minute buckets. Small enough for near-real-time budget enforcement, and you just sum them to get hours, days, months. One granularity, infinite rollups. 🧮 The lesson that stuck with me: The hard part of "big data" was never the size. It's what happens when every row controls a dollar. 💵 Volume is a scaling problem — you throw infrastructure at it. Correctness is a design problem — you can't buy your way out of it. 🧠 Anyone can count a billion events. Counting a billion events exactly once, in real time, while money moves? That's engineering. 🔥 What's the highest-stakes number YOUR code is responsible for? 👇 #Day12 #SystemDesign #DataEngineering #ClickHouse #DistributedSystems #Analytics #Backend #SoftwareEngineer