Building reliable agentic AI systems
70 points by sarangk90 4 hours ago | 13 comments
smallnix 2 hours ago
What was the main driver for a dynamic workflow with loops vs a rigid forward running only workflow. The non-deterministic nature of these loops with LLM decision points doesn't mesh well with the transparency requirement imho
replyLittice 2 hours ago
The part about context discipline feels underrated.
Larger context windows don’t remove the need to decide what the model shouldn’t see.
replyaltmanaltman 2 hours ago
> The author used AI assistance during the writing of this article. AI tools were used for brainstorming ideas, creating outlines, and reviewing drafts to polish language and improve clarity.
replyThe first sentence makes it seem like they just used to improve sentence structure etc but the second line makes it seem like they used it for 90% of the work. Which one is true?
padolsey 2 hours ago
These vast multi-agentic systems with roles like 'Researcher', 'Writer' (with a review loop), 'Reflection agent', seem to ~feel~ mostly right but lack evals as to the merit of agent decomposition. So it forms a satisfying enough flowchart but I see no evidence these authors actually tried other approaches or agent roles. And let's be honest: an agent is just a system prompt and output contracts, and these rich architectures seem to be pontificating beyond their worth. It all feels a bit vibe-y.
replyai_slop_hater 2 hours ago
Why is comment from padolsey dead? Seriously, something fishy is going on on this website.
replyai_slop_hater 2 hours ago
> Sarang Kulkarni is a Principal Consultant at Thoughtworks
reply> teaches an O’Reilly course on building production-ready RAG applications
isn't this basically saying that you are a scammer? or am I paranoid?
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.
But that does make it more complex to build simple information retrieval use cases.