My current circle is:

Can I get GM?

Loop Engineering + 4 D's: upgraded mental model. Outer Loop = Orchestrator Inner Loop = Maker (executes the beat) 10-80-10: First 10%: Delegation + Description (you direct) 80%: Maker executes Last 10%: Checker, then Human review Key insight most people miss: The Checker must ALWAYS be a separate model. The Maker built the output. It will approve its own work every time. Separate model. No attachment. Objective gate. That's an engineered system. Not a vibe. 🔄 #AgenticAI #AIEngineering #BuildInPublic

AI coding agents in 3 words: Fast. Sloppy. Useful. They ship code quick. They still hardcode env vars and miss auth edge cases unless you babysit them. Human review isn’t optional yet.

Some bugs don't crash your app. They just trap your users in silence. Found an infinite redirect loop inside an AI employee dashboard I'm building. Two auth guards disagreeing: One trusted stale persisted session Other hit backend → 401 → back to login → repeat Fixed it but going deeper with a more robust approach. Full breakdown coming soon. Auth bugs don't fail loudly. They loop silently. #buildinpublic

Fixed 3 bugs today before real users could find them: - Silent auth bypass OTP "verified" on frontend, DB flag never set true - Broken onboarding new tenants landing on blank state - Layout flash on login moved routing decision server-side, zero flash None caught in code review. All would've been caught by users. Building in public. 🚀

One thing I’m noticing while building with AI coding agents: They are great at writing code fast, but they still miss small production details unless you explicitly guide them. Things like proper environment handling, edge cases, and clean structure still need human review.

Been testing features with general AI coding agents lately. They write solid pytest cases, but keep hardcoding environment variables instead of using os.getenv(). Caught it right before pushing to GitHub. Updated the agent’s global memory after pointing it out. Still figuring out how much of this is my prompting vs the agent’s default behavior.

RAG is everywhere. CAG? Almost nobody knows it. Here's the problem I've been thinking about: RAG works great, but when the same type of queries hit repeatedly, you're making unnecessary hits to your retrieval system each time paying the latency tax. Enter CAG (Cache Augmented Generation). Check cache first. If it's there, return it. If not, retrieve and cache for next time. Simple. Clean. Works perfectly for single-tenant systems where data is static. But here's where it gets tricky: Multi-tenant systems. Each tenant has isolated data, isolated queries, isolated cache. That's manageable. But the real challenge? Data changes constantly. Every order, every ingestion, every update invalidates your cache. So you're stuck: use CAG and risk stale data, or validate on every query and lose the speed benefit. The solution I'm exploring: Tenant-scoped cache with event-driven invalidation and versioning. When data changes, invalidate only affected cache. But don't just discard it version it. Each cache state gets a version number tied to the data change event. This gives you two things: Freshness: Only valid cache serves queries Audit Trail: You can trace which data version was served at which time, to which tenant Multi-tenant caching is hard. But with versioning, it becomes auditable. And auditable systems scale. What's your approach to cache invalidation in production systems? #AI #LLM #SystemsDesign #Caching

Most AI agents still stop at the dashboard. The real challenge is making them take action in messy real systems without breaking.

Bro people keep saying FDE just means sit with the client, understand requirements, then build the whole product end to end.Stop.FDE is different.There is already a complex platform that is live and deployed. The FDE goes and sits with the customer team (who are usually ops or domain people, not pure software engineers) and makes that platform actually work inside their systems, their data, their real workflows. They don't start from zero. They take the powerful thing that already exists, wire it into the messy production reality, write the production code, ship it, and own whether it delivers the outcome.That's the whole job. Not consulting. Not building a custom app from scratch. Bridging the platform to the customer so the value shows up.If you're explaining FDE any other way you're missing the point.

shipped something today that actually works. no compromises

Hey @X algorithm Show this to people who are actually building: • AI agents • Production systems • LangGraph / FastAPI • Real AI employees Drop what you’re working on 👇 Let’s connect.

GM builders ☀️ Another day of shipping and learning.

Everyone's saying "Forward Deployed Engineer" this year like it's new. It's not. It's an old role (implementation engineer) that got a glow-up. Real definition, after digging into it today: FDE exists when you have (1) a strong platform + (2) a client who isn't technical enough to implement it themselves. The FDE doesn't just "set things up." They sit with the client, understand the actual mess, and customize the platform on-site for that specific problem. Palantir basically invented this pattern with Foundry. Now it's back because of AI enterprises want agentic systems but have zero in-house AI depth. Someone has to bridge that gap. Started going hands-on with this myself today. Feels like where a lot of real engineering leverage is moving.

Been a bit quiet the last few days. Back now. Been deep in system design and thinking more about reliability in agent architectures.

Today I spent time exploring single points of failure in system architecture. In agent systems especially, one small dependency can bring everything down. The goal isn’t zero failure it’s making sure one failure doesn’t cascade.

One thing I’m noticing more and more: Building the agent is the easy part. Making it reliable when it has to take real actions in messy systems is the hard part.

Looking to connect with more people who are deep into: • AI agents • LangChain / LangGraph • Real production systems • Ops automation Drop what you’re working on 👇 Happy to connect.