When to bind an input, and when to leave it Agent Populated

In my previous post about Conversational Email in Marketing Cloud Next, I promised a few more discoveries from the same build. So… here they are!

But let me start with a question - have you ever configured an Agentforce action that had everything it needed, and still watched it fire with empty arguments, or write the same wrong value every time?

My scenario: the subagent had to read which option a customer named in their plain-text reply and write it to a field on the record. Sounds trivial, right? Right…

The lesson?

Whether you bind an action input to a variable or use “Agent Populated” is not a detail - it decides whether the model is even allowed to fill that value.

Three ways it quietly failed

1. I referenced the variable as a “chip” in the Reasoning Instructions. From what I saw in the trace, it rendered as its live value (still empty), so the model literally read something like “…when None is not None…”. Chips seem to substitute the current value, not a symbolic name.

2. I bound the action input to that variable. Once bound, the model can no longer fill it itself - the value has to come from the variable. But nothing ever populated that variable with the interpreted value, so it stayed empty and the tool call went out with empty arguments.

3. I tried to pre-set the value with a chain of Set Variable blocks, one per option. Without a real structural If, they all ran every turn, in order - so the variable landed on the last option no matter what the customer actually wrote.

What finally worked

I set the input to “Agent Populated” and let the model pass the value it parsed straight into the action call. The parsing logic stays in plain text in the instructions, and the model supplies the argument itself. No intermediate variable, no Set Variable, no If/Else.

Bind inputs that come from something deterministic (an action output, a real context variable). Leave anything the model must interpret from free text Agent Populated.

Important note: a chip is perfectly safe when you only want the model to read a variable that has already been set by a previous step - my resolved record Id worked exactly that way. The trap is only referencing a variable inside the instructions meant to set it for the first time.

Small configuration choices can make a huge difference. I hope this post will save you some debugging time.