If you have a gigantic data warehouse with 1000+ tables, there's no way you could fit all of that info into a system prompt without completely jacking something up in the blackbox. So, why bother trying?

Consider that the user's specific request serves as an additional constraint that can be used to your advantage to dramatically reduce the search space. Building a single prompt / schema description that will magically work for all potential user requests is a cursed mission by comparison.

The user's conversation happens at level 0. Any actual tool use is only permitted at stack depths > 0. When the model calls the Return tool at stack depth 0 we end that logical turn of conversation and the argument to the tool is presented to the user. The user can then continue the conversation if desired with all prior top level conversation available in-scope.

It's effectively the exact same experience as ChatGPT, but each time the user types a message an entire depth-first search process kicks off that can take several minutes to complete each time.

This is the key lesson that everyone needs to step back and pay attention to here. The data is still king. If you have a clean relational database that contains all of your enterprise's information, pointing a modern LLM (i.e., late 2025+) at it without any further guidance often yields very good outcomes. Outcomes that genuinely shocked me no fewer than 6 months ago.

I am finding that 100 tables exposed as 1 tool performs significantly better than 100 tables exposed as 10~100 tools. Any time you find yourself tempted to patch things with more system prompt tokens or additional tools, you should push yourself to solve things in the other ways. More targeted & detailed error feedback from existing tools often goes a lot further than additional lines of aggressively worded prose.

I think one big fat SQL database is probably getting close to the best possible way to organize everything for an agent to consume. I am not going to die on any specific vendor's hill, but SQL in general is such a competent solution to the problem of incrementally revealing the domain knowledge to the agent. You can even incrementalize the schema description process itself by way of the system tables. Intentionally not providing a schema description tool/document/prompt seems to perform better with the latest models than the other way around.

https://en.wikipedia.org/wiki/Capstone_Green_Energy

It's hard to beat domain specific code. I can avoid massive prompts and token bloat if my execution environment, tools and error feedback provide effectively the same constraints.

If I had to pick only one tool for a generic agent to use, it would definitely be ExecuteSqlQuery (or a superset like ExecuteShell). If you gave me an agent framework and this is all it could do, I'd probably be ok for quite a while. SQL can absorb the domain specific concerns quite well. Consider that tool definitions also consume tokens.

You might be shocked to discover there are subdivisions so affluent they can afford physical armed security and access control structures with far more invasive identification and logging procedures.

I understand this isn't inline with traditional git scm, but it's a very powerful workflow if you are OK with some hybridization.

You might think you are protected with UPSes and what not, but nothing will stop the electromagnetic effects if it hits within a few feet. Every piece of copper is going to get lit up. No solution is 100% guaranteed here, but EC2 and snapshots is a hell of a lot more likely to survive a single event like that.

What is more interesting to me is the fact that everyone seems to think of Postgres as the obvious alternative to SQLite. It is certainly an alternative. For me, the most opposite thing of SQLite is something like Oracle or MSSQL.

The complexity being relatively constant is the part I care about most here. Running a paid, COTS database engine on a blessed OS tends to be a little bit easier than an OSS solution that can run on toasters and drones. Especially, if you are using replication, high availability, etc.

The business liability coverage seems to track proportionally with how much money you spend on the solution. SQLite offers zero guarantees accordingly. You don't have a support contract or an account manager you can get upset with. Depending on the nature of the business this could be preferable or adverse. It really depends.

For serious regulated business with oppressive audit cycles, SQLite trends toward liability more than asset if it's being used as a system of record. That it merely works and performs well is often not sufficient for acceptance. I'm not saying that Postgres isn't capable of passing an intense audit, but I am saying that it might be easier to pass it if you used MSSQL. The cost of having your staff tied up with compliance should be considered when making technology choices in relevant businesses.

I'd put the 5700xt at #2 for being the longest lived GPU I've owned by a very wide margin. It's still in use today.

I enjoy working hard on problems that most would label as miserable. Not just computer problems. The money is genuinely not that important to me. A Porsche would only get me into trouble faster. I don't desire that kind of status game energy in my life anymore. I used to but not anymore. I've been inside these fancy houses. It's not appealing to me at all. Infrasonic room modes are not my jam.

Solving problems in 2 days that an entire development team couldn't solve in 2 months is far more of an adrenaline rush for me. No amount of money can buy this. You have to bust your ass and live it every day to be able to do it. Disrupting an entire entrenched power hierarchy with one cheeky pull request is peak happiness for me. I enjoy getting management riled up regarding the apparent productivity disparity between their full-time W2 employment pool and the one cowboy 1099 who works barely 3 hours per week.

I put my Amex details into OAI, I get tokens, it just works. I really don't understand what the hell is going on with Claude. The $200/m thing is so confusing to me. I'd rather just go buy however many tokens I plan to use. $200 worth of OAI tokens would go a really long way for me (much longer than a month), but perhaps I am holding it wrong.

If I don't get paid for one day of work, I will probably get over it in a few hours. If I don't get paid for six months of work, we will have a serious problem. The tighter and more incremental we can make the delivery process, the less likely anyone gets screwed.

If a party is pushing hard for long-term contracts or large up-front sums of payment, I would walk away from that transaction unless there was a literal golden goose sitting in their lap.