I build AI agent products full time — previously did vector search engines and RAG systems at a database company, now shipping my own stuff. Since OP asked for tech stacks, here's what I actually run day to day, no fluff.

My entire development workflow runs through Claude Code with Opus 4.6. Not Cursor, not Copilot. Terminal-native, agentic, 1M token context. I point it at a repo, describe what I want, and it plans, edits across 20+ files, runs tests, fixes failures, and opens a PR. I used to spend maybe 60% of my day writing code. Now I spend 60% of my day reviewing code that an agent wrote. The shift happened faster than I expected and it's not going back.

But here's where it gets interesting for this sub specifically — I don't trust cloud agents with everything. My daily workflow agent runs locally. The architecture is dead simple and I'll tell you exactly why: a while loop, an LLM call, a tool router, and a handful of native tools (bash, file I/O, browser, database). That's it. No LangChain, no CrewAI, no framework. I tried all of them and ripped every single one out within weeks. They add abstraction where you need transparency. When your agent breaks at step 14 of a 20-step task, you need to see exactly what happened — not dig through three layers of somebody else's middleware.

The thesis I've arrived at after building this for 2 years: an agent doesn't need much. Give it a shell, a database, and a browser — it can already do 90% of what these bloated tool ecosystems promise. MCP is useful as a standard protocol, sure, but conceptually the whole "plugin marketplace" thing is solving a problem Unix solved decades ago. The real AI-native OS is just Linux with an LLM making function calls. Once I internalized that, my architecture went from 15 dependencies to basically 3.

What actually changed my daily life: I have an agent that watches my GitHub notifications, Hacker News threads relevant to my space, and competitor repos — synthesizes everything into a morning briefing I read with coffee. Another one that takes my rough markdown notes after a user interview and restructures them into product specs with prioritized action items. A third that monitors my production logs, detects anomaly patterns, and drafts incident reports before I even know something's wrong. None of these required anything fancy to build. The hard part was never the agent framework — it was defining the task boundary tightly enough that the LLM doesn't hallucinate its way into uselessness.

The thing I'd push back on in this thread: people keep asking "what agents do you use" as if agents are products you install. The agents that actually stick in your workflow are the ones you build yourself, for your specific context, with your specific data. A generic "AI assistant" will always feel like a toy. An agent that knows your codebase, your docs, your naming conventions, your deployment pipeline — that's when it stops feeling like AI and starts feeling like a very fast junior employee who never sleeps.

Running locally matters more than people think, by the way. Not just for privacy — for latency. An agent that bounces through 3 API calls and takes 12 seconds per action is dead on arrival for any interactive workflow. Local inference on a decent GPU gives you sub-second tool calls. That's the difference between an agent you actually use and one you demo once then forget about.