Putting It All Together

Version: β‰₯5.5.x

This guide shows how all of EDDI's components work together to create a complete, functional bot. We'll build a real-world example step-by-step, explaining how each piece connects.

The Big Picture

EDDI bots are composed of interconnected components that flow through the Lifecycle Pipeline:

Dictionary β†’ Parser β†’ Behavior Rules β†’ Actions β†’ HTTP Calls / LLM β†’ Output β†’ User
    ↓          ↓           ↓              ↓            ↓              ↓
  Define    Extract    Decide what   Triggers    Fetch data    Format    Response
  words     meaning    to do        execution    or call AI   response

Each component is a separate configuration that's combined into packages, which are assembled into bots.

Real-World Example: Hotel Booking Bot

Let's build a bot that helps users book hotel rooms. It will:

  1. Greet users

  2. Ask for city and dates

  3. Check availability via API

  4. Show options

  5. Confirm booking via API

Component Overview

We'll need:

  • Dictionary: Define hotel-related vocabulary

  • Parser: Extract entities (cities, dates)

  • Behavior Rules: Conversation flow logic

  • Properties: Store user inputs

  • HTTP Calls: Check availability and create bookings

  • Output Templates: Display results dynamically

  • Package: Combine everything

  • Bot: Reference the package

Step 1: Create the Dictionary

Purpose: Teach the bot hotel-related language

Returns: eddi://ai.labs.regulardictionary/regulardictionarystore/regulardictionaries/DICT_ID?version=1

How it connects: Parser will use this dictionary to convert "I want to book a hotel" β†’ ["intent(book)", "entity(hotel)"]

Step 2: Create Behavior Rules

Purpose: Define conversation logic and when to trigger actions

Returns: eddi://ai.labs.behavior/behaviorstore/behaviorsets/BEHAVIOR_ID?version=1

How it connects:

  • Welcome rule triggers on first message β†’ shows welcome output

  • Check Availability rule triggers when user asks about availability AND city is in context β†’ calls API

  • Book Room rule triggers when user wants to book AND room is selected β†’ creates booking

Step 3: Create Property Configuration

Purpose: Extract and store user-provided data

Returns: eddi://ai.labs.property/propertysetterstore/propertysetters/PROPERTY_ID?version=1

How it connects: When user says "Paris", property extractor saves it as context.city for use in behavior rules and HTTP calls

Step 4: Create HTTP Calls

Purpose: Integrate with hotel booking API

Returns: eddi://ai.labs.httpcalls/httpcallsstore/httpcalls/HTTP_ID?version=1

How it connects:

  • check-availability call is triggered by behavior rule β†’ fetches available rooms β†’ creates quick reply buttons

  • create-booking call is triggered after user selects room β†’ creates booking β†’ stores booking ID and price

Step 5: Create Output Templates

Purpose: Define bot responses with dynamic data

Returns: eddi://ai.labs.output/outputstore/outputsets/OUTPUT_ID?version=1

How it connects:

  • welcome action β†’ shows greeting

  • httpcall(check-availability) action β†’ shows room count dynamically from API response

  • booking_confirmed action β†’ shows booking details from stored properties

Step 6: Create Package

Purpose: Bundle all components together

Returns: eddi://ai.labs.package/packagestore/packages/PACKAGE_ID?version=1

How it connects: Package defines the order of lifecycle tasks and loads all configurations

Step 7: Create Bot

Purpose: Create the top-level bot entity

Returns: Bot ID (e.g., BOT_ID)

How it connects: Bot references the package, which contains all the components

Step 8: Deploy Bot

Result: Bot is now active and ready to handle conversations!

Step 9: Test the Bot

Initial Conversation

Response:

Provide City and Check Availability

What happens internally:

  1. Parser: "check availability in Paris" β†’ ["intent(check_availability)", "entity(hotel)"]

  2. Behavior Rules: Matches "Check Availability" rule (has intent + city in context)

  3. Actions: Triggers httpcall(check-availability)

  4. HTTP Call: GET https://api.hotels.example.com/availability?city=Paris&checkIn=2025-06-01&checkOut=2025-06-05

  5. Response Processing: Creates quick reply buttons from room list

  6. Output: Shows available rooms with dynamic count

  7. Memory: Stores API response for later use

Response:

Book a Room

What happens internally:

  1. Parser: "book Deluxe Suite" β†’ ["intent(book)", "entity(room)"]

  2. Behavior Rules: Matches "Book Room" rule (has intent + selectedRoom)

  3. Actions: Triggers httpcall(create-booking) and booking_confirmed

  4. HTTP Call: POST https://api.hotels.example.com/bookings with room details

  5. Response Processing: Extracts bookingId and totalPrice, stores in properties

  6. Output: Shows confirmation with dynamic booking details

Response:

How the Components Connect: Visual Flow

Key Takeaways

1. Components are Modular

Each component (dictionary, behavior rules, HTTP calls, outputs) is:

  • Created independently via API

  • Versioned separately

  • Reusable across multiple bots

  • Testable in isolation

2. Packages Define Execution Order

The order in the package matters:

This is the lifecycle pipeline order.

3. Behavior Rules are the Orchestrator

Behavior rules decide:

  • WHEN to call APIs (httpcall(check-availability))

  • WHEN to show outputs (welcome, booking_confirmed)

  • WHICH actions to trigger based on conditions

4. Memory is the Connector

Everything stores data in and reads from conversation memory:

  • HTTP Calls store responses: memory.current.httpCalls.availableRooms

  • Properties store extracted data: context.city

  • Outputs read data: [[${context.bookingId}]]

5. Context Bridges External Systems

Your application passes context to inject real-world data:

  • User IDs

  • Session tokens

  • Business state

  • Configuration

Common Patterns

Pattern 1: Progressive Data Collection

Pattern 2: API-Then-LLM

Pattern 3: Multi-Step Confirmation

Next Steps

  • Add LLM Integration: Use OpenAI to handle natural language queries

  • Add Error Handling: Create behavior rules for failed API calls

  • Add Validation: Check date formats, availability before booking

  • Add Conversation Memory: Store booking history across conversations

  • Export for Reuse: Export the bot and share with team

Last updated

Was this helpful?