Skip to main content
Context carries task-specific values into a workflow. Use it to provide information that the agent needs for a conversation, such as a synthetic customer name or case reference. Keep the keys aligned with the workflow instructions and templates. For a call-trigger request, initial_context can look like this:
The workflow can refer to a value with {{initial_context.customer_name}}. Values gathered during the conversation are available under gathered_context in the templates and outputs that support them. Define the expected keys in the workflow and use a controlled test to make sure values reach the intended node.

​
Use values in an HTTP tool

An HTTP tool can use parameters supplied by the model or presets configured by your team. A body_template can place these values in nested objects or arrays. If a template value consists of one placeholder, its original JSON type is preserved; combining a placeholder with surrounding text produces text. For example, {{initial_context.priority}} can remain a number when it is the entire value, while Case {{initial_context.case_reference}} becomes text. For example, a tool can send a structured request like:
With no body template, POST, PUT, and PATCH send resolved parameters as a flat object. GET and DELETE place them in query parameters. body_format selects JSON or form encoding where the method uses a body. For setup and test details, see Tools and knowledge.

​
Website visitor context

The generated website widget can pass visitor context through its data-dograh-context attribute. Keep the generated attribute name and snippet intact so it continues to match the widget integration. Use synthetic visitor data during setup. Browser-supplied context is untrusted input. Do not include backend credentials, private account data, or authorization decisions in it. Validate any value used by an external service on your backend, and do not treat a value supplied by the visitor as proof of identity or permission.