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

# Context and variables

> Pass call data into a workflow and use it in prompts and tools.

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:

```json theme={null}
{
  "initial_context": {
    "customer_name": "Sam Example",
    "case_reference": "CASE-EXAMPLE-001"
  }
}
```

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:

```json theme={null}
{
  "case": {
    "reference": "{{initial_context.case_reference}}"
  },
  "caller": {
    "name": "{{initial_context.customer_name}}"
  }
}
```

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](https://docs.tryopencomputer.com/guides/tools.md).

## 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.

## Set default template variables

Open the agent's **Settings → Template Variables**. Under **Add New Variable**, enter **Key** and **Value**, add it to the current variables, and choose **Save Variables**. Use a key such as `company_name` and a matching prompt placeholder such as `{{company_name}}`. Review current variables to edit or remove a default.

Save and test the draft, then publish. Call-level context, pre-call enrichment, and values gathered during the call are separate sources; inspect the actual run before assuming a default won a collision. For explicit integration references, use the appropriate `initial_context` or `gathered_context` path. Structured extraction is configured on supported nodes in [Workflow builder](https://docs.tryopencomputer.com/guides/workflow-builder.md#extract-structured-values).

## Set up a pre-call lookup

1. Edit **Start Call** on the canvas and set **Pre-Call Data Fetch** to **Always**, **Inbound calls only**, or **Outbound calls only**. Use **Disabled** to skip it.
2. Enter **Endpoint URL** for your hosted lookup service and select **Authentication** if required.
3. Make the service accept Athena's POST request and return the context envelope shown below. The request's `call_inbound` object includes `agent_id`, `from_number`, and `to_number`, with `workflow_run_id` when available. The event name remains `call_inbound` even when an outbound-mode lookup uses it.
4. Save and test the matching call direction using synthetic account data. Check the receiver request, returned values in the run, and rendered greeting. Publish after verification.

Example receiver response:

```json theme={null}
{
  "initial_context": {
    "customer_name": "Sam Example",
    "case_reference": "CASE-EXAMPLE-001"
  }
}
```

The response can also wrap `initial_context` inside `call_inbound`. The legacy `dynamic_variables` key is accepted, but use `initial_context` for a new integration. The lookup has a 10-second request timeout. A failed or invalid lookup can leave enrichment unavailable rather than stopping the whole call, so make your prompt handle missing values. Do not use this lookup as your only authorization check or assume it runs for a direction excluded by the selected mode.

A pre-call response can also contain a validated `model_overrides` envelope for the services owned by the agent visit: LLM, its fallback policy, and TTS. It cannot change the already-built call mode, STT, realtime service, embeddings, or whole named configuration through this hook. Use call-request overrides before initialization when you need a supported request-level configuration selection. See [Call API](https://docs.tryopencomputer.com/guides/calls.md#choose-a-model-configuration-for-one-call).


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