I flagged The job search is exhausting right now. Rejections come fast. Roles disappear after you've put in the work. You send emails and wait. You show up every day and the silence on the other side doesn't match the effort on yours. I'm flagging this not to complain — but because pretending it's fine when it isn't is exactly what this log is supposed to avoid. because The job search is exhausting right now. Rejections come fast. Roles disappear after you've put in the work. You send emails and wait. You show up every day and the silence on the other side doesn't match the effort on yours. I'm flagging this not to complain — but because pretending it's fine when it isn't is exactly what this log is supposed to avoid.

I learned that high agency means acting on gaps, not just naming them from seeing my own entries in the What High Agency Looks Like feed todayOpened Proof today and saw both my entries featured under "What High Agency Looks Like." That's not something I expected. But reading RK's notes again, I realised the pattern he's picking up on isn't the technical content — it's that I named what I skipped and said what I'd do next. I actually did those things. Docker to Render, JWT gateway, refresh tokens, ReAct pattern. Each day I said tomorrow I'll do X — and I did. That's what high agency means. Not knowing everything. Acting on the gap you just named.

how I look at code I've already written because writing forces you to name decisions you made by reflex — and named decisions are ones you can improveTen days ago I thought knowing how to build something was enough. I had three projects, a working MERN stack, a Gen-AI platform with LSTM — and I couldn't explain a single decision I made while building them. I just built. Docker was there because tutorials used it. JWT was there because auth needed it. The LLM was there because the project needed AI. No reasoning. Just pattern copying. These 10 days changed that. I now know why Docker and Render coexist in my repo. I know why JWT verification belongs at the gateway not inside each service. I know the difference between an LLM that generates and an agent that reasons. I know why latency matters more than accuracy in production. None of this came from studying harder. It came from writing it down and asking why — every single day

Read about evals today but didn't go deep — skimmed more than studied. What I did pick up: evals are how you know if your agent is actually working or just appearing to work. Without evals you're guessing. You run the agent on test cases, check the outputs, and score them — either against expected answers or using another LLM as a judge. I decided to understand this over skipping it entirely because yesterday I realised I don't know how Omnisavant would know if their onboarding agent is doing the right thing. Evals are the answer. I just don't fully understand them ye over skipping evals entirely and assuming the agent works because you can't trust a system in production if you have no way to measure if it's right

Read about low latency LLMs today — specifically why Omnisavant's job description mentions R&D on them. The core insight: smaller models are faster because they have fewer parameters to compute per token. A 7B model responds in milliseconds where a 70B model takes seconds. For a customer onboarding agent that needs to scrape docs, generate demos, and respond in real time, latency isn't a nice-to-have — it's the product. A slow agent feels broken even if the answer is correct. I decided to understand this over skipping it because I kept thinking LLM quality = bigger model. That's wrong for production. The right model is the smallest one that's good enough for the task over always using the biggest most capable model because production agents need speed, not just accuracy — a slow agent feels broken

Studied the ReAct pattern in LangChain today. ReAct = Reason + Act. The LLM doesn't just generate an answer — it first reasons about what it needs, decides which tool to call, calls it, reads the result, then reasons again. It loops until it has enough to answer. I decided to understand this over just using LangChain as a black box because my GenAI platform calls an LLM once and stops — I needed to know what I was missing. What I was missing is the loop. My platform generates. An agent equipped with ReAct thinks, acts, checks, and repeats. That's the gap between what I built and what Omnisavant actually needs over using LangChain without understanding how it works because I needed to know what my GenAI platform is missing before I can improve it

the difference between an LLM generator and an LLM agent from my GenAI platform code and LangChain docsWent back into my GenAI assessment platform today. I expected to find a simple LLM call — send prompt, get answer. It's more layered than that. There's prompt construction logic, LSTM predictions feeding into the prompt, and response parsing after. But it's still not an agent — it calls the LLM once and stops. No tools, no looping, no decision about what to do next. I also read about LangChain agents today. The difference is clear now: my platform uses the LLM as a generator. An agent uses the LLM as a reasoner — it decides what action to take, calls a tool, checks the result, and loops until the task is done. I built something smart but not something that acts

Wrote the refresh token logic today — when the access token expires, the client now automatically sends the refresh token, gets a new access token, and retries the request. The user never sees a 401. I also spent time understanding what an LLM agent actually is. A normal LLM just responds to input. An agent has tools it can call, loops until the task is done, and acts instead of just answering. The gap between "I can use an AI API" and "I can build an agent" is the difference between giving someone a brain and giving them hands. That clicked today from

Traced how my API Gateway handles JWT today. The gateway receives the request, pulls the token from the Authorization header, verifies the signature using the secret key, and only then forwards the request to the right microservice. If the token is invalid it never reaches the service at all. I wrote this code months ago but I was thinking of it as "authentication middleware" — today I understood it's actually a bouncer at the door, not a check inside the room. The decision to verify at the gateway level instead of each service was the right one — because if each service verified tokens independently, a bug in one service's auth logic could expose all the others. One gate is easier to secure than six. I just didn't know why until now over each service checking its own token because one gate is easier to secure than six

from Opened my docker-compose.yml properly today instead of just running it. Each service is its own container — they share a network so they can talk to each other by service name, not localhost. The depends_on field is what I was copying blindly — it just controls startup order, not whether a service is actually ready. That's why I had race condition bugs early on. I fixed them by adding retries but never knew why they were needed. Now I d

over because I had both docker-compose.yml and render.yaml in my e-commerce repo. I thought they were alternatives — pick one. Today I realised they solve different problems. Docker because I needed all 6 services to run identically on my machine without "works on my laptop" issues. Render because I didn't want to manage servers in production. The decision was always there — I just never named it while buildin

I've been building projects — MERN microservices, ML pipelines, a GenAI assessment platform — but I realised today I've been listing what I built more than understanding why I made each call. Like, I used Docker Compose for the e-commerce platform. But if you asked me right now why Docker over just deploying directly on Render — I'd stumble. That's the gap I'm starting to close.