Your AI setup should not depend on someone else’s pricing model.
That is the real lesson from the #Claudepocalypse. Claude is still excellent. That is not the point. The point is that if one subscription change can break your agent workflow overnight, then you do not really own
@whats_ai
-
AI Dependency: Why You Must Control Your Pricing Model
By
–
-
One Agent With Tools Beats Multiple Agents
By
–
A client asked us to build a multi-agent system for their marketing chatbot. They had the whole thing mapped out. One agent for planning. One for retrieval. One for generation. One for validation. A full squad.😅 I'll be honest, it looked good on their pitch deck. Probably helped get the grant, too. But something felt off when we started asking questions. "Does agent 2 ever run without knowing what agent 1 decided?" No. Always sequential. "Does the validation step ever happen without the full generation context?" No. Every step depends on the one before it. "Does the flow ever change mid-execution?" Almost never. So we told them: you don't need four agents. You need one agent that's good at using tools. That's a conversation most clients don't love having. They came in wanting the architecture. We came back saying the architecture is the problem. We built one agent with 8 tools instead. One decision maker holding the full context. Tools doing the specialized work: formatting SMS, validating tone, retrieving brand assets. No information dropped at handoffs. No duplicated logic. Way easier to debug. And it's cheaper, faster, and more reliable. I keep seeing this pattern. We reach for multi-agent because it feels like the serious choice. But splitting context across agents when the task is sequential just creates problems you didn't have before. 🤷♂️ One agent with good tools is still the most underrated architecture out there. Before your next build, try the recipe test: if you can write the exact steps in advance like a recipe, it's a workflow or one agent. Not a multi-agent system. [Translated from EN to English]
-
Progressive Disclosure Pattern Optimizes AI Token Efficiency
By
–
We've been building skills at Towards AI for months now and the progressive disclosure pattern is key. Loading full context upfront wastes tokens and confuses the model. The lightweight trigger + on-demand loading is how you actually scale this. Super cool to see Anthropic
-
Tracking User Frustration Signals for AI Model Improvement
By
–
I wonder what my is_negative ratio looks like after a long debugging session haha. Honestly though, tracking frustration signals is smart product design. If you know where users struggle most, you know where to improve the model.
-
Python Rewrite and Architecture Leak Analysis Revealed
By
–
The Python rewrite angle is clever haha. Honestly the leak was more interesting for what it revealed about the architecture than anything else. Skills, hooks, the whole execution model… not that surprising if you use it daily but nice to see confirmed.
-
RAG Pipeline Routing Agents Prompt Quality Optimization
By
–
It's so important to look at the actual prompts sent to the model (and the received chunks) to see if it makes sense at all. A lot of RAG pipelines retrieve "relevant" chunks that are actually useless for the specific question. The routing agent is where most of the value is IMO.
-
Intermediate Reasoning Steps in AI Models and Error Tolerance
By
–
This is a good reframe. The intermediate reasoning steps being "wrong" doesn't matter if the final output is correct. It's similar to how humans think through problems, lots of wrong turns before the right answer. The error compounding argument assumes each token is a final
-
LLMs democratizing government transparency through data processing
By
–
Government transparency limited by people's ability to process raw data is such an underrated problem. LLMs processing spending bills, lobbying disclosures, zoning decisions… this could genuinely change how democracy works at the local level. Super exciting.
-
File-Based Data Management for Long-Term Memory Systems
By
–
Everything managed in files is the way to go, just hard to manage long-standing memory still. Even with such a wikipedia version, but at least better to have more and well organized data vs. none!
-
2M Token Context: KV Cache Engineering Challenges and Limitations
By
–
2M token context sounds incredible but I wonder how it works in practice. KV cache at that scale is a real engineering problem, and results are quite often disappointing for higher context, especially for inter-connected questions that basically needs some sort of "retrieval"