Skip to main content
What are Objectives? Objectives are evaluation prompts that guide a conversation toward concrete outcomes and let an evaluator LLM determine completion and extract structured variables. They influence both the conversational LLM (what to work toward) and the evaluator (what to verify and extract).This guide is a deep dive on best practices for structuring your objectives. For basic setup, parameters, and API details, see the main Objectives documentation:

How the System Works

Tavus uses two LLM roles during a conversation:
  • Conversational LLM: talks to the user and steers toward completing objectives.
  • Evaluator LLM: checks completion status and extracts variables from conversation history.
Your objective_prompt influences both:
  • It is injected into the conversational behavior (what to gather and confirm).
  • It is used by the evaluator to decide completion and extraction quality.
That means prompt clarity directly affects both conversation quality and workflow correctness.

What Good Prompts Look Like

Good objective prompts are:
  • Clear: unambiguous and concrete
  • Specific: one goal at a time
  • Testable: easy to validate with sample conversations
  • Robust: handle real user variation and edge cases

Objective Prompt Template

[Action] [specific information or condition] [optional criteria] Examples:
  • Collect the user's first name, last name, and email address
  • User has explicitly agreed to the terms and conditions
  • Check if an error message is visible on shared screen and extract error code

Objective Types

1) Information Extraction Objectives

Use when you need structured data.
Avoid:
Why bad: vague prompt + vague variable.

2) Condition Check Objectives

Use when a verifiable condition must be true before proceeding.
Avoid subjective checks:

3) Visual Objectives

Use for camera or screen-share analysis.
Tip: visual prompts should describe clear, observable signals, not interpretation-heavy judgments.

Output Variables Best Practices

Naming

Good variable names:
  • first_name, last_name
  • preferred_contact_method
  • appointment_date, appointment_time
  • reason_for_visit
Bad variable names:
  • info, data, thing1, user_response

Granularity

Prefer atomic fields over one giant blob. Good:
Less useful:

NOTFOUND

If a value is missing, evaluator may return "NOTFOUND". That is expected. Do not put NOTFOUND handling instructions inside objective prompts. Handle it in app logic.

Conditional Objectives

Use conditional objectives to route a workflow.
Guidelines:
  • Prefer 2-5 branches.
  • Keep branch conditions distinct.
  • Include a catch-all path.
  • Base conditions on conversation content (not hidden database state).

Common Mistakes (and Fixes)

1) Writing instructions instead of outcomes

Bad:
Good:

2) Future-state checks

Bad:
Good:

3) Overloaded objectives

Bad: one objective collects 15 unrelated fields. Good: split into focused objectives (get_name, get_contact, get_address).

4) Overlapping conditional branches

Bad:
Reason this is bad: paths are not distinct enough and can overlap, so both conditions may match the same user message. Good:

Testing Checklist

Before shipping prompts:
  • Test one-message answers (user gives everything at once)
  • Test multi-turn collection (piece by piece)
  • Test corrections (Actually, it's Jon not John)
  • Test refusal cases (I'd rather not share that)
  • Test ambiguity cases (Sometime next week)
  • Track variable-level NOTFOUND rates in production
Simple test fixture example:

Example Blueprint (Support Triage)


Final Guidance

Start simple, ship, observe, and iterate. Strong prompts should make objective completion predictable, extraction reliable, and debugging straightforward.