A support-triage AI agent in Java with Spring AI 2.0.1: one structured workflow step, a bounded tool loop, tenant data the model never sees, and refunds that wait for a human. Plus the guardrails Spring AI now ships and the ones you still write yourself.
On a well-built Spring Boot app, exposing your product to AI agents is almost trivial: annotate a service method, add one starter. The wiring is the easy part. Choosing what to expose and securing it is the real work. Here is the honest version, on Spring AI 2.0.
Four ways to map a Java bean, one JMH harness, real numbers. MapStruct costs almost nothing over hand-written code. One of the others is about 300x slower. Here is which, and when it matters.
You run a Java product and want to add an AI feature. There are two real framework choices. Here is the honest comparison across providers, RAG, tools, Spring fit, and the one thing that decides it for most teams.
Do Java virtual threads make a Spring Boot app faster? I load-tested the same app both ways on real AWS hardware. The honest answer: below saturation they do nothing, on CPU-bound work they do nothing, and where they win on blocking I/O, a properly tuned platform pool matches the throughput. The real case for virtual threads is not raw speed, it is having no pool to tune and a cheaper thread.
AWS says Graviton gives up to 40 percent better price-performance. I put the same Spring app on same-rank Intel, AMD, and Graviton instances and measured it. It is true, I got 43 to 60 percent, but the reason is not that Graviton is faster. It is cheaper, and same vCPU does not mean same cores.
