As an agent engineer, your responsibility is to design the best context for your AI agents.

• Functionality: What operations are possible?
• ML Performance: How accurately does the Reasoning Engine interpret and use your plugin?
• User Clarity: How easy is it for users to understand what happened?
• Latency: How fast does the plugin execute (both execution time and end-to-end user experience)?
• Maintainability: How easy is it to modify or extend?

This guide presents the work backwards methodology: start from your goal and trace dependencies back to their sources. For each architectural decision, you’ll see the tradeoffs explicitly—what you gain, what you sacrifice, and when to choose each approach.

Work Backwards from the Goal

For every plugin:

1. Identify the core action (the “goal” – the final API call)
2. List all input arguments (just list them first)
3. Trace each input to its source:
   • Meta info (current_user, current_date, etc.)
   • User provides (becomes a slot)
   • Another action (trace that action’s inputs recursively)
4. Repeat step 3 for any dependent actions until everything traces to meta info or slots
5. Design slot collection (this is where context engineering decisions happen)

You’re done when: All inputs are either meta info, slots, or outputs from actions whose inputs are meta info/slots.

During slot collection design (step 5), you make critical context engineering decisions. The next section explores these tradeoffs in depth.

Example 1: View Team PTO Requests

Step 1: Identify the Core Action

Core Action: GET /v1/scheduling/employee_timeoff/multi_read

Step 2: List All Input Arguments

First, list every input this action requires:

Step 3: Trace Each Input to Its Source

Now extend the table—where does each input come from?

Key insight: employee_ids comes from another action. That means we’re not done—we need to trace that action’s inputs.

Step 4: Trace Dependent Action(s)

The action that converts user emails to UKG employee IDs:

Action: Convert Users to UKG IDs
API: POST /identity-graph/resolve

List its inputs, then trace them:

Now everything traces to user-provided data!

Complete tracing result for the core action:

All inputs now trace to “User provides” (either directly or through actions). You’re done with backtracing.

Step 5: Design Slots

All user-provided values are now slots:

Now you can configure these slots with the appropriate data types.

Example 2: Get Employee Timesheet

Step 1: Identify the Core Action

Core Action: GET_TIMESHEET

Step 2: List All Input Arguments

Step 3: Trace Each Input to Its Source

Extend the table—where does each input come from?

You’re done with backtracing. No dependent actions needed (skip Step 4)

Step 5: Design Slots

Only one slot needed:

This is where design decisions matter. How do you enforce the constraint?

Implementation Approaches

Approach 1: Slot Description Only

Just describe the constraint in the slot description.

• ❌ UX: No user-facing validation. Relies on the API to throw a 400. Forces the user to “restart”
• ❌ ML Performance: Reasoning Engine might not follow the rule consistently
• ✅ Maintainability: Simplest implementation
• ✅ Latency: Fast – no extra operations

Approach 2: Slot Validation Policy

Add a validation rule using DSL:

1
value.$PARSE_TIME().$ADD_DATE(0, 0, 1).$FORMAT_TIME("%d") == "01" OR
2
value.$PARSE_TIME().$FORMAT_TIME("%d") == "15"

• ✅ UX: Early validation with clear error message
• ✅ ML Performance: Reasoning Engine understands why validation failed
• ✅ Latency: Low latency, no extra actions
• ❌ Maintainability: DSL rule requires maintenance

Approach 3: Generate Structured Value Action

Use two activities in the conversation process: (1) Generate structured value (2) Get timesheet

• ✅ Developer Visibility: Less hidden logic
• ❌ ML Performance: Multiple activities → context bloat
• ❌ Latency: Many LLM extra calls
  1. LLM call from reasoning engine to pick the plugin
  2. LLM call from the action activity
  3. LLM call to parse the outputs from the activity & decide if it should be shown to the user
  4. LLM call to run the timesheet action
  5. LLM call to process the timesheet results

Approach 4: Compound Action Validation

Validate inside a compound action before calling the API.

• ✅ ML Performance: Fully abstract execution from reasoning
• ❌ UX: User sees “processing” with bad input, then retry
• ❌ Latency: Must wait for compound action validation
• ❌ Maintainability: Additional asset to maintain