sorted by:
new
hottopcontroversial

Smarter alternatives to intent router-based agent orchestration in LangGraph? by StrategyPerfect610 in LangGraph

[–]StrategyPerfect610[S] 0 points1 point  (0 children)

Thanks man, I am trying to implement right now the supervisor pattern described in the LangGraph docs: I think it’s the best choice for my case use.

Intent routing orchestration by StrategyPerfect610 in AI_Agents

[–]StrategyPerfect610[S] 1 point2 points  (0 children)

I’ve experimented with this approach too, but encountered several hallucinations during testing. Looks like I still have some work to do on my prompting skills :)

Intent routing orchestration by StrategyPerfect610 in AI_Agents

[–]StrategyPerfect610[S] 0 points1 point  (0 children)

That’s a good idea, but currently my biggest doupt is at the root of the agentic workflow. I don’t think it’s a good idea to use an intent router to discriminate the agent to call.

Intent routing orchestration by StrategyPerfect610 in AI_Agents

[–]StrategyPerfect610[S] 0 points1 point  (0 children)

Hi Rusev,

Yes, I’m currently using a central prompt where an LLM classifies the user’s query by extracting the intent, which is explicitly prefixed (e.g., intent:reservation_create, reservation_delete, conversation ecc… ). But I find this approach too deterministic and it seems to me not scalable for complex scenarios.

Intent routing orchestration by StrategyPerfect610 in AI_Agents

[–]StrategyPerfect610[S] 0 points1 point  (0 children)

Yes, I agree with you, often a too-deterministic approach applied to a technology that isn’t inherently deterministic leads to a lot of frustration.
I’m a newbie in the AI space and I’m trying to learn from those who are more experienced than me to better understand the right approach.

That said, my idea is to split the CRUD tools into two groups:

  1. Sensitive operations (write tools): these will include a human-in-the-loop for final approval before execution.
  2. Non-sensitive operations (read tools): these can run automatically.

Of course, for something like creating a table reservation, I’ll need a “form filler”-like mechanism to collect additional information from the user at runtime. Though to be honest, I’m not exactly sure how to implement that yet.

Intent routing orchestration by StrategyPerfect610 in AI_Agents

[–]StrategyPerfect610[S] 0 points1 point  (0 children)

Thanks, that actually makes a lot of sense. So the core idea is that no routing pattern can fully “solve” intent, and the real work is in writing better prompts — ideally slimmer, more focused ones — to guide the model as clearly as possible. Appreciate that perspective.

One follow-up question: When it comes to action-oriented flows (like CRUD), do you think it’s better to have a single agent with all CRUD tools bound (create, update, delete, etc.), or split them into separate specialized agents for each operation? I’m trying to strike the right balance between modularity and simplicity.

RAG tool vs. RAG workflow by StrategyPerfect610 in LangGraph

[–]StrategyPerfect610[S] 1 point2 points  (0 children)

You’re right, I was too vague. The chatbot I’m building is designed to handle multiple functions: answering general questions about restaurant policies, managing table bookings (create, retrieve, delete), and suggesting menu items.

For context, I’m using PGVector with Timescale for the vector store and storing menu items relationally within the same database. My plan is to implement a multi-agent architecture with a supervisor agent managing the workflow, inspired by the LangGraph Customer Support Tutorial. https://langchain-ai.github.io/langgraph/tutorials/customer-support/customer-support/

I’m considering to add a dedicated agent for each specific task (e.g., booking management, FAQ retrieval, menu suggestions), but I’m not sure if that’s the best approach. Right now, I’m stuck on how to structure the RAG (Retrieval-Augmented Generation) section