
u/ApartmentHappy9030

I’ve been working on multi-agent workflows for real use cases (not just chat), and built a small demo around customer operations.
Instead of a single LLM, this uses multiple agents with defined roles (analysis, decision, execution), coordinated through an explicit workflow.
It’s built on Spring AI, but the focus is on orchestration — managing execution flow, retries, and state between agents.
What it does:
routes requests across specialized agents
enforces a structured execution flow
keeps state across steps instead of relying on a single prompt
The main challenge I’ve seen isn’t the models — it’s orchestration:
keeping execution predictable when agents interact
handling retries and partial failures without breaking the flow
managing shared state without turning everything into implicit prompt context
Curious how others are handling this in practice:
are you using explicit orchestration (graphs / workflows), or keeping it implicit in prompts?
how do you deal with failure handling across multi-step agent pipelines?
do you keep state externally, or rely on the model context?
Interested in real-world approaches , especially beyond toy demos.
I’ve been working on multi-agent workflows for real use cases (not just chat), and built a small demo around customer operations.
Instead of a single LLM, this uses multiple agents with defined roles (analysis, decision, execution), coordinated through an explicit workflow.
It’s built on Spring AI, but the focus is on orchestration — managing execution flow, retries, and state between agents.
Live demo:
https://huggingface.co/spaces/datallmhub/multi-agent-customer-ops
What it does:
- routes requests across specialized agents
- enforces a structured execution flow
- keeps state across steps instead of relying on a single prompt
The main challenge I’ve seen isn’t the models, it’s orchestration:
- keeping execution predictable when agents interact
- handling retries and partial failures without breaking the flow
- managing shared state without turning everything into implicit prompt context
Curious how others are handling this in practice:
- are you using explicit orchestration (graphs / workflows), or keeping it implicit in prompts?
- how do you deal with failure handling across multi-step agent pipelines?
- do you keep state externally, or rely on the model context?
Interested in real-world approaches, especially beyond toy demos.
I’ve been working on RAG setups recently, and something keeps coming up.
Simple pipelines work fine:
query → retrieve → generate → done
But as soon as things get more complex, it starts breaking down:
- multiple retrieval steps
- retries when retrieval fails
- combining different sources
- keeping track of intermediate state
- validating the final answer
Most examples stay linear, but real workflows aren’t.
I ended up experimenting with a graph-based approach to orchestrate the flow:
- separate agents for retrieval, reasoning, validation
- shared state across steps
- retries and recovery when something fails
It’s not a RAG tool per se, more like a way to structure non-linear, stateful workflows around RAG.
Example flow:
User query
→ retrieve (vector DB)
→ refine query
→ retrieve again
→ synthesize answer
→ validate output
Curious how others are handling this.
Are you sticking with linear pipelines, or moving toward something more structured?
I've been experimenting with multi-agent workflows using Spring AI, and I ran into a limitation quickly: most examples are stateless and linear.
In real-world systems, you need things like:
- long-running workflows
- state persistence across steps
- retry and failure handling
- coordination between multiple agents (routing, sub-agents)
So I built a small framework to explore this, using a graph-based execution model for agents (kind of like a workflow engine, but for LLM-driven systems).
Repo: https://github.com/datallmhub/spring-agent-flow
Right now I'm trying to figure out:
- how to manage state cleanly in Spring-based systems
- how far to push orchestration vs keeping things simple
Curious if others are tackling similar problems, especially on the Java/Spring side.