Embabel Framework Condition Annotation - Building Decision Making AI Agents

Embabel Framework Condition Annotation: Building Decision Making AI Agents

AISpring Boot

Learn how to build intelligent, decision-making AI agents with the Embabel framework Condition annotation, and Spring Boot. This step-by-step guide explores the @Condition annotation to control agent workflows based on logical rules

Table of Contents

1. Introduction

Welcome back to our journey into the Embabel framework! Building intelligent AI agents that can reason and make decisions is an important aspect of modern software development. In this series, we’re exploring how Embabel, a powerful framework for the JVM, makes this process accessible and robust.

In our first article, “Embabel Framework: Create Goal-Driven AI Agents for the JVM“, we laid the groundwork, covering the basics of Embabel and building our first simple meeting summarizer agent using the Embabel shell.

Then, we leveled up in our second article, “Embabel Framework: Build a REST API Based AI Agent”, by exposing our agent’s capabilities through a REST API, making it accessible to other services.

Now, in this third installment, we’ll dive into one of Embabel’s important features: Conditions. We’ll learn how to give our agent the ability to make logical decisions, choosing different paths of execution based on specific criteria—much like an if-else block in traditional programming, but for AI agents.

2. The Core Concept: What Are Conditions in Embabel?

Think of conditions as decision points in your agent’s workflow. They are simple, deterministic Java methods that return true or false. The Embabel framework uses the result of these conditions to decide which action to take next.

This is achieved using a few key annotations:

  • @Condition: You use this to mark a method as a condition. This method must return a boolean.
  • @Action(pre=…): The pre (pre-condition) attribute on an action tells Embabel: “Only run this action if the specified condition returns true.”
  • @Action(post=…): The post (post-condition) attribute on an action tells Embabel: “After this action runs, its output can be used to evaluate these named conditions.”

By combining these, you can create sophisticated, rule-based workflows that guide your AI agent, ensuring it follows your business logic precisely before using the creative power of an LLM.



3. Building Agent: E-Commerce Replacement Agent

Our demo agent will handle a simple but realistic scenario:

Business Flow:

  1. Customer submits a replacement request with product SKU and problem description
  2. Agent checks product inventory status
  3. Decision Point:
    • Condition 1 (In Stock): Issue a replacement
    • Condition 2 (Out of Stock): Issue a refund
  4. Return the final decision to the customer

This workflow perfectly demonstrates how conditions guide agent behavior. The agent doesn’t blindly execute all actions—it intelligently chooses which path to take based on runtime data.

⚙️ Project Structure & Setup

Before diving into the code, let’s understand how our project is organized:

embabel-condition-demo-ecommerce-replacement-agent
├── src
│   └── main
│       ├── java
│       │   └── com
│       │       └── bootcamptoprod
│       │               ├── agent
│       │               │   └── EcommerceProductReplacementAgent.java  # Agent with conditions
│       │               ├── config
│       │               │   └── ConfigureOpenRouterModels.java         # LLM configuration
│       │               ├── controller
│       │               │   └── EcommerceController.java               # REST endpoint
│       │               ├── dto
│       │               │   └── FinalDecision.java                     # Response model
│       │               │   └── InventoryStatus.java                   # Inventory state
│       │               │   └── ReplacementRequest.java                # Request model
│       │               └── EmbabelConditionDemoApplication.java       # Spring Boot main class
│       └── resources
│           └──application.yml                                         # Configuration
└── pom.xml                                                            # Maven dependencies
Project Structure

Understanding the Project Structure

Here’s a quick breakdown of what each key file and package does:

  • EcommerceController.java: New REST controller that exposes our agent via HTTP endpoints
  • EcommerceProductReplacementAgent.java: The heart of our application, where the agent’s logic, actions, and conditions are defined.
  • dto package (FinalDecision.java, InventoryStatus.java, ReplacementRequest.java): This directory holds our Data Transfer Objects (DTOs). These are simple Java record classes that define the structure of our data, including the incoming API request (ReplacementRequest.java) and the final decision output (FinalDecision.java), which are used by the agent to process information.
  • ConfigureOpenRouterModels.java: This is a Spring @Configuration class responsible for setting up and providing the LLM (in this case, Free models from the OpenRouter platform) that our agent will use to process information. We will be using a free model from OpenRouter platform, due to which we have added this configuration. If you are using OpenAI or Anthropic you can configure the OPENAI_API_KEY or ANTHROPIC_API_KEY environment variables.
  • EmbabelConditionDemoApplication.java: The main class that boots up our Spring Boot application. It contains the crucial @EnableAgents annotation that tells Embabel to find and activate our EcommerceProductReplacementAgent.
  • application.properties: Our configuration file. This is where we set the default LLM for Embabel to use (z-ai/glm-4.5-air:free) and configure logging levels for easier debugging.
  • pom.xml: The Maven project file. It manages all our project’s dependencies, including the most important one for this project: embabel-agent-starter, which provides all the core Embabel agent functionalities.


Diving Into the Code

Let’s break down each component of our application.

Step 1: Configure Maven Dependencies

Every Spring Boot project starts with the pom.xml file. This is where we tell Maven which libraries our project needs to function. Our pom.xml now includes spring-boot-starter-web to build a web application and embabel-agent-starter for the core agent functionalities.

<properties>
	<java.version>21</java.version>
	<embabel-agent.version>0.3.0-SNAPSHOT</embabel-agent.version>
</properties>

<dependencies>
  <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
  </dependency>
  <dependency>
    <groupId>com.embabel.agent</groupId>
    <artifactId>embabel-agent-starter</artifactId>
    <version>${embabel-agent.version}</version>
  </dependency>
  <dependency>
		<groupId>org.springframework.boot</groupId>
		<artifactId>spring-boot-starter-actuator</artifactId>
	</dependency>
</dependencies>

<repositories>
	<repository>
		<id>embabel-releases</id>
		<url>https://repo.embabel.com/artifactory/libs-release</url>
		<releases>
			<enabled>true</enabled>
		</releases>
		<snapshots>
			<enabled>false</enabled>
		</snapshots>
	</repository>
	<repository>
		<id>embabel-snapshots</id>
		<url>https://repo.embabel.com/artifactory/libs-snapshot</url>
		<releases>
			<enabled>false</enabled>
		</releases>
		<snapshots>
			<enabled>true</enabled>
		</snapshots>
	</repository>
</repositories>
pom.xml

In this configuration:

  • This Maven configuration sets up our Spring Boot project with Java 21.
  • The key dependency here is embabel-agent-starter, which brings in all the necessary components to create Embabel application. This will also bring the spring-ai dependencies that are required for our application.
  • The dependency spring-boot-starter-web Provides REST API capabilities, embedded Tomcat server, and Spring MVC
  • We’ve also included custom repositories to fetch the latest Embabel artifacts.
  • The Actuator dependency adds health checks and metrics endpoints for production monitoring.

Step 2: Configure Application Properties

Next, let’s configure our application settings in application.yml:

spring:
  application:
    name: embabel-condition-demo-ecommerce-replacement-agent

embabel:
  models:
    defaultLlm: z-ai/glm-4.5-air:free

logging:
  level:
    org.springframework.ai: DEBUG

management:
  endpoints:
    web:
      exposure:
        include: "*"
application.yaml

📄 Configuration Overview

  • defaultLlm: We’re using GLM 4.5 Air (free tier) via OpenRouter
  • logging.level: Enables DEBUG logging for Spring AI to trace LLM interactions
  • management.endpoints: Exposes all actuator endpoints for monitoring (health, metrics, etc.)

This configuration tells Embabel which default LLM to use for generating intelligent responses. The free tier model works great for learning and development!



Step 3: Application Entry Point

This is the main class that bootstraps our entire application.

package com.bootcamptoprod;

import com.embabel.agent.config.annotation.EnableAgents;
import com.embabel.agent.config.annotation.LoggingThemes;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
@EnableAgents(
        loggingTheme = LoggingThemes.STAR_WARS
)
public class EmbabelConditionDemoApplication {

    public static void main(String[] args) {
        SpringApplication.run(EmbabelConditionDemoApplication.class, args);
    }

}
EmbabelConditionDemoApplication.java

Explanation:

  • This is our Spring Boot application entry point.
  • The @EnableAgents annotation activates Embabel’s agent framework capabilities. This annotation scans for agent definitions and registers them.
  • The loggingTheme = LoggingThemes.STAR_WARS parameter adds fun, themed logging output to make debugging more engaging (you’ll see Star Wars-themed log messages!).
  • This class bootstraps both Spring Boot and Embabel frameworks simultaneously

Step 4: Create Data Transfer Object (DTOs)

Our DTOs define the structure of data flowing through the application.

package com.bootcamptoprod.dto;

public record ReplacementRequest(
        String productSku,
        String problemDescription
) {}
ReplacementRequest.java

Purpose: This record captures the customer’s replacement request. It contains:

  • productSku: The unique identifier for the product (e.g., “SKU-HDPHN-01”)
  • problemDescription: Details about why the customer needs a replacement

Think of this as the input form a customer would fill out on your website.

package com.bootcamptoprod.dto;

public record InventoryStatus(
        String productSku,
        boolean inStock
) {}
InventoryStatus.java

Purpose: This record represents the inventory check result:

  • productSku: Which product was checked
  • inStock: Whether the product is available (true/false)

This is the crucial piece of information our conditions will evaluate!

package com.bootcamptoprod.dto;

public record FinalDecision(
        String decisionCode,   // "REPLACEMENT_ISSUED" or "REFUND_ISSUED"
        String message
) {}
FinalDecision.java

Purpose: The final response sent back to the customer:

  • decisionCode: A code indicating what action was taken
  • message: A human-friendly message explaining the decision

This is what the customer ultimately receives—either good news about a replacement or information about their refund.



Step 5: Configuring LLM Models

This configuration class sets up multiple LLM models via OpenRouter, a unified API gateway for various AI models. Here’s what’s happening:

package com.bootcamptoprod.config;

import com.embabel.agent.api.models.OpenAiCompatibleModelFactory;
import com.embabel.common.ai.model.Llm;
import com.embabel.common.ai.model.PerTokenPricingModel;
import io.micrometer.observation.ObservationRegistry;
import org.jetbrains.annotations.NotNull;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

import java.time.LocalDate;

@Configuration
public class ConfigureOpenRouterModels extends OpenAiCompatibleModelFactory {

    public ConfigureOpenRouterModels(@NotNull ObservationRegistry observationRegistry, @Value("${OPENROUTER_API_KEY}") String apiKey) {
        super(
                "https://openrouter.ai",
                apiKey,
                "/api/v1/chat/completions",
                null,
                observationRegistry
        );
    }

    @Bean
    public Llm mistral7b_free() {
        return openAiCompatibleLlm(
                "mistralai/mistral-7b-instruct:free",
                new PerTokenPricingModel(0.0, 0.0),
                "OpenRouter",
                LocalDate.of(2024, 10, 1)
        );
    }

    @Bean
    public Llm deepseek_r1_t2() {
        return openAiCompatibleLlm(
                "tngtech/deepseek-r1t2-chimera:free",
                new PerTokenPricingModel(0.0, 0.0),
                "OpenRouter",
                LocalDate.of(2025, 5, 28)
        );
    }

    @Bean
    public Llm glm_4_5_air() {
        return openAiCompatibleLlm(
                "z-ai/glm-4.5-air:free",
                new PerTokenPricingModel(0.0, 0.0),
                "OpenRouter",
                LocalDate.of(2025, 5, 28)
        );
    }
}
ConfigureOpenRouterModels.java

Explanation:

  • This configuration class registers OpenRouter as an AI model provider.
  • By extending OpenAiCompatibleModelFactory, we leverage OpenRouter’s OpenAI-compatible API.
  • The constructor configures the base URL and endpoint for OpenRouter API.
  • The @Value("${OPENROUTER_API_KEY}") annotation injects your API key, which you must provide as an environment variable when running the application.
  • The LLM beans methods create different model instances with zero pricing (useful for free tier or internal tracking) and metadata about the model.
  • The PerTokenPricingModel(0.0, 0.0) indicates these are free-tier models with no cost per token.
  • The ObservationRegistry integration enables automatic metrics collection for model usage.

Why Multiple Models? Having multiple models configured gives you flexibility to switch between them without code changes

NOTE: We will be using free model from OpenRouteri due to which we have added this configuration class. If you are using OpenAI or Anthropic you can directly configure the OPENAI_API_KEY or ANTHROPIC_API_KEY environment variables. In that case, this class will not be required.

Step 6: Building the Conditional Agent (The Heart of Our Tutorial!)

This is where we define our AI agent and its capabilities.

package com.bootcamptoprod.agent;

import com.bootcamptoprod.dto.FinalDecision;
import com.bootcamptoprod.dto.InventoryStatus;
import com.bootcamptoprod.dto.ReplacementRequest;
import com.embabel.agent.api.annotation.AchievesGoal;
import com.embabel.agent.api.annotation.Action;
import com.embabel.agent.api.annotation.Agent;
import com.embabel.agent.api.annotation.Condition;
import com.embabel.agent.api.common.Ai;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.stereotype.Component;

import java.util.Map;

@Agent(
        name = "ecommerce-product-replacement-agent",
        description = "Handles product replacements and refunds based solely on inventory status.",
        version = "1.0.0"
)
@Component
public class EcommerceProductReplacementAgent {

    private static final Logger log = LoggerFactory.getLogger(EcommerceProductReplacementAgent.class);

    private static final Map<String, Integer> inventory = Map.of("SKU-HDPHN-01", 10, "SKU-KBD-05", 0);

    @Action(description = "Check product inventory whether mentioned product is in stock", post = {"isInStock", "isOutOfStock"})
    public InventoryStatus checkInventory(ReplacementRequest replacementRequest) {
        log.info("[ACTION] checkInventory START - productSku: {}", replacementRequest.productSku());
        int stock = inventory.getOrDefault(replacementRequest.productSku(), 0);
        boolean inStock = stock > 0;
        InventoryStatus status = new InventoryStatus(replacementRequest.productSku(), inStock);
        log.info("[ACTION] checkInventory END - SKU: {}, units: {}, inStock: {}", replacementRequest.productSku(), stock, inStock);
        return status;
    }

    @Condition(name = "isInStock")
    public boolean isInStock(InventoryStatus status) {
        log.info("[CONDITION] isInStock START - SKU: {}, inStock: {}", status.productSku(), status.inStock());
        boolean result = status.inStock();
        log.info("[CONDITION] isInStock END - result: {}", result);
        return result;
    }

    @Condition(name = "isOutOfStock")
    public boolean isOutOfStock(InventoryStatus status) {
        log.info("[CONDITION] isOutOfStock START - SKU: {}, inStock: {}", status.productSku(), status.inStock());
        boolean result = !status.inStock();
        log.info("[CONDITION] isOutOfStock END - result: {}", result);
        return result;
    }

    @Action(pre = {"isInStock"})
    @AchievesGoal(description = "Replacement issued for in-stock products")
    public FinalDecision issueReplacement(ReplacementRequest replacementRequest, Ai ai) {
        log.info("[GOAL] issueReplacement START - productSku: {}", replacementRequest.productSku());
        FinalDecision decision = ai.withDefaultLlm()
                .createObjectIfPossible(
                        """
                                Inform the customer that their return is approved, replacement unit has been ordered and will be shipped soon. 
                                Respond with decisionCode = "REPLACEMENT_ISSUED" and message.
                                """,
                        FinalDecision.class
                );
        log.info("[GOAL] issueReplacement END - decision: {}", decision);
        return decision;
    }

    @Action(pre = {"isOutOfStock"})
    @AchievesGoal(description = "Refund issued for out-of-stock products")
    public FinalDecision issueRefund(ReplacementRequest replacementRequest, Ai ai) {
        log.info("[GOAL] issueRefund START - productSku: {}", replacementRequest.productSku());


        FinalDecision decision = ai.withDefaultLlm()
                .createObjectIfPossible(
                        """
                                Inform the customer that the product is out of stock and a refund has been issued.
                                Respond decisionCode = "REFUND_ISSUED" and message.
                                """,
                        FinalDecision.class
                );
        log.info("[GOAL] issueRefund END - decision: {}", decision);
        return decision;
    }
}
EcommerceProductReplacementAgent.java

Explanation:

This is the heart of our application – the intelligent agent.

  1. @Agent: This annotation marks the class as an Embabel agent, giving it a unique name and description that the framework can use to identify it.
  2. @Action: This annotation denotes actions that the agent can perform. These are the building blocks of its workflow.
    • checkInventory: This is the agent’s first step. It performs a simple, deterministic lookup in our simulated inventory map. Crucially, it uses the post attribute (post = {“isInStock”, “isOutOfStock”}). This is an announcement to the Embabel planner, declaring: “After this action finishes, its result can be used to immediately evaluate the specific named conditions isInStock and isOutOfStock.”
    • issueReplacement and issueRefund: These are the two possible final actions that can achieve the agent’s goal. They use the pre attribute to declare their requirements. For example, pre = {“isInStock”} tells the planner, “Only run me if the isInStock condition has been checked and has returned true.”
  3. @Condition: This marks a method as a logical check that returns true or false. These are the decision points in the agent’s workflow.
    • isInStock and isOutOfStock: These methods take the InventoryStatus object produced by the checkInventory action and perform a simple boolean check. The name attribute is essential, as it links these conditions to the pre and post attributes in the @Action annotations, allowing the planner to connect them.
  4. @AchievesGoal: This annotation on the issueReplacement and issueRefund methods defines the agent’s possible finishing moves. Embabel’s planner sees that its goal is to produce a FinalDecision. It identifies these two methods as the ones that can achieve it and works backward to figure out how to satisfy their pre-conditions.
  5. Ai: This parameter, injected into our goal-achieving actions, is our gateway to the Large Language Model. We use its fluent API (ai.withDefaultLlm().createObjectIfPossible(…)) to generate a user-friendly message. This is a perfect example of Embabel’s philosophy: use deterministic Java for core logic (checking inventory) and use the LLM for tasks that require natural language creativity (crafting a response).


Step 7: Create the REST Controller

This is the bridge between the web and our agent. It defines the API endpoint and uses Embabel’s AgentPlatform to invoke our agent programmatically.

package com.bootcamptoprod.controller;

import com.bootcamptoprod.dto.FinalDecision;
import com.bootcamptoprod.dto.ReplacementRequest;
import com.embabel.agent.api.common.autonomy.AgentInvocation;
import com.embabel.agent.core.AgentPlatform;
import com.embabel.agent.core.ProcessOptions;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
@RequestMapping("/api/v1/ecommerce/product")
public class EcommerceController {

    private static final Logger log = LoggerFactory.getLogger(EcommerceController.class);

    private final AgentPlatform agentPlatform;

    @Autowired
    public EcommerceController(AgentPlatform agentPlatform) {
        this.agentPlatform = agentPlatform;
    }

    @PostMapping("/replacement")
    public ResponseEntity<FinalDecision> handleReplacement(@RequestBody ReplacementRequest request) {

        var productReplacementAgentInvocation = AgentInvocation
                .builder(agentPlatform)
                .options(ProcessOptions.builder().verbosity(v -> {
                    v.showPrompts(true);
                    v.showPlanning(true);
                    v.showLlmResponses(true);
                }).build())
                .build(FinalDecision.class);

        FinalDecision finalDecision = productReplacementAgentInvocation.invoke(request);
        log.info("Result: {}", finalDecision);
        return ResponseEntity.ok(finalDecision);
    }
}
EcommerceController.java

Explanation:

This controller exposes a single endpoint: POST /api/v1/ecommerce/product/replacement

Here’s the flow:

  1. Dependency Injection: AgentPlatform is injected—this is Embabel’s core component that manages agents
  2. AgentInvocation Builder: We create an invocation with verbose logging options:
    • showPrompts(true): See the prompts sent to the LLM
    • showPlanning(true): See how the agent plans its workflow
    • showLlmResponses(true): See raw LLM responses
  3. Build and Invoke: We specify FinalDecision.class as the expected return type and invoke the agent with our request
  4. Return Response: The agent’s decision is wrapped in a ResponseEntity and sent back

The verbosity options are incredibly helpful for debugging and understanding how your agent makes decisions!



4. Testing the Application

With the application running, you can now test the endpoint using any API client like curl or Postman.

Scenario 1: Product is In Stock

curl --location 'http://localhost:8080/api/v1/ecommerce/product/replacement' \
--header 'Content-Type: application/json' \
--data '{
    "productSku": "SKU-HDPHN-01",
    "problemDescription": "The headphones have a crackling sound in the right ear."
}
'
Terminal

Expected JSON Response:

{
    "decisionCode": "REPLACEMENT_ISSUED",
    "message": "Return approved, replacement unit ordered and will be shipped soon."
}
API Response

Scenario 2: Product is Out of Stock

curl --location 'http://localhost:8080/api/v1/ecommerce/product/replacement' \
--header 'Content-Type: application/json' \
--data '{
    "productSku": "SKU-KBD-05",
    "problemDescription": "The '\''W'\'' key on my keyboard is not working."
}'
Terminal

Expected JSON Response:

{
    "decisionCode": "REFUND_ISSUED",
    "message": "Product out of stock, refund issued."
}
API Response

5. Putting It All Together: The Agent’s Thought Process

So, how does the agent actually “think”? Embabel’s planner follows a logical, goal-oriented process. Here’s a step-by-step breakdown of what happens when a request comes in:

  1. The Request Arrives: A user sends a POST request to the /replacement endpoint in our EcommerceController.
  2. The Goal is Defined: The controller invokes the agent, telling it that the ultimate goal is to produce an object of type FinalDecision.
  3. The Planner Works Backward: The Embabel planner is activated. It looks at the EcommerceProductReplacementAgent and identifies the two actions marked with @AchievesGoal that can produce the desired FinalDecision: issueReplacement and issueRefund.
  4. A Roadblock is Identified: The planner examines these two goal actions and sees they have requirements—a pre-condition. It cannot run issueReplacement without first knowing if the isInStock condition is true, and it can’t run issueRefund without knowing if isOutOfStock is true. At this point, the status of these conditions is unknown.
  5. The Missing Link is Found: To resolve the unknown conditions, the planner searches for another action that can help. It discovers the checkInventory action. By reading its post attribute, the planner sees that this can be used to evaluate the isInStock and isOutOfStock conditions.
  6. A Plan is Formed: The planner now has a clear path forward. It constructs a multi-step plan:
    • Step A: Execute the checkInventory action first.
    • Step B: Take the result of that action and evaluate the conditions.
    • Step C: Based on which condition is met, execute the correct final action (issueReplacement OR issueRefund).
  7. The Plan is Executed: The agent follows the plan. It runs checkInventory, gets the InventoryStatus, and evaluates the boolean conditions.
  8. The Goal is Achieved: It executes the one goal action whose pre-condition was met. This action uses the LLM to generate a friendly message and returns the final FinalDecision.
  9. The Result is Returned: This FinalDecision object travels back to the controller, which sends it as a JSON response to the user.


6. Video Tutorial

For a complete walkthrough, check out our video tutorial. We build the e-commerce replacement agent from the ground up, providing a live demonstration of how to use conditions to control your agent’s workflow and ensure it follows your business logic.

📺 Watch on YouTube:

7. Source Code

The full source code for our e-commerce decision-making agent is available on our GitHub repository. The best way to learn is by doing, so we encourage you to clone the repo, set your OPENROUTER_API_KEY as an environment variable, and launch the Spring Boot application. This will let you test the conditional logic firsthand and start experimenting with building your own rule-based AI agents.

🔗 Embabel Conditions Demo: https://github.com/BootcampToProd/embabel-condition-demo-ecommerce-replacement-agent

8. Things to Consider

As you build conditional agents, keep these best practices in mind:

  1. Real-World State: Our agent uses a simple in-memory map for inventory. In a production system, the checkInventory action would call a database or an external inventory management service.
  2. Use Descriptive Condition Names: Name conditions clearly: isUserPremium, hasValidCoupon, isBusinessDay. This makes workflows self-documenting.
  3. Expanding the Logic with More Conditions: Our example is a simple binary choice (replace or refund). A real-world system might have more outcomes. Embabel’s planner is designed to handle this increased complexity, choosing the correct path out of many potential options.
  4. Handle Edge Cases: What happens if a product SKU doesn’t exist in inventory? Our code defaults to 0 stock. Consider adding validation and error handling.
  5. Test Each Path: Create test cases that exercise every condition branch. In our case, test both in-stock and out-of-stock scenarios.
  6. Secure Your API Keys: Never hardcode API keys. Use environment variables or secret management systems.
  7. Monitor LLM Costs: While we’re using free-tier models, production apps should monitor token usage.


9. FAQs

Can an action have multiple pre-conditions?

Yes. If you specify pre = {“conditionA”, “conditionB”}, the action will only run if both conditions are true (an AND relationship).

Can I have more than two conditions in a workflow?

Yes! You can create as many conditions as needed. For example, you could add isExpressShippingAvailable, isWarrantyActive, or isVIPCustomer conditions to create more sophisticated workflows.

How do I debug when the wrong path executes?

Enable verbose logging in ProcessOptions as we did. You’ll see exactly which conditions evaluated to true/false.

Can conditions access data from multiple previous actions?

Yes! Embabel maintains context throughout the workflow. Conditions can access any data produced by previous actions.

10. Conclusion

In this article, we demonstrated how to implement conditional logic within the Embabel framework using the @Condition annotation. This feature is essential for building agents that can follow specific business rules, allowing you to separate deterministic decision-making from the generative capabilities of an LLM. This enables you to create more robust and predictable AI applications on the JVM, ensuring that agent behavior remains aligned with your core operational requirements.



11. Learn More

#

Interested in learning more?

Embabel Framework: Build a REST API Based AI Agent

Learn More


Add a Comment

Your email address will not be published.