Why Embabel keeps the agent planner out of the model

The hard problem in JVM agent development is not sending a prompt from Java. It is making the workflow explainable, testable, and safe to resume when a model call fails. Embabel keeps language work inside Actions while goals, conditions, state transitions, and planning remain visible to the application.

A workflow layer above Spring AI

Spring AI handles model and provider access. Embabel adds an agentic-flow model built around Actions, Goals, Conditions, and an AgentPlatform. The repository is Kotlin-centered but offers a natural Java usage model.

GOAP keeps planning deterministic

Embabel uses Goal-Oriented Action Planning: compute a route from the current state toward a goal, execute one action, then replan from the new state. Planning is application code; model calls happen inside actions that need language reasoning. This improves cost control, logging, and recovery.

Types are operational boundaries

@Agent(description = "Write and review a technical article")
public class BlogAgent {
    @Action public Draft write(Topic topic) { /* model call */ }
    @Action public Review review(Draft draft) { /* model call */ }
}

Typed domain objects can make Draft, Review, Approval, and publication requests distinct states. Production still requires authorization, idempotency, timeouts, validation, human approval, and replayable audit logs.

A responsible evaluation path

Start from the official Java or Kotlin template, configure Maven and OPENAI_API_KEY, and run a closed-world task before adding external writes. Capture planner decisions, model calls, state changes, failures, and the final object.

Embabel is worth evaluating as an accountability layer for JVM agent workflows, not as proof that every integration is production-ready. Judge it by recovery and auditability, not by a successful demo.