Agent Variables: виды, жизненный цикл и практическое назначение

Agent Variables in Agentforce are the mechanism that turns a “chatty” model into a system that can behave like an enterprise tool. A language model can generate text, but it cannot reliably operate inside business rules unless it is given structured state. Variables provide that state. They represent stable signals about the user, the interaction, and the operational context, and they are the primary way to make an agent consistent, governable, and useful in real processes.

Agentforce variables are commonly grouped into three types: Context variables, Conversation variables, and Custom variables. Each type has its own lifecycle, level of control, and typical use cases, and understanding the differences is essential if you want predictable outcomes.

Context variables are system-provided values that describe the current context and are typically read-only. In Agentforce, they are commonly accessed through the $Context namespace. The key idea is that context variables are not something the agent “makes up.” They are grounded values coming from the platform or the channel environment, such as session metadata, user-related facts, or other runtime attributes that are relevant to decision-making. Because they are read-only, they are safe to treat as authoritative signals. That makes them particularly valuable for deterministic behavior and for enforcing access rules.

Conversation variables exist only inside the current session. They are the agent’s short-term working memory, designed to store what was established during the interaction and should remain available while the session continues. For example, if the user has already chosen a preferred language during the chat, the agent can store it as a conversation variable and continue using it in follow-up messages without asking again. The key constraint is lifecycle: once the session ends, these variables are gone. That makes conversation variables ideal for temporary preferences, intermediate decisions, and state tracking inside a single conversation flow.

Custom variables are created manually by the designer or developer and are defined with an explicit data type. They exist because businesses often have their own signals that do not appear automatically in system context. Custom variables let you model business concepts in a controlled way, such as a customer tier, an escalation flag, a verification status, a confidence score, or a case routing code. Since you define their type, they can be validated and used predictably in rules, inputs, and mappings. Custom variables are frequently used as glue between what the business needs and what the agent must do next.

In practice, variables are used in four main places: filters, instructions, action inputs, and action outputs. This is where variables stop being “metadata” and become operational.

Filters use variables to enforce deterministic access to topics and actions. If determinism means “the same state leads to the same available actions,” then variables are how you describe the state, and filters are how you translate that state into hard constraints. A filter can say, in effect, that a particular topic or action is available only when a variable indicates the correct condition. That condition could be a user’s role, a case status, the current channel, or a priority level. The result is that the reasoning engine does not merely “prefer” the right action; it is only allowed to choose from the actions that filters permit.

Instructions use variables to make responses context-aware without relying on guesswork. Instead of hoping the model infers the right behavior from vague wording, you provide explicit signals. For example, an instruction might tell the agent to respond in the user’s language based on a variable, or to use a more formal tone when the user category requires it, or to avoid certain suggestions when the case status indicates a restricted phase. This improves quality and consistency, but the important point is that instructions remain a softer control than filters. Instructions shape the agent’s behavior inside the allowed boundaries, while filters define the boundaries.

Variables are also used as inputs for actions. This is one of the most practical roles they play. Actions represent real operations such as retrieving an order, creating a case update, generating a refund request, or triggering an internal workflow. Actions need parameters, and variables are the safest way to supply them. When action inputs are driven by variables, the agent becomes more reliable because it uses structured values instead of extracting everything from text each time. This reduces ambiguity and failure modes, especially in multilingual scenarios or messy user messages.

Finally, variables are used as outputs from actions through mapping. When an action returns data, that data can be written into variables, and those variables then become part of the agent’s state. This is how you create multi-step flows that remain consistent across the interaction. The agent can call an action to check an order status, map the returned status into a variable, and then make decisions based on it. It can also reuse the result later without repeating the call. This pattern is essential for building agent behavior that feels like a business process rather than a one-off answer.

A few short business examples show how this works in real scenarios.

First, consider the user’s preferred language. A context variable might indicate the locale provided by the channel, or the language might be inferred and stored as a conversation variable once confirmed. The agent can then use this variable in instructions to ensure every response is consistently in the right language. The same variable can also be used in action inputs, for example when generating a localized email template or retrieving language-specific knowledge articles.

Second, consider the status of an order. A custom variable such as OrderStatus can be populated from an action that looks up the order in a system. Once mapped, filters can enforce correct behavior. If the status is “Delivered,” refund actions might become available only under specific conditions. If the status is “Pending shipment,” the agent might be allowed to update the delivery address, but only until a cutoff stage. The agent’s choices become predictable because the set of available actions is determined by the variable, not by the model’s improvisation.

Third, consider the criticality of a chat. A custom variable such as ChatPriority or EscalationLevel can represent whether the conversation is normal, urgent, or high-risk. That variable can drive filters so that escalation actions become available only when priority is high, and it can drive instructions so the agent uses a more concise, confirmation-heavy style when stakes are higher. It can also influence routing actions, like transferring to a human agent or triggering an incident workflow.

The key point across all examples is that variables are not just storage. They are the agent’s operational state. They enable deterministic control through filters, improve consistency through instructions, provide reliable parameters for actions, and create memory through output mapping. Without them, an agent is forced to rely on raw text and probabilistic inference. With them, the agent becomes a controlled system that can execute business logic.

Next, we will go deeper into Context variables in particular, including how they map from a messaging session and what the syntax and format look like in practice. This is where you learn to treat $Context as a structured contract between the channel and the agent, and to design your filtering and action logic on top of it with confidence.