Embabel Agent Framework
A JVM framework for planning and testing agentic flows that combine LLM calls with typed business code.
Per-dimension scores and reasoning
Insufficient evidence: No documentation or code for permission management, user confirmation, data flow transparency, sensitive data handling, dependency security, external effects, rollback, or source attribution. Workflows use secrets (e.g., DEPENDABOT_SECRET, GCP_SERVICE_ACCOUNT_CREDENTIALS) but no least-privilege principle is stated. Hence all criteria scored 0.
Insufficient evidence: No documentation for self-consistency, dependency availability, or failure messages. Workflows use third-party actions without verification. Hence all criteria scored 0.
Insufficient evidence: No documentation for target audience, scenarios, capability boundaries, trigger precision, or environment fit. README-appendix.md only describes internal architecture, not usage scenarios. Hence all criteria scored 0.
Insufficient evidence: No documentation for information architecture, install notes, naming stability, examples/FAQ, known limitations, versioning/changelog, or maintenance responsibility. LICENSE file exists but no other convention info. Hence all criteria scored 0.
Insufficient evidence: No documentation for output usability, marginal value, or cost-benefit. Hence all criteria scored 0.
Insufficient evidence: No documentation for claim traceability, cross-source corroboration, or fact/inference separation. Hence all criteria scored 0.
- Repository content is insufficient to support a comprehensive assessment of the Agent product; only partial architecture description and CI/CD workflows are provided.
- Workflows use secrets and third-party actions without security audit or least-privilege documentation.
- No installation, usage, or configuration instructions are provided, making it difficult for users to actually deploy or use the framework.
What does this agent do, and when should you use it?
Embabel Agent Framework is a JVM agentic-flow framework written in Kotlin with a natural Java programming model. Developers define flows with @Agent, @Action, @Goal, and @Condition annotations, or with Kotlin agent { } and action { } blocks backed by domain objects. Its AgentPlatform runs in Focused, Closed, or Open mode and replans after every action rather than simply following a fixed sequence. GOAP is the default planner, Utility AI is included, and the planning step is pluggable. The framework is built on Spring and the JVM, can use Spring AI ChatModel integrations and MCP servers, and can expose an SSE MCP server or an A2A service through its a2a profile.
The framework takes user input and domain objects, derives plans from action inputs, outputs, and conditions, then reassesses and replans after each @Action. An action can run ordinary Java or Kotlin code, or call a model through Ai.withDefaultLlm(), Ai.withLlm(...), and createObject(...) to produce typed domain objects; actions can require tool groups such as CoreToolGroups.WEB. AgentPlatform can directly invoke a selected agent in Focused mode, classify intent to select an agent in Closed mode, or assemble a path from known goals, actions, and conditions in Open mode. It can consume MCP servers configured through the Spring AI MCP client, expose capabilities through its /sse MCP endpoint, and start an A2A server when the a2a Spring profile is enabled.
- A Java Spring Boot team that needs to combine existing services, transactions, and domain models with LLM-driven steps in a testable flow.
- A Kotlin team that wants to author state-aware, replanning task flows with the agent { } and action { } DSL.
- An application developer who needs one workflow to coordinate regular code, typed LLM-generated objects, and web-tool access.
- A team that wants to consume Docker Desktop MCP tools or expose local Embabel functionality to Claude Desktop over SSE.
- A JVM project that needs unit tests for prompts, model options, and action logic instead of relying only on end-to-end tests.
- A system that wants Open mode to find new paths by combining defined actions and goals, while restricting execution to defined steps.
What are this agent's strengths and limitations?
- Default GOAP planning and replanning after every action let defined steps be recombined from runtime state instead of being limited to a finite-state machine or fixed sequence.
- Actions, goals, and conditions are backed by strongly typed domain models, allowing Java/Kotlin code and structured LLM object creation to work together.
- It offers both a Spring annotation model and a Kotlin DSL while retaining Spring injection, AOP, persistence, and transaction options.
- Focused, Closed, and Open execution modes provide distinct boundaries between direct code-driven invocation and dynamic goal selection across resources.
- It documents an MCP client, an SSE MCP server, and an A2A profile, with paths for local models, OCI Generative AI, and Spring AI ChatModel providers.
- The project describes itself as early stage; federation, budget-aware agents, and implementations for other platforms are roadmap goals rather than established features.
- Full examples and integration tests depend on external model services and credentials; integration tests list OpenAI, Anthropic, DeepSeek, and Mistral keys.
- The documented web-tool experience adds local setup complexity through Docker Desktop, MCP Catalog tools, and network access.
- Open mode is the most powerful but least deterministic; it only proceeds when it is convinced a goal applies, and developers may need GoalChoiceApprover to narrow selection.
- Gradle users must explicitly add the Spring Milestones repository to resolve the Embabel BOM's experimental Spring MCP BOM dependency.
How do you install or deploy this agent?
Create a runnable project with:
uvx --from git+https://github.com/embabel/project-creator.git project-creatorOr add this dependency to a Maven pom.xml:
<dependency>
<groupId>com.embabel.agent</groupId>
<artifactId>embabel-agent-starter</artifactId>
<version>0.3.0</version>
</dependency>
Set OPENAI_API_KEY. The README states that a template project can run when Maven and that key are available; some examples and the coding agent also require ANTHROPIC_API_KEY. For the documented Docker MCP tool setup, install Docker Desktop >4.43.2 and enable Brave Search, Fetch, Puppeteer, and Wikipedia from its MCP catalog.
How do you use this agent?
Annotate a Spring-managed class with @Agent and define steps with @Action that accept domain objects and Ai; mark a completing action with @AchievesGoal. An action can call ai.withDefaultLlm().createObject(prompt, ResultType.class) or execute normal business code. Run unit tests with mvn test. In the example project's Spring Shell, enter help to list commands, then run:
execute "Lynda is a Scorpio, find news for her" -p -rThe -p option logs prompts and -r logs model responses; x is an execute shortcut.
How does this agent compare with similar options?
The README positions Embabel as a higher-level abstraction built on Spring AI, comparing Spring AI to the Servlet API and Embabel to Spring MVC. Against finite-state machines or fixed sequential execution, Embabel emphasizes dynamic planning and action selection through GOAP or Utility AI.