logoalt Hacker News

bob1029today at 6:27 AM2 repliesview on HN

The most important part is the database that the agent can see and how clean the data is. I pitched a custom enterprise agent to a client thinking it would be maybe 50/50 time on data vs agent tuning, but it's more like 99/1.

The alignment process goes very quickly once you have all the fish in exactly one barrel. I think pulling data dynamically from the source systems is where this turns into a game of whack-a-mole.

The problem with dynamic fetch is that you don't get any kind of persistent or compounding gains. There are queries that you simply cannot run because you'd chew through your GitHub, et. al., API quotas. It takes over 48h to fully hydrate the database for GitHub items on my current project. But, once that process is complete I can query across things like issue comments and do crosscutting joins with the state of other vendor systems in milliseconds.

I am finding the MSSQL dialect to be quite agreeable to the OAI models. With absolutely no prompting they will bootstrap off information schema and extended description properties every single time. If you design the schema for your audience, the amount of "Jesus prompting" you will require is much better controlled.


Replies

dbuxtontoday at 7:10 AM

The problem with this is that you have a consistency problem if you want to take action. The only way of making your agents read-write rather than read-only in practice is to use the underlying systems rather than try and pool information in a data lake.

But that does make it more complex to build simple information retrieval use cases.

show 2 replies
Tanxsinxlnxtoday at 7:26 AM

[flagged]