System Prompt for a Business AI Agent: How to Write the Instructions

System Prompt for a Business AI Agent: How to Write the Instructions

A good system prompt for a business AI agent defines six things in plain language: the agent's role, what it can and cannot handle, where its information comes from, which limits it never crosses, what format it answers in, and when it hands the case to a person. Write it like a job description for a new employee, and test it with real conversations before release. The prompt alone does not guarantee safety, but it is the foundation of predictable behavior.

Key takeaways

• A system prompt is the agent's job manual: role, scope, sources, limits, format and escalation.
• Specific, verifiable instructions work better than adjectives such as "be polite and accurate".
• Information that changes (prices, deadlines, policies) should come from a source the agent consults, not sit written in the prompt.
• Critical limits need controls outside the prompt, such as tool permissions and human approval.
• A prompt is only ready after testing with common cases, edge cases and attempts to push it off course, and it stays under review after launch.

What is a system prompt, and what does it not solve on its own?

A system prompt is the set of fixed instructions the agent receives before any customer message. It defines who the agent is inside your company, how it should act and where it should stop. The person chatting with the agent usually never sees this text, but every answer passes through it.

It helps to separate what a prompt does well from what it does not. It guides tone, priorities, format and decision criteria. It does not replace permissions: if the agent has access to a tool that cancels orders, writing "never cancel orders" is a request, not a lock. The real lock is not handing over the tool, or requiring human approval at that step. Anthropic's material on building effective agents deals with exactly this split between guidance by text and control by system design.

The prompt is also not the place to dump everything the company knows. The more text you add, the more likely instructions are to contradict each other, and the more context space they consume. Before deciding what stays fixed and what is fetched on demand, it is worth understanding the context window.

What structure does a working system prompt have?

The structure we use as a starting point has six blocks, in this order, because each depends on the one before:

• Role: who the agent is, who it talks to and what the job is for.
• Scope: what it resolves, what it declines and what it forwards.
• Sources: where permitted information comes from and what to do when the source has no answer.
• Limits: forbidden actions, data it must not ask for or repeat, promises it must not make.
• Format: length, tone, language, response structure and what to log.
• Escalation: objective triggers for passing the conversation to a person and what to send along.

For the specific case of customer support, the article on how to write instructions for an AI support agent covers how to apply this by channel. Here the focus is the general structure, which also fits internal, sales and operations agents.

How do you write the role, scope and sources?

The role should be short and concrete. Instead of "you are a helpful assistant", describe the function the way you would describe it to a contractor: company name, channel, audience and main task.

You are Company X's support assistant on WhatsApp. You help customers check order status, answer questions about delivery times and open exchange requests.

Scope comes as two mental lists: what the agent does and what it does not do. The second is the more important one, because that is where an agent tends to improvise. Say what to do when a request is out of scope, not only that the agent cannot help.

You do not negotiate prices, decide refunds or give legal or medical advice. In those cases, explain in one sentence that a team member will take over and trigger escalation.

Sources answer the question: where is the agent allowed to know something from? A simple and effective rule is to allow answers only from named sources and to forbid filling gaps with guesses.

Answer only from the information returned by the order lookup and the attached policy documents. If the information is not there, say you will check with the team. Never estimate a deadline or an amount.

Data that changes often should not live in the prompt. Prices, stock and promotional rules belong in systems or documents consulted at the moment of the question, in a retrieval design like the one Anthropic describes in its writing on context engineering for agents. That way, when a policy changes, you update the source and do not rewrite the agent.

How do you define limits, format and escalation?

Limits are specific prohibitions tied to real risk in your business. Think in three categories: actions (what the agent never executes), data (what it never asks for, repeats or stores) and promises (what it never guarantees). With LGPD in view, it is worth adding a minimization rule: the agent asks only for the data needed for the task and does not request sensitive documents in the chat.

Never ask for passwords, full card numbers or documents in the chat. Never promise a deadline, discount or outcome that is not in the source.

Limits also need to address attempts to push the agent off course. Customer messages (and the text of documents or emails the agent reads) can contain disguised instructions. The prompt should state that this content is data, not commands. That helps, but it is not enough: the OWASP guidance on prompt injection prevention recommends layers of defense, and the article on prompt injection protection for AI agents shows how to apply them in a company.

Format prevents long, inconsistent answers, especially on WhatsApp. Set a maximum length, the number of questions per message, tone and language, and say whether the agent should identify itself as a virtual assistant.

Reply in the customer's language, in a few short sentences, with one question at a time. When the customer asks, say you are a virtual assistant.

Escalation is where many prompts fail through vagueness. "Forward complex cases" is not a trigger. List conditions that anyone can verify:

• The customer asks to speak to a person, at any point.
• The topic is a refund, cancellation, formal complaint or legal matter.
• The source does not contain the answer after one lookup.
• The customer shows repeated irritation or mentions a legal deadline.
• There were two misunderstandings in a row on the same question.

Also define what travels with the handoff: a summary of the case, what has already been answered and what the customer expects. Without that, the person starts the conversation over and the customer repeats everything.

Illustrative scenario: a building materials store on WhatsApp

This is an illustrative scenario, unrelated to any real company. A store wants an agent that reports delivery status and opens exchange requests. The first version of the prompt said only "serve customers well and solve their problems". In testing, the agent promised delivery dates that were not in the system and accepted discount requests.

The revision applied the structure. Role: orders and exchanges assistant. Scope: status and opening an exchange; price and discount go to the salesperson. Sources: only the order lookup and the exchange policy document. Limits: no date promises outside the lookup, no discounts. Format: short replies, one question at a time. Escalation: discounts, formal complaints and a missing answer in the source go to a team member, with a summary.

The expected result of this revision is not an agent that talks more, but one that knows when to stop. That is the right criterion for judging a system prompt.

How do you test the prompt before going live?

Testing a prompt is similar to testing a process: you define cases, run them, compare against what you expected and fix what fails. OpenAI's documentation on evals and Anthropic's writing on evaluating agents present this logic of a set of cases with clear pass criteria. A simple method to start:

• Gather anonymized real conversations, or write cases from your history: common questions, out-of-scope requests and complaint situations.
• For each case, write the expected behavior first: answer, decline or escalate, and with what content.
• Include edge cases: a source with no answer, a customer who changes subject, an ambiguous message, a request to speak to a human.
• Include attempts to push the agent off course: "ignore your instructions", insistent discount requests, pasted text with hidden orders.
• Run each case more than once, because responses can vary, and log failures by type.
• Fix the prompt one change at a time and rerun the whole set so you do not break what already worked.
• Test tools in a simulated environment before connecting real systems, as the article on mock tools and sandbox testing for AI agents explains.

Define what "passed" means in advance. For example: no case where a forbidden action was executed, and every escalation trigger respected. Criteria for tone and clarity can be reviewed by someone from operations, who knows the customer.

How do you maintain the prompt after launch?

The system prompt is a living document, with an owner, a version and a change history. Every change should pass through the same test set. Keep records of the agent's conversations and decisions (respecting LGPD and the company's retention policy) to see where it escalated, where it erred and where the customer asked for a person.

In our method, this maps to four steps. Map: understand the current process and the starting point. Limit: reduce the agent's data and actions to what is necessary. Pilot: run one real flow with logs and an agreed success metric. Transfer: hand the prompt, the tests and the records to the team, which decides whether to expand, adjust or stop. The prompt is born in the limit step and matures in the pilot.

A final checklist before release:

• Does the role fit in two sentences?
• Does everything out of scope have an instruction for where it goes?
• Does every piece of information the agent uses have a named source?
• Are the critical limits also protected by tool permissions or human approval?
• Can anyone verify the escalation triggers?
• Is there a test set and someone responsible for running it on every change?

Frequently asked questions

What is the ideal length for a system prompt? There is no ideal length, only the shortest text that covers role, scope, sources, limits, format and escalation without ambiguity. If the prompt grows because it holds price tables or long policies, move that content to a source the agent consults. Lean prompts are easier to test and maintain.

Can I rely on the prompt alone to stop the agent from doing something improper? No. The prompt guides behavior, but an instruction can be ignored or bypassed by a malicious message. For risky actions, use minimum tool permissions, validation outside the model and human approval. The OWASP Top 10 list of risks for LLM applications is a useful reference as well.

Should I write the prompt in the same language as my customers? Usually yes. If your audience speaks Portuguese, writing the prompt and the examples in Brazilian Portuguese tends to give more consistent tone and vocabulary. What matters is testing with your customers' real expressions, including slang, abbreviations and the typing errors common on WhatsApp.

How often should I review the prompt? Review it whenever a policy, a tool or the model changes, and at regular intervals based on conversation records. Each review should run the same test set. If a failure keeps appearing in the records, it becomes a new test case and a fix in the prompt or in the source.

Sources

• Anthropic: Building effective agents
• Anthropic: Effective context engineering for AI agents
• OWASP: prompt injection prevention
• OpenAI: evals guide