AI

Embabel: an agent framework for the JVM A working reference: philosophy, architecture, a worked example, and REST invocation. Updated for Embabel 1.0 (GA, July 20, 2026). 1. Philosophy Embabel is built by no other than Rod Johnson. Every Java (should) know who he is. He is the creator of the Spring Framework, the most used Java framework for more that two decades. It is build on the premise that neither raw LLM calls nor MCP tool access are enough to build reliable business applications. MCP is an important step forward and Embabel embraces it, but a higher-level orchestration layer is still needed — especially for explainability (why were choices made) and discoverability, which MCP doesn’t address on its own. ...

Every Java field you’ve ever declared has a secret. Before your constructor or static initializer ever touches it, the JVM has already written something to it, a 0, a false, a null. You never see it happen, but it happens, and it’s the source of a whole category of bugs that are miserable to track down. JEP 539 gives the JVM a way to close that gap. It’s a preview feature targeted for JDK 28, and it’s worth getting comfortable with even before you can use it directly, because a few other Java features are quietly built on top of it. ...

Everything BrightCart has built so far has a peculiar kind of amnesia. Each request lands, gets handled, and vanishes from the system’s mind completely. The summarizer, the classifier, the enrichment service. Every single call starts from a blank slate, as if the previous one never happened. For one-shot ticket processing, that’s fine. But watch what happens the moment a support agent tries to actually work a ticket through the assistant: ...

There’s a specific moment when a Claude Code setup crosses over from “collection of tricks” to “environment I actually trust.” For me it was a morning at work a few weeks after I’d finished the last big round of .claude/ cleanup. I opened a session on a service I’d been fighting a bug in the day before, typed one sentence about the bug, and Claude Code — before I did anything else — knew what branch I was on, what other work was in progress, what JIRA ticket the bug was tracked in, what the team’s transactional conventions were, and which of the four review subagents I’d want to run before committing. I didn’t have to explain any of that. The setup did. ...

It took me three months of using Claude Code before I finally installed a hook. It took me about ten minutes after that to wonder why I’d waited so long. The problem was banal. I’d been running Claude Code alongside a Spring Boot project at work, and after a longer refactoring session — twenty-something files touched, an interface renamed, a couple of implementations moved to a new package — I committed and pushed. Everything compiled. Tests passed. Life was good until Jenkins came back thirty seconds later with a red X: spotless:check had failed on eight files. Claude had used its own idea of import ordering, and our project uses a stricter one. ...

At the end of article 6, something slightly magical happened and I asked you to just accept it. The model requested a tool call, and Spring AI executed the method and fed the result back — looping until the model was satisfied — without us writing a single line of orchestration. I called it “Spring’s tool-calling machinery” and moved on. Time to name that machinery. It was an advisor. Specifically a built-in one called ToolCallAdvisor, sitting quietly in the request pipeline, running the whole tool loop on our behalf. ...

The moment subagents clicked for me was during a code review I’d already once let through. A colleague had sent through a PR touching one of our JMS message handlers — a service that processes incoming payment-status webhooks from a downstream provider, updates the corresponding ticket, and acknowledges the message back to the broker. Two hundred lines, four external touch-points, and one atomic-looking flow that was actually anything but. The initial review from a single Claude Code thread came back the way these things often do: “The handler looks well-structured. Consider extracting the parsing into a helper class. Log messages could be more descriptive.” Fair points. Also, not the kind of review that catches anything you’d be embarrassed by in production. ...

At the end of the last article, BrightCart’s classifier did something impressive and something useless, at the same time. Impressive: it read a chaotic customer rant and pulled out orderNumber: "BC-48291" as a clean, typed field. Useless: it had absolutely no idea whether order BC-48291 exists, what’s in it, or where it is. It extracted that order number the same way it would extract BC-99999 or BC-BANANA — by pattern-matching text. The model was working entirely from the customer’s words, and customers, as we’ve established, are not a reliable source of truth. ...

I spent forty-five minutes last week undoing a refactor that should have taken ten. The change looked simple. Rename Ticket.getStatus() to Ticket.getStatusText() — we’d added a proper enum-typed getStatusEnum() a while back, and the string version needed to be less ambiguous. I asked Claude Code to do the rename across the codebase. Standard stuff. Claude confidently reported back: “Renamed 47 references to getStatus across 23 files.” It felt fast. It felt done. ...

Let me show you the exact moment a Spring AI demo turns into a Spring AI application. In the last two articles, BrightCart’s summarizer happily returned prose, and prose was the right answer — a human support agent reads it. But the moment I tried to make the system do something with a model’s answer, I hit a wall. I wanted to classify tickets so they could be routed automatically: delivery problems to the logistics team, billing issues to finance, and so on. So I asked the model to classify a ticket, and it cheerfully replied: ...