Java vs. Python AI Agent frameworks experiment
Agentic AI design is primarily an orchestration challenge, and the Java frameworks Embabel and LangChain (specifically LangChain4j and…
Java vs. Python AI Agent frameworks experiment
Agentic AI design is primarily an orchestration challenge, and the Java frameworks Embabel and LangChain (specifically LangChain4j and LangGraph for the JVM) offer different approaches to solving it. Evaluation (Evals) is a critical part of this orchestration, providing the feedback loops for agent performance.
A modern Java GOAP (Goal-Oriented Action Planning) agent built on Spring WebFlux or Virtual Threads is a highly scalable solution for high-throughput LLM orchestration. Coming from Java background, I had to experiment. Below is a comprehensive comparison of two parallel approaches for building production-ready LLM agents:
- Embabel (Java GOAP): Deterministic planning with an enterprise-grade focus
- LangGraph (Python): State-based, flexible orchestration
Spring AI provides the essential building blocks and consistent APIs to connect Java applications to various AI models and services (LLMs, embeddings, vector stores, etc.) using the familiar Spring paradigm. It is the foundation that higher-level frameworks like Embabel are built upon.
Finally we will explore the hybrid approach.
Example : Market Analyst Agent
- Call Technical Tool Server → Calls the external financial data API to retrieve structured quantitative indicators (SMA, RSI, MACD) for a stock ticker
- Call RAG Service → Retrieve unstructured qualitative market intelligence for the same ticker
- LLM Synthesis → Sends the quantitative JSON output and the qualitative text context to the LLM to synthesize a final thesis and recommendation (BUY, SELL, HOLD)
=== Workflow (Deterministic 3-Step) ===
[Embabel/LanGraph - Step 1/3] Call Technical Tool Server (public information)
[Embabel/LanGraph - Step 1/3] ✓ Retrieved: BULLISH
[Embabel/LanGraph - Step 2/3] Call RAG Service (can be propaitery information)
[Embabel/LanGraph - Step 3/3] LLM Synthesis
[Embabel/LanGraph - Step 3/3] ✓ Recommendation: BUY (Confidence: 75.0%)
=== Workflow Complete ===
How is GOAP implemented with just Spring AI?
In the java-tool-server, since the public Embabel Maven repository was inaccessible, GOAP (Goal Oriented Action Planning) is Simulated.
- True GOAP: You define actions + preconditions, and a generic algorithm figures out the sequence at runtime.
- This Implementation: The developer acted as the “Planner” and hardcoded the optimal sequence in
// The "Plan" is hardcoded in Java:
TechnicalIndicators technicalData = executePlanStep1_CallTool(ticker);
String qualitativeContext = executePlanStep2_CallRAG(...); // Depends on Step 1
ThesisResult thesis = executePlanStep3_LLMSynthesis(...); // Depends on 1 & 2
- It demonstrates the architectural pattern (Dependencies -> Synthesis) without needing the complex A* search algorithm library.
Comparison of the two stacks:

1. The Java Way: Deterministic & Scalable
A modern Java Agent built on Spring Boot and Virtual Threads offers a highly scalable solution for high-throughput orchestration.
- Philosophy: “Safety First.” We use Java Records to enforce strict data contracts between the LLM and our code.
- Architecture (GOAP): We implemented a Goal-Oriented Action Planning (GOAP) pattern. Unlike a loose graph, this approach defines “Goals” and “Dependencies.”
- Implementation Note: In this experiment, the GOAP planner is “simulated”. Instead of a runtime search algorithm, we hardcoded the optimal plan (Technical Data → RAG → Synthesis) to demonstrate the Separation of Concerns without the overhead of a complex library.
- Performance: By leveraging Java 21 Virtual Threads, we can achieve massive concurrency (running the RAG and Technical steps in parallel) without the complexity of Python’s
asyncioloop or the GIL limitations.
2. The Python Way: Flexible & Cyclic
LangGraph represents the state-of-the-art in Python orchestration.
- Philosophy: “Velocity First.” It allows for rapid iteration and changing the agent’s behavior at runtime.
- Architecture (State Graph): The developer defines nodes and edges. This is superior for cyclic workflows (e.g., “Review the Output. If bad, generate again.”) which are clumsy to implement in a rigid Java dependency tree.
The Verdict: The Hybrid Model
Using Python for the ML/LLM layer and Java/C# for the core business layer is the pragmatic standard across large enterprises.
The Separation of Concerns:
Python (LangGraph/LangChain) is chosen for the specialized ML/LLM layer, excelling at:
- Rapid Prototyping and Decision-Making.
- Natural Language Processing and integration with diverse LLM/ML libraries.
- Cyclic and Flexible. LangGraph is designed to easily handle cycles (the core of multi-agent and self-correction loops), making it highly flexible for complex, non-linear R&D workflows.
Java/JVM (Spring Boot) is chosen for the Core Business Layer, optimized for:
- Performance and Concurrency (e.g., Spring WebFlux/Virtual Threads).
- Type Safety and Compliance for mission-critical, high-volume workloads.
- Dynamic Re-planning. If a step fails or produces an unexpected result, the GOAP planner can dynamically formulate a new, optimized path to the goal, enhancing reliability and adaptability in complex systems.
Enterprises should avoid rewriting validated, long-standing business logic (e.g., pricing engines, risk calculators) just to fit a Python-based LLM agent. Instead, expose this logic through a clean API (like the Model Context Protocol).
graph TD
User --> P[Python (LangGraph Orchestrator)]
P -->|REST / MCP| J[Java Tool Server (Spring Boot)]
J -->|Calculates| DB[(Legacy Database)]
J -->|Returns Typed Data| P
P -->|Context + Data| LLM
LLM -->|Thesis| P
P --> User
- Preserve existing investment — Fortune 500 companies have 10–15+ years of Java/C# infrastructure
- Separation of concerns — AI reasoning vs. business logic
- Best tool for each job — Python’s ML ecosystem + Java’s production stability
- Independent scaling — AI layer scales separately from backend
Most Fortune 500 companies already operate massive infrastructure in Java, C#, or Go. The hybrid model lets them preserve this stability while leveraging Python exclusively for specialized LLM/ML intelligence.
To make the above Market Analyst Agent a hybrid, Python LangGraph would:
Python (Orchestration): LangGraph controls flow, LLM reasoning
↓ calls
Java (Tools): Technical indicators, business calculations
↓ returns
Python: Synthesizes final thesis using LLM
Java would be the only source of business logic/calculations.
Conclusion
The successful Enterprise AI stack for 2026 isn’t “Java OR Python.” It is “Java AND Python.” Use Python to manage the chaotic reasoning of the LLM, and use Java to ensure the actions it takes are safe, fast, and correct.
메타데이터
- post_id
- bbade2c7960c
- slug
- java-goap-vs-python-langgraph-bbade2c7960c
- url
- https://medium.com/@random.droid/java-goap-vs-python-langgraph-bbade2c7960c
- canonical_url
- https://medium.com/@random.droid/java-goap-vs-python-langgraph-bbade2c7960c
- author_url
- https://medium.com/@random.droid
- status
- ok
- fetched_at
- 2026-06-23 17:05:31