u/ApartmentHappy9030

I've been building multi-agent systems on top of Spring AI and kept hitting the same wall: the framework gives you primitives, but you still end up writing orchestration, retries, state management — and more importantly, governance.
The real issue for me was trust.
One of my agents retried a paid API 23 times overnight because of a transient error. The retry logic worked technically, but it had no notion of cost, approval boundaries or operational risk.
So I built AgentFlow4J: a graph-based runtime for stateful multi-agent workflows in Java, focused on governed execution.
Agents are not trusted by default.
Current governance primitives include:
ToolPolicy → allow/deny tool access per agent

StatePolicy → restrict writes to sensitive state keys

BudgetPolicy → cap spend per run/node/call (tokens, dollars, call counts)

ApprovalGate → pause for human approval and resume from checkpoint

Each policy is opt-in and defaults to a no-op.
The framework builds on Spring AI, ships with a Spring Boot starter, and can run fully offline via a deterministic sample (no API key required).
The project is still early-stage (v0.6), and I’d genuinely appreciate feedback on:
API design

governance model

developer ergonomics

failure handling

No MCP integration yet.
No benchmark theatre either — the bottleneck is usually the LLM, not the orchestration layer.
Huge thanks to the contributors helping shape the project.
Happy to discuss design trade-offs and learn from others building agentic systems in production.

GitHub repository in the comments

I’ve been building multi-agent systems on top of Spring AI and kept hitting the same wall: the framework gives you primitives, but you still write the orchestration, retries, state management — and more importantly, governance.
The real issue for me was trust.
One of my agents retried a paid API 23 times overnight because of a transient error. The retry logic worked technically, but it had no notion of cost, risk or approval boundaries.
So I built AgentFlow4J: a graph-based runtime for stateful multi-agent workflows in Java, focused on governed execution.
Agents are not trusted by default.
Current governance primitives:
ToolPolicy → allow/deny tool access per agent
StatePolicy → restrict writes to sensitive state keys
BudgetPolicy → cap spend per run/node/call (tokens, dollars, call counts)
ApprovalGate → pause for human approval and resume from checkpoint
Each policy is opt-in and defaults to a no-op.
The framework builds on Spring AI, ships with a Spring Boot starter, and can run fully offline via a deterministic sample (no API key required).
This is still early-stage (v0.6, solo project, not affiliated with Spring), and I’d genuinely appreciate feedback on:
API design
governance model
developer ergonomics
failure handling
No MCP integration yet.
No benchmark theatre either — the bottleneck is usually the LLM, not the orchestration layer.
Happy to answer questions or discuss design trade-offs.

GitHub repository in the comments

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 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?