AI Agent Generates SQL but Stops Executing After 2nd Query

Questions
,
1

Hello everyone,

I’m trying to build a workflow with the AI agent node, Ollama, and PostgreSQL.
Everything goes well for the first two questions that need to generate an SQL query. But on the third question that needs data from the database, Ollama generates the SQL query correctly but stops and doesn’t execute it on the GetData node.

Please share your workflow

Information on your n8n setup

  • n8n version: 2.21.5
  • Database (default: SQLite): SQLIte
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via : Docker
  • Operating system: Linux
2

@flipflip , can you try this?

3

Hi @flipflip

I think the cause is your numPredict: 1024 setting on the Ollama node. That limits the model’s response to 1024 tokens per turn. After 2 queries, your conversation history (tool calls, results, table structures) grows, and the model runs out of output tokens before it can finish generating the tool call.

Two things to try:

  1. Increase numPredict to at least 4096 in the Ollama node options.

  2. Reduce contextWindowLength on your Postgres Chat Memory from 20 to something like 5-10. Each message includes full tool call results, so 20 messages eats through your 16384 context window fast.

Combine those with @kjooleng system prompt changes and it should get past the 3rd query.

Let us know if this helps !

4

@flipflip

check if this works for you:
GitLab MCP Server.json (5,0 KB)

5

Two things worth checking: first, look at the AI Agent node settings and check the “Max Iterations” value - Ollama models sometimes exhaust the iteration budget after processing 2 tool calls, which would explain the agent generating the SQL but not following through on the GetData call. Bump it up to 15-20 and test.

Second, check how your PostgreSQL node is wired as a tool. If it’s using the “Execute Query” operation and the SQL is passed via an expression like {{ $fromAI('query') }}, make sure the field name in fromAI matches exactly what the agent is outputting. A mismatch there causes the tool to run but return nothing, and Ollama quietly stops rather than retrying.

6

The most likely culprit here is that qwen3:14b doesn’t reliably output a proper tool call after generating the SQL. The AI Agent node waits for the LLM to return a structured tool call — if the model just writes the SQL as plain text and stops, the agent never triggers the getData node. It sees no tool call, considers the task done, and returns an empty response.

A few things to try, in order:

  1. Enable intermediate steps temporarily. In the Agent node, turn on “Return Intermediate Steps.” Rerun the same third question. You’ll see exactly what the agent did — whether it called getData and with what query, or if it just stopped after generating SQL text. That tells you immediately where the disconnect is.
  2. Check your system prompt. If it’s just a placeholder “My prompt,” the agent doesn’t know it must use the getData tool for every data request. Add something explicit:
    “Whenever the user asks a question that requires data from the database, you must call the ‘getData’ tool with the appropriate SQL query. Do not output SQL directly; always use the tool.”
  3. Try a function-calling-capable model. qwen3:14b may not have native function-calling support in Ollama, so the agent falls back to a text-based parser that’s fragile. Swap in llama3.1:8b-instruct or mistral:7b-instruct (both confirmed to work with tool calls via Ollama) and test if the third query executes. If it does, the model was the problem.
  4. Increase numPredict or remove the limit. Your numPredict is 1024 tokens. If the SQL query plus the tool-call syntax exceeds that, the model might get cut off before emitting the final } that signals a tool call. Set numPredict to -1 (unlimited) or bump it to 4096.
  5. Check Postgres memory consumption. While unlikely to cause a hard stop at exactly the 2nd query, a long memory window can clutter the context and confuse the model. Temporarily set contextWindowLength to 5 and test. If the third query works then, you can tune it back up.

Start with #1 and #3 — those are the fastest to rule out. If you see in the intermediate steps that the agent never calls the tool, it’s a model output issue. Let us know what you find.

7

Hello everyone,

with the suggestions from @kjooleng and @houda_ben, I managed to fix the problem. For now, I haven’t encountered the issue again despite 10 questions requiring a mix of memory and database queries. Of course, I significantly enriched the base prompt to integrate my constraints and requirements.

Thank you all for your help.