> This page is for Agent Studio.

> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.moveworks.com/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.moveworks.com/_mcp/server.

# Map Data and Context

Agent Studio does not expose one global bag of data. Every action, compound action, resolver, conversation process, and system trigger has a scoped runtime data bank.

Mappings create explicit bridges between those scopes.

## Explore the Data Boundaries

## The Data Bank by Surface

| Surface                           | Commonly available values                                                                          | Boundary                                   |
| --------------------------------- | -------------------------------------------------------------------------------------------------- | ------------------------------------------ |
| HTTP action                       | Typed input arguments, `meta_info.user` in user context, `meta_info.action_instance_id`            | Action response                            |
| Compound action                   | `data.<input_arg>`, earlier step outputs, user metadata only when the caller provides user context | `return.output_mapper`                     |
| Conversation process              | `data.<slot>`, completed activity outputs, `meta_info.user`                                        | Activity output mapping and process result |
| Conversation action output mapper | Current action payload as `response`                                                               | Replaces the exposed activity output       |
| Slot validation                   | Candidate value as `value`, supported user metadata                                                | Valid or invalid policy result             |
| Dynamic resolver                  | Declared inputs and explicitly mapped context                                                      | Exact value or candidate list              |
| Webhook or schedule               | Trigger payload/body and mapped backend outputs                                                    | Action or compound return                  |

> **User Context Is Trigger-Dependent**
>
> `meta_info.user` exists when execution has conversational user context. A webhook or schedule does not automatically have a user profile. Resolve identity explicitly and map it forward.

## Understand the Mapping Layers

### Input Mapping

Input mapping supplies an action activity's typed input arguments from the parent conversation process:

```yaml
feature_request_id: data.selected_feature_request.id
new_status: data.target_status.value
```

It answers: **What does this action receive?**

### Output Mapping

Output mapping reshapes the current action payload, referenced as `response`:

```yaml
feature_request:
  id: response.id
  name: response.name
  status: response.currentStatus
display_instructions_for_model: >-
  Confirm the feature request name and its new status.
```

Unmapped response fields do not remain in the exposed activity output.

It answers: **What does the conversation and reasoning engine receive?**

### Compound Action Input Arguments

A compound action declares typed entry points. Each internal action block uses `input_args` to receive exact values from the compound data bank.

It answers: **What crosses into this backend workflow and each internal step?**

### Compound Action Return

The final `return.output_mapper` creates the compound action's public result:

```yaml
- return:
    output_mapper:
      feature_request:
        id: data.updated_request.id
        name: data.updated_request.name
        status: data.updated_request.currentStatus
```

Intermediate action outputs stay internal unless you return them.

It answers: **What crosses back to the caller?**

## Choose the Right Language

| Need                                                             | Use                           | Why                                          |
| ---------------------------------------------------------------- | ----------------------------- | -------------------------------------------- |
| Insert one scalar into a fixed string                            | Mustache                      | Smallest substitution tool                   |
| Preserve arrays, objects, numbers, or booleans                   | Moveworks Data Mapper         | Structured transformation                    |
| Rename, filter, merge, map, or conditionally include fields      | Moveworks Data Mapper         | Creates a new structured payload             |
| Evaluate a rule or validation                                    | DSL                           | Deterministic boolean or computed expression |
| Apply a DSL function inside a mapping                            | Data Mapper with embedded DSL | Combines structure and computation           |
| Implement complex reusable logic unsuitable for mapping          | Script action                 | Explicit Python execution                    |
| Interpret or extract unstructured language, images, or documents | LLM action                    | Model-based content processing               |

> **Data Mapper, JSON Bender, and DSL**
>
> **Moveworks Data Mapper** is the current teaching term for structured transformations. Existing references may call the underlying mapping system **JSON Bender**. **DSL** is a separate expression language that can run inside mapper fields.

## Replace Outputs Intentionally

An output mapper rewrites the exposed output. It is not an annotation layered over the original response.

If you map:

```yaml
accounts:
  MAP():
    items: response.data
    converter:
      id: item.id
      name: item.name
```

Then downstream steps receive `accounts`, not the original payload plus `accounts`.

Use this behavior to:

* Remove metadata, debug fields, and unused nested objects.
* Rename keys to describe business meaning.
* Normalize inconsistent provider schemas.
* Limit arrays before they enter conversational context.
* Add `display_instructions_for_model` when presentation needs light steering.

## Shape Context for the Reasoning Engine

The reasoning engine sees each output exposed by a conversation action activity. It does not need every API response or internal backend step.

Prefer:

```json
{
  "request_id": "FR-1042",
  "request_name": "Bulk edit requests",
  "new_status": "Planned"
}
```

Avoid:

```json
{
  "lookup_response": {},
  "validation_response": {},
  "patch_response": {},
  "audit_response": {},
  "raw_headers": {}
}
```

When several calls run without user interaction, use a compound action and return one concise object.

## Use Display Instructions as Steering

`display_instructions_for_model` can guide how the assistant presents a result:

```yaml
display_instructions_for_model: >-
  State the feature request name, current status, and product area.
  Do not mention internal record identifiers unless the user asks.
```

Treat this field as presentation guidance, not a deterministic business rule. Use DSL, policies, mappings, or code when a rule must always hold.

## Build Along: Map the PurpleSuite Contracts

Create the explicit bridges for the feature-request build:

1. Map the list action's response array into resolver candidates with `id`, `display_name`, and `current_status`.
2. Map the selected object's stable ID and the static resolver's raw status into the compound action.
3. Return only the updated request's name and status to the conversation.

Use this conversation-to-compound input mapping:

```yaml
feature_request_id: data.selected_feature_request.id
new_status: data.target_status.value
```

Use this conversation activity output mapping:

```yaml
updated_feature_request:
  name: response.feature_request.name
  status: response.feature_request.status
display_instructions_for_model: >-
  Confirm the feature request name and its new status.
```

Inspect the Data Bank at each boundary. Your checkpoint is that the raw list response and internal PATCH and verification responses do not enter conversational context.

## Deep Dives

* [Data Bank](/agent-studio/core-concepts/data-bank)
* [Conversation Process Data Bank](/agent-studio/conversation-process/plugin-process-data-bank)
* [Action Activities](/agent-studio/conversation-process/activities)
* [Common DSL and Mapper Patterns](/agent-studio/configuration-languages/common-patterns)
* [Data Mapper Reference](/agent-studio/core-platform/configuration-languages/moveworks-bender-language-reference)
* [DSL Reference](/agent-studio/core-platform/configuration-languages/moveworks-dsl-reference)
* [Plugin Responses](/agent-studio/conversation-process/activities/plugin-responses)

Next, [collect slots and resolve values](/agent-studio/guides/plugin-building-masterclass/collect-slots-and-resolve-values).