For the complete documentation index, see llms.txt. This page is also available as Markdown.

Context variables

Overview

Agentic workflows rely on context to maintain continuity across Actions, API calls, AI Agent reasoning, and user interactions.

Unlike traditional request-response architectures, Agentic systems operate as evolving conversations where information collected in one step may influence decisions many steps later.

Context provides the shared memory layer that makes this possible.

Every Action execution can contribute information to the conversation, allowing the AI Agent to reason not only about the current request, but also about previously collected data, execution outcomes, and business information accumulated throughout the interaction.

The purpose of context is not simply to store data.

Its purpose is to preserve information that helps the AI Agent understand what happened, what is currently known, and what should happen next.

Understanding the Agentic memory model

Before working with Context Variables, it is important to understand how memory flows through an Agentic system.

A typical execution follows the lifecycle below:

At each stage, information may be created, enriched, reused, or updated. Context Variables are the mechanism used to carry this information throughout the conversation. If you want to learn more about all the supported variables in Syntphony CAI, check here as well.

Context types

Not all information stored in the Context serves the same purpose. Some information represents an Action request, other information represents the outcome of an Action execution, and some should remain available throughout the entire conversation.

To support these different responsibilities, Agentic workflows use three primary context structures (they work together to create a complete execution cycle):

Context variable
Purpose

hiddenContext._eva.api.agentic.functionRequest

Describes what should be executed.

hiddenContext._eva.api.agentic.functionResult

Describes what happened after execution.

hiddenContext._eva.api.agentic.userData

Stores contextual information that should remain available during the conversation.

Context Variables references

Agentic Variables

Description

Where

hiddenContext._ eva.api.agentic.functionRequest

Internal structure used to prepare and pass parameters required to execute an Action. It represents the execution intent before the Action is performed.

hiddenContext._ eva.api.agentic.functionResult

Stores the resolution of an Action execution. Rather than acting as a simple API response container, it provides execution context to the AI Agent, describing what happened during the Action and enabling the AI Agent to determine the next conversational step.

hiddenContext._ eva.api.agentic.userData

Stores contextual information that should remain available throughout the conversation. This information can include customer attributes, business information, external knowledge, API responses, or any additional context that may support future reasoning.

These variables create a dynamic memory system that preserves information across AI Agent interactions. By properly structuring Code cells to read from and write to these context objects, sophisticated workflows can be built, where each Action builds on previously collected information.

Understanding the contexts

functionRequest

functionRequest represents the Action that the AI Agent intends to execute. Before an Action is executed, the necessary information must be organized and prepared. This structure acts as the execution contract between the AI Agent and the Action.

Example:

At this stage:

  • No Action has been executed;

  • No result exists yet;

  • And the structure only describes what should happen next.


functionResult

functionResult stores the resolution of an Action execution. Its primary responsibility is not persistence, but to provide execution context back to the AI Agent.

Once an Action finishes, the AI Agent must understand:

  • Whether the Action succeeded;

  • Whether the Action failed;

  • Which business outcome was produced;

  • Which information became available;

  • And what should happen next.

functionResult acts as the execution contract returned after the Action completes.

Example (customer identification):

An Action attempts to identify a customer:

The value of this structure is not the boolean itself. It is the context it provides to the AI Agent. The Agent can now reason:

  • Customer identified → Continue customer-specific flow; OR

  • Customer not identified → Request additional information.

Example (business outcome):

The AI Agent now understands:

  • Which Action was executed;

  • Whether the execution succeeded;

  • And which information became available after execution.


userData

userData represents persistent contextual memory. Unlike functionResult, which describes the outcome of a specific execution, userData stores information that may be useful throughout the conversation.

Information stored in userData remains available to future Actions, Code cells, Service cells, and AI Agent reasoning processes.

Common examples

Typical examples can include:

  • Customer attributes;

  • Account information;

  • Contract information;

  • Subscription information;

  • Eligibility information;

  • Preferences.

userData is not limited to customer information

A common misconception is that userData should only contain customer attributes. This is not a system requirement. Any information that should remain available throughout the conversation may be stored in userData.

Example: Product catalog

Suppose an Action retrieves a list of available products:

The returned products are not customer information. However, they may still be useful for future reasoning. In this scenario, the information can be persisted as contextual knowledge.

This allows the AI Agent to reference the product catalog later without performing another Action execution.

The same principle can be applied to:

  • Service catalogs;

  • Available plans;

  • Installation information;

  • Eligibility rules;

  • Business metadata;

  • External knowledge relevant to the conversation.

Simplifying context access

Using aliases

The complete context path can become difficult to read when reused across multiple Actions. For instance:

For readability and maintainability, developers may expose simplified aliases. For instance:

Instead of repeatedly accessing a deeply nested structure, the same information can be accessed directly.

Another practical example

Action collects:

Stored as:

Using an alias, this becomes:

Why use aliases?

Aliases help:

  • Reduce complexity;

  • Improve readability;

  • Simplify debugging;

  • Improve reuse across Actions;

  • Reduce deeply nested references.

Success scenario

What happens during a successful Action execution

A successful execution generates two independent but complementary outcomes:

  • Execution outcome: The Action returns a resolution through functionResult;

  • Persistent context: Relevant information may be persisted through userData or custom context variables for future use.

Execution lifecycle

Step 1: User request

I want to check my internet balance.

Step 2: AI Agent selects an Action

The AI Agent determines that the check_balance Action should be executed.

Step 3: Parameters are collected

All values collected by the Action may remain available for future executions:

Step 4: functionRequest is created

Step 5: REST execution

The request is executed.

Step 6: functionResult is created

Step 7: Context enrichment

Additional information may be persisted.

Step 8: Agent reasoning

Following the cycle, the AI Agent now has access to:

  • Action parameters;

  • functionResult;

  • userData;

  • Previously stored context.

The AI Agent uses this information to decide the next conversational step.

Combining functionResult and userData

The same execution can leverage both structures. For instance:

This allows the AI Agent to reason using:

  • Execution outcomes;

  • Persistent context;

  • Previously collected information.

Error handling

Errors are also Action outcomes. For this reason, errors should be represented through the same execution context structure used for successful executions.

The AI Agent reasons over both outcomes in a consistent way.

Example: Business error

Example: Validation error

Agent reasoning after an error

The purpose of the error is not only to report a failure, but to provide context for the next decision. For instance:

1

Action executed

2

Error returned

3

functionResult updated

4

AI Agent reasons over outcome

5

Recovery strategy selected

Depending on the outcome, the AI Agent may:

  • Request additional information;

  • Retry an Action;

  • Suggest an alternative path;

  • Escalate to another Agent;

  • Inform the user about the issue.

Final guidelines

When designing and building Agentic workflows, consider:

Use it when:

  • Describing what should be executed;

  • Passing parameters to an Action;

  • Preparing REST requests.

Avoid context pollution

Do not persist information that has no future value. Store only information that contributes to future:

  • Decisions;

  • Actions;

  • Reasoning.

A well-designed context should maximize usefulness while minimizing unnecessary memory.

Last updated

Was this helpful?