> ## Documentation Index
> Fetch the complete documentation index at: https://koreai.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# How to handle empty-state and fallback greetings

Use this pattern when startup context may be missing, a branch may not match, or a channel may not deliver proactive welcome content.

## Concept

A fallback greeting is the safe default that prevents the first turn from feeling broken. Fallbacks are needed because startup conditions can fail, channel metadata can be absent, and some delivery contracts suppress proactive startup messages.

In ABL, a top-level `ON_START RESPOND` can act as the fallback when branches do not match. If there is no `ON_START`, the first flow step can be the greeting.

## Minimal working example

```yaml theme={null}
AGENT: Fallback_Greeting_Agent
GOAL: "Recover when startup conditions do not match"

ON_START:
  RESPOND: "Welcome. I can help with service, billing, or returns."
  BRANCHES:
    - IF: session.interaction.current.language == "fr"
      RESPOND: "Bonjour. Je peux vous aider avec le service, la facturation ou les retours."

FLOW:
  entry_point: ready
  steps:
    - ready

ready:
  REASONING: false
  RESPOND: "How can I help?"
  THEN: COMPLETE
```

## How it works

The runtime evaluates the branch. If the language is French, the branch response is selected. If it is not French, the top-level response is used. Because the top-level response is a fallback prelude, the flow can continue into `ready`.

## Common variations

### Start without ON\_START

Use the first flow step as the greeting when the channel or product experience should not send proactive content.

```yaml theme={null}
AGENT: No_Startup_Handler_Agent
GOAL: "Start safely even without a proactive startup response"

FLOW:
  entry_point: first_prompt
  steps:
    - first_prompt

first_prompt:
  REASONING: false
  RESPOND: "Hello. What can I help you with?"
  THEN: COMPLETE
```

## Verification

Test a matching branch, a non-matching branch, and a session without `ON_START`. Confirm every path produces a clear first customer-facing response. In traces, branch misses should not cause an error when a top-level fallback exists.

## Common mistakes

| Mistake                                          | Why it happens                                | How to avoid it                                                               |
| ------------------------------------------------ | --------------------------------------------- | ----------------------------------------------------------------------------- |
| Omitting the generic fallback                    | Branch examples focus on the happy path.      | Add top-level `ON_START RESPOND` or make the first flow step a safe greeting. |
| Personalizing fallback copy with unverified data | Startup metadata may be missing or untrusted. | Keep fallback copy generic until identity and context are known.              |
| Treating a branch miss as an error               | Branches are conditional by design.           | Test branch misses and verify the fallback response.                          |

## Troubleshooting

If no greeting appears, confirm whether the channel suppresses startup payloads. If a malformed branch condition is present, the runtime falls back instead of selecting the broken branch; inspect traces for branch diagnostics.

## Production readiness checklist

* Always define a generic startup or first-flow fallback.
* Keep fallback copy broad enough for unknown users.
* Avoid sensitive personalization in fallback messages.
* Test branch miss and missing-context cases.
* Confirm the no-`ON_START` path still has a useful first flow step.