How to Make AI NPCs Act on What They Say

A character who says "Follow me, I'll show you the gate" and then stands still is worse than one who never spoke. Players expect AI NPCs to do what they say. This guide shows how to turn AI dialogue into gameplay actions safely: the character decides what fits the conversation, and your game decides what actually happens.

Why keyword matching fails

The first approach most people try is reading the reply for words like "follow" or "here you go", then triggering the matching action. It breaks quickly:

• The character says "Come along" instead of "follow me", and nothing happens.
• It says "I won't give you the key", and the word "give" hands it over.
• It mentions an item that doesn't exist, and your code throws an error.

The reliable pattern is structured output: the model returns its chosen actions as data, separate from the words, and only from a list you define.

The three parts of an action system

1. A fixed list of actions

Decide what the character can do: FOLLOW, GO_TO, GIVE_ITEM, OPEN_DOOR, ATTACK. In Neocortex you add each one as an Action node on the character in the editor, with a short description of when to use it. The character can't invent a new one.

2. What the character can see

The character needs to know what is in the scene to act on it. Send the nearby objects with the request as entities, each with a stable id:

{
  "characterIds": ["GUARD_ID"],
  "message": "Can you open the gate for me?",
  "metadata": [
    { "id": "gate-north", "name": "North Gate", "properties": [{ "name": "state", "value": "closed" }] },
    { "id": "player", "name": "Traveller", "properties": [{ "name": "carrying", "value": "royal seal" }] }
  ]
}

Each entity can have a position and up to 16 properties, and a request can carry up to 40 of them. Send what matters for this moment, not the whole level.

3. Actions back as data

The reply holds the spoken lines and, separately, the actions:

"actions": [
  { "name": "OPEN_DOOR", "targetId": "gate-north" }
]

targetId always matches one of the ids you sent, or is empty for actions that need no target. The character can't point at something that isn't there. The Unity and Godot SDKs send nearby objects for you, so in an engine you rarely build this JSON by hand.

Your code decides what runs

An action is a request, not a command. Before running it, check it against the game state:

• Is it allowed? OPEN_DOOR on the north gate only if the player carries the seal.
• Is it possible? The target still exists and is in range.
• Is it timed right? Play the line first, then start the action, so the guard says "Stand back" before the gate moves.

If the check fails, skip the action and let the conversation continue. The character might say "Let me open it" while your code keeps the gate shut because the seal is fake. Write the character to expect that, so it can react naturally on the next turn when you send an event like "The gate stayed shut".

Moving targets

For anything that moves, look up the live object by its id when the action arrives instead of trusting a position from the request. The player may have walked away while the reply was being written.

Making actions feel natural

• Pair actions with emotion. Every Neocortex line carries an emotion tag. A guard who opens the gate ANNOYED should look annoyed doing it.
• Use few, broad actions. GO_TO with a target beats ten actions like GO_TO_MARKET and GO_TO_GATE.
• Describe when to use each one. "Only give an item after the player pays" in the Action node's description keeps the character from handing out loot for a compliment.
• Let the story drive big moments. For quest-critical steps, combine actions with a Conversation Flow so the scene reaches its checkpoints in order.

Actions in your engine

The action list belongs to the character, so the same guard works everywhere. Each engine SDK receives actions alongside the reply:

• Unity: RegisterAction connects each action to a coroutine, and Neocortex Interactable components tell the character what is nearby. The Unity tutorial shows both.
• Unreal Engine: the reply carries the action keyword, and the interactable it targets comes back marked Is Subject in the reply's metadata. See how to add AI NPCs to Unreal Engine 5 for the Blueprint side.
• Godot: register_action takes a handler per keyword, and NeocortexInteractable nodes mark what the character can see. See how to add AI NPC dialogue in Godot 4.
• Web: the website tutorial registers a handler per action in a few lines.

Common mistakes

• Trusting the model with game state. The reply can ask for GIVE_ITEM, but only your inventory code knows whether the item exists.
• Too many actions. Each one is something the character must choose between. Start with three or four.
• Silent failures. When your code refuses an action, tell the character through an event so its next line makes sense.

Next steps

Actions are the strongest defence against players talking characters into things, so read how to keep AI NPCs in character next. For the full picture, browse the guide to building AI NPCs, and see the interactables docs for every field.

Frequently Asked Questions