2 min read

Set the system prompt first, not the model

Set the system prompt first, not the model

The moment I watched the agent stall

I had just deployed AgentForge on a fresh Ubuntu server. Docker Compose pulled, containers started, the web UI loaded in my browser. Everything looked fine on the surface.

I typed a test message in Telegram: What is the status of ticket 4023? The agent responded with a generic answer about how it could help with tickets, but no real action. It asked for more details. I gave them. It asked again. Five messages later I had nothing useful.

A familiar pattern

This happened at 1it.pro when we first rolled out an internal support agent for our own ops team. We spun up the instance, connected it to Telegram, and expected it to triage Slack alerts and update Jira tickets. Instead, the agent spent two days saying things like "I can help you with that" and then doing nothing.

The team got frustrated. They stopped using it. The agent sat idle.

The real problem was not the model

I assumed the issue was LLM selection. Maybe GPT-4 was too slow. Maybe Claude was too cautious. I switched models twice. Same behavior.

The real problem was that I had not told the agent who it was, what tools it had, and what to do when it did not have an answer. The system prompt was the default boilerplate from the AgentForge template. It said "You are a helpful assistant" — and that is exactly what we got: a helpful assistant that chatted forever and never acted.

Why this costs you time and money

Every vague answer from an agent means a human has to step in and redo the work. In a sales follow-up workflow, that is a lost lead. In support automation, that is a longer ticket lifecycle. In internal operations, that is your team ignoring the tool.

If the first interaction is bad, nobody gives it a second chance.

What I changed in AgentForge

I opened the web UI, went to the agent settings, and edited one field: the system prompt.

I replaced the generic text with a 5-line instruction set:

  • 🎯 Tell the agent its exact role ("You are a support dispatcher for the internal ops team".)
  • 📋 List the specific tools it must use first ("Always query the Jira connector before asking the user".)
  • 🔁 Set a fallback behavior ("If you cannot resolve in 2 steps, tag the on-call engineer".)
  • 🚫 Ban open-ended questions ("Do not ask 'How can I help?' Start with the data you already have".)
  • ✅ Set a single output format ("Every answer must begin with either an action or a direct answer".)

I did not touch any other setting. No embedding chunk size. No temperature. No model swap.

A good system prompt replaces ten rounds of conversation with one decision.

What happened after

The first message I sent in Telegram after the change: What is the status of ticket 4023? The agent replied with the ticket status, the assignee, and the last update time. No follow-up questions. No chatter.

Within two hours, two other team members started using the agent unprompted. By the end of the first week, the agent was handling 40% of the initial triage without human intervention.

The fix did not require a bigger model or more infrastructure. It required one specific instruction about how to behave when the trigger arrives.

AgentForge

AI agents for real work. If you want to see how this works in practice, visit our product site and blog.

Share
Serhii

Serhii