The Golden Rule

Never execute two action-based activities in a row in a conversation process without collecting a slot in between.

That’s the rule. If you remember one thing from this page, remember that. Every other best practice in Agent Studio is downstream of this principle.

Why This Rule Exists

Every action activity in a conversation process returns output that gets added to the reasoning engine’s context window. That output stays in the window for the rest of the conversation. The engine reads all of it on every subsequent turn to decide what to say and do next.

Chain two actions back-to-back, and both outputs sit in the window. Chain four, and you have four full API responses competing for the engine’s limited attention budget.

Here’s what happens:

The reasoning engine processes the entire context window on every turn. More tokens means more computation and more latency. But the performance hit isn’t just about speed.

The Lost in the Middle Problem

The reasoning engine doesn’t read the context window with equal attention everywhere. Research shows that attention follows a U-shaped curve: strong at the beginning, strong at the end, weak in the middle.

When you chain three actions:

• Action 1’s output sits near the beginning of the action history. Decent attention.
• Action 2’s output lands in the middle. Weak attention — roughly 20% recall.
• Action 3’s output is near the end. Decent attention.

The engine is literally more likely to hallucinate about the second action’s data than the first or third. You’ll see it pick the wrong field, misinterpret a value, or ignore the data entirely. And the bugs are hard to trace because they look like random reasoning failures, not positional attention problems.

What a Violation Looks Like

Here’s a meeting scheduler plugin that chains four action activities. Each action depends on the previous one’s output, and all four responses dump into the context window.

1
# Conversation Process: schedule_meeting
2
activities:
3
  - action_activity:
4
      action_name: lookup_user_calendar
5
      required_slots: [organizer]
6
      input_mapper:
7
        user_id: data.organizer.id
8
      output_key: calendar_info
9
10
  - action_activity:  # Action right after action
11
      action_name: fetch_room_list
12
      input_mapper:
13
        building: data.calendar_info.default_building
14
      output_key: rooms
15
16
  - action_activity:  # And another
17
      action_name: check_room_capacity
18
      input_mapper:
19
        rooms: data.rooms.available
20
        headcount: data.attendees.$LENGTH()
21
      output_key: suitable_rooms
22
23
  - action_activity:  # And another
24
      action_name: reserve_room_and_create_event
25
      input_mapper:
26
        room: data.suitable_rooms[0]
27
        attendees: data.attendees

Four actions chained. Each returns 2-5 KB. The reasoning engine’s context balloons to 20 KB+ of intermediate data it doesn’t need. Response time goes from 2s to 8s. The user stares at a spinner.

The Fix: Compound Actions

Compound actions move the chain out of the conversation process. The intermediate results stay outside the context window entirely. The reasoning engine only sees the final, clean output.

1
# Compound Action: prepare_meeting_room
2
steps:
3
  - action:
4
      action_name: lookup_user_calendar
5
      input_mapper:
6
        user_id: data.organizer.id
7
      output_key: calendar_info
8
9
  - action:
10
      action_name: fetch_room_list
11
      input_mapper:
12
        building: data.calendar_info.default_building
13
      output_key: rooms
14
15
  - action:
16
      action_name: check_room_capacity
17
      input_mapper:
18
        rooms: data.rooms.available
19
        headcount: data.headcount
20
      output_key: suitable_rooms
21
22
  - return:
23
      output_mapper:
24
        recommended_room: data.suitable_rooms[0].name
25
        room_capacity: data.suitable_rooms[0].capacity
26
        alternatives_count: data.suitable_rooms.$LENGTH() - 1

1
# Conversation Process - Clean
2
activities:
3
  - action_activity:
4
      action_name: prepare_meeting_room
5
      required_slots: [organizer, attendees]
6
      output_key: room_prep
7
      confirmation_policy: true
8
9
  - action_activity:
10
      action_name: create_calendar_event
11
      required_slots: [meeting_title, meeting_start_time, duration_minutes]
12
      input_mapper:
13
        title: data.meeting_title
14
        room: data.room_prep.recommended_room
15
        attendees: data.attendees
16
      output_key: created_event
17
      confirmation_policy: true

The Role of confirmation_policy

Notice confirmation_policy: true on both action activities above. This gives the user a checkpoint — they see the result and confirm before the action fires. It’s useful when you want the user to verify data before the process continues (e.g., “I found Room 4A with capacity for 8. Want me to book it?”).

The slot barrier itself comes from required_slots. When the next action activity has required slots, the engine has to stop and collect them before proceeding. That’s the natural breakpoint that satisfies the Golden Rule.

Rule of Thumb

If your conversation process has two action activities back-to-back, refactor. Move the chain into a compound action, use return with an output_mapper to curate the fields the reasoning engine actually needs, and add confirmation_policy between action groups.

The context window is a finite resource. Treat it like one.