Embabel Agent Framework: JVM-Native AI Agents
embabel/embabel-agent
Embabel Agent Framework is a Kotlin-first framework for building AI agents on the JVM, using Goal Oriented Action Planning instead of a hand-wired conditional chain to decide what an agent does next. Reach for it if you're already on Spring and want agent logic that's strongly typed and unit-testable; skip it if your stack is Python or you just need one LLM call wrapped in a function.
Understanding Embabel's Core Purpose
Embabel Agent Framework is a JVM library for authoring agentic flows that mix LLM-prompted steps with regular code and a typed domain model, rather than a hosted agent product. It models flows as Actions, Goals, Conditions and a Plan that the system replans after every action, similar to an OODA loop. Use it when you want agent behavior expressed in Java or Kotlin classes, not YAML or Python.
The Need for a JVM-Centric Agent Framework
Most agent frameworks assume you're writing Python and gluing together untyped dicts and prompt strings. Teams running Spring services, Kotlin backends, or JVM-based enterprise systems either bolt on a Python microservice for the agent logic or hand-roll a state machine that hard-codes every path an LLM call can take. Embabel Agent Framework targets that specific gap: it lets a JVM developer define Actions, Goals and Conditions as ordinary Java or Kotlin code, and leaves the sequencing to a planner instead of an if/else chain that has to be rewritten every time a new capability gets added.
Core Concepts and Differentiators
- ✓Goal Oriented Action Planning (GOAP) by default — a dynamic AI planning algorithm borrowed from game AI that decides the action sequence at runtime and replans after each step, instead of executing a fixed FSM.
- ✓Utility AI mode — swap GOAP for utility-score-based action selection when there's no single fixed goal, aimed at open-ended exploration tasks.
- ✓Two authoring styles — an annotation model (@Agent, @Goal, @Condition, @Action, similar to Spring MVC) and an idiomatic Kotlin DSL using agent { } / action { } blocks.
- ✓Strongly typed domain model — Actions, Goals and Conditions are backed by typed objects instead of 'magic maps,' so refactoring tools keep working across prompt-adjacent code.
- ✓Three execution modes on AgentPlatform for multi-agent orchestration — Focused (code calls a specific agent), Closed (platform picks among known agents), and Open (platform assembles a custom agent from every available goal and action); the README notes Open gives the system the widest latitude to combine capabilities on its own, at the cost of being the least predictable of the three.
- ✓Built on Spring — agents can be injected and managed by the Spring container, decorated with Spring AOP, and use existing persistence and transaction management.
- ✓LLM mixing within one flow — per the README, different actions can call different LLMs, including local models, to balance cost and capability.
- ✓Designed for testability — per the README, both unit tests and full agent end-to-end tests are part of the intended workflow, illustrated in the example with a FakeOperationContext.
Building Agents: Code Examples
The README's running example is a StarNewsFinder agent: a class annotated @Agent(description = "...") with several @Action methods — one extracts a StarPerson from user input via ai.withLlm(...).createObjectIfPossible(...), one calls a plain Java service with no LLM involved at all, one calls a web-search tool group, and the last is marked @AchievesGoal to close out the flow and produce a Writeup object. The Kotlin version has the same shape, written as functions annotated @Action, and the README also shows a plain Kotlin DSL style using agent { } and action { } blocks as an alternative to annotations. Domain objects like StarPerson and Horoscope are ordinary Java records or Kotlin data classes, so the compiler catches mismatches between what a prompt returns and what downstream code expects.
Quick Start: Setting Up Embabel
The README's quick-start path is template-based, not a package install: click 'Use this template' on the Java or Kotlin agent template repo on GitHub to get a working Maven project. With an OPENAI_API_KEY already set and Maven installed, the README says you'll have an agent running in under a minute; the broader quick-start target it states is under 5 minutes. There's a separate Embabel Agent Examples Repository for tutorials. Adding Embabel as a dependency to an existing, non-template Maven or Gradle project isn't covered in the README, so that path is not clearly documented.
Advantages of Using Embabel
- ✓The typed domain model means the compiler and refactoring tools catch mismatches between prompt output and downstream code — no untyped dict passed between steps.
- ✓Dynamic replanning after every action (GOAP by default) means adding a new Action, Goal or Condition doesn't require touching a hand-written state machine.
- ✓Runs inside a normal Spring app, so persistence, transactions, DI and Spring AOP are already there instead of being rebuilt for the agent layer.
- ✓Both Java and Kotlin are treated as first-class, per the README, not Kotlin with a thin Java wrapper bolted on.
- ✓Built-in unit testing support, shown via FakeOperationContext in the example, so agent logic and prompt content can be asserted in a normal test rather than eyeballed in a chat window.
Current Scope and Future Directions
- △Open mode — the execution mode with the widest latitude to combine capabilities — is flagged in the README as the least deterministic of the three modes, so using it in production trades predictability for that flexibility.
- △Federation across Embabel systems and third-party frameworks is described in the README as a future direction, not a shipped capability today.
- △Natural-language-authored actions and goals aren't available yet — the README says the team is 'working toward' this, but flows are still authored in Java or Kotlin code.
- △At 3980 stars and 398 forks, the ecosystem is small next to general-purpose Python agent frameworks, so expect fewer third-party integrations, tutorials and Stack Overflow answers.
- △Adding Embabel as a dependency to an existing Maven or Gradle project outside the GitHub templates isn't documented in the README.
Embabel Compared to Other Frameworks
Common Questions About Embabel
Embabel Agent Framework is a JVM library for building AI agents that mix LLM calls with ordinary Java or Kotlin code and a typed domain model, using dynamic planning instead of a fixed script to decide what happens next.
Embabel Agent Framework is written in Kotlin and, per the README, offers a natural usage model from Java too, so both languages are treated as first-class rather than one being a thin wrapper around the other.
Embabel Agent Framework defaults to Goal Oriented Action Planning (GOAP), a non-LLM AI algorithm borrowed from game AI, and replans after every action; it also ships Utility AI as an alternative planning mode for open-ended tasks without one fixed goal.
Embabel Agent Framework is built directly on Spring: agents can be injected and managed by the Spring container, decorated with Spring AOP, and rely on Spring's persistence and transaction management, per the README.
Embabel Agent Framework's AgentPlatform supports three modes: Focused, where code calls a specific agent directly; Closed, where the platform picks among known agents for a classified intent; and Open, where the platform assembles a custom agent from every available goal and action — the most flexible mode but, per the README, the least deterministic.
Embabel Agent Framework is released under the Apache-2.0 license.
Best use cases
- •Adding an LLM-driven feature to an existing Spring Boot service without rewriting the app in Python.
- •Building multi-step agents where the next action depends on runtime conditions, not a fixed script.
- •Teams that want unit tests around agent logic and prompt content, not just manual chat-based QA.
- •Prototyping against the README's Tripper travel-planner agent example as a reference for a realistic, non-toy agent app.
Who should try it — and who should skip
Reach for Embabel Agent Framework if you're already running a Spring Boot or JVM backend and want agent logic living in the same codebase, DI container and test suite as the rest of the app — teams building an internal tool, a support flow, or something like the README's Tripper travel-planner example are the target case. Skip it if your team ships in Python, if you need a mature ecosystem of prebuilt connectors and community integrations right now, or if a single hardcoded LLM call already does the job and you don't need dynamic planning.