What you're seeing
It usually looks like this. You send a PUT to the agent with a new personality, goal and instructions. It returns 200. A GET on the agent shows all three fields with your new text. And the bot keeps answering with the old rules, the old offer and the old links.
We've hit exactly this in our own builds: the three fields came back updated while fullPrompt still held the earlier version, word for word.
Why it happens
HighLevel's update reference says it directly: when fullPrompt has text in it, that text overrides personality, goal and instructions during generation. The separate fields are still stored and still returned, but once fullPrompt is filled, it is what the bot works from.
So the API isn't lying when it returns 200. The fields you sent were saved. They just aren't the ones in charge.
The separate fields can look right while the bot reads something else. Check fullPrompt.
The fix, step by step
Two reads and one write on the same agent ID, then a test in the app.
- Read the agent with GET /conversation-ai/agents/{agentId} using the conversation-ai.readonly scope, and put its fullPrompt beside its personality, goal and instructions. If fullPrompt holds the old text, you've found the cause.
- Write out the complete prompt you want the bot to follow, made from your new personality, goal and instructions.
- Send PUT /conversation-ai/agents/{agentId} with the conversation-ai.write scope, including that complete text as fullPrompt, a string, in the same request as the three fields.
- Use the Version header the update reference shows. It was v3 when we checked.
- Read the agent again and compare fullPrompt with what you sent. Ignore the separate fields for this check.
- Test the bot in HighLevel with a message that touches the part you changed.
Rather have it set up for you?
We'd write and load your Conversation AI prompts, read each one back and test the bot before it talks to anyone, starting with a 30-minute 1:1 with Rob.
Checking the change actually landed
Two checks, and you need both. The first is the read-back: fullPrompt on the agent should match your new text. The second is behavior: in HighLevel, open the bot from the Agents List and send it a test message about the thing you changed, such as the new offer or the rule you added.
If the read-back doesn't match, the update didn't carry fullPrompt, and the bot is still on the previous text.
We can't point you to a documented format for joining the three parts into fullPrompt, so keep yours plain and use the same layout across every agent you manage. That makes the read-back easy to compare by eye.
Fields you can read but can't write
A GET response is not a template for a PUT. knowledgeBaseTriggers is a good example: it appears in the agent's response, but it isn't part of the documented update body, and in our builds a PUT that included it was refused.
Build each update from HighLevel's update schema, sending only the fields it lists, rather than editing a GET response and sending it back whole. It keeps you clear of fields the endpoint won't accept, and it makes plain which fields your code means to change.