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

# Update state

> Plan how conversation values should change and use existing placeholder or assignment configuration without inventing a built-in state tool.

A state update would change values used during a conversation, such as a selected product or a completed verification step. Define who owns each value and which action is allowed to change it before designing that behavior.

<Note>
  `update_state` is not an accepted built-in tool type in the current API. Do not add that type to an agent or assume a state-update callback exists. This page covers preparation and adjacent authoring features.
</Note>

## Separate the kinds of state

| Need | Existing configuration or ownership |
| - | - |
| Example values in an authored prompt | Agent [dynamic-variable placeholders](/agents-platform/configure/personalization/dynamic-variables). |
| Requested extraction from a tool result | A tool definition's `assignments` list. |
| A customer record or transaction | The application service that owns and authorizes that record. |
| Changes to the agent itself | The [agent draft and version workflow](/agents-platform/deploy/versioning). |

Changing a placeholder edits example configuration. It is not a live customer-data update. Changing an agent draft is also separate from changing values inside an active conversation.

## Prepare a tool-result assignment

The current assignment contract includes:

| Field | Authoring meaning |
| - | - |
| `source` | Only `response` is accepted. |
| `dynamic_variable` | Name of the variable intended to receive a value. |
| `value_path` | Dot-notation path such as `record.status` or `items.0.id`. |
| `sanitize` | Requested removal of the assigned value from model and transcript output; defaults to `false`. |
| `preserve_native_type` | Requested preservation of the extracted type; defaults to `false`. |

These fields describe assignment intent. They do not establish that live assignment or sanitization is implemented. Do not treat `sanitize: true` as verified protection for a sensitive value.

<Steps>
  <Step title="Define the value and source">
    Choose a non-secret variable name and an actual response field from a reviewed tool contract. Record the expected type and what should happen when the field is missing.
  </Step>

  <Step title="Review the definition">
    Use the supported [tool configuration workflow](/agents-platform/configure/tools/overview) to inspect or author assignments. Keep reserved platform names and credentials out of general-purpose variable slots.
  </Step>

  <Step title="Inspect stored configuration">
    Reopen the tool and check the assignment path and destination name. Keep live assignment testing pending until the relevant execution path is available.
  </Step>
</Steps>

## Frequently asked questions

<AccordionGroup>
  <Accordion title="Can I mark a customer as verified with a placeholder?" id="faq-update-state-verification">
    A placeholder cannot perform identity verification or grant access. The service responsible for that decision must establish and enforce it.
  </Accordion>

  <Accordion title="Do assignments update my database?" id="faq-update-state-database">
    No database write is established by this configuration. Durable business changes belong to a separately authorized service action.
  </Accordion>
</AccordionGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.