When you configure an agent in Azure AI Foundry (or any agent framework), the instructions become part of the system prompt – the persistent context the LLM receives with every single conversation turn. They shape:<\/p>\n\n\n\n
- \n
- How the agent understands its role<\/li>\n\n\n\n
- What constraints it operates within<\/li>\n\n\n\n
- How it handles ambiguous situations<\/li>\n\n\n\n
- What tone and format it uses when responding<\/li>\n\n\n\n
- When it should ask for clarification vs. proceed<\/li>\n<\/ul>\n\n\n\n
Think of it as the onboarding document you’d write for a new, very literal-minded employee who follows instructions exactly as written.<\/p>\n\n\n\n
<\/p>\n\n\n\n
A Real Example: Travel Booking Agent<\/strong>
<\/p>\n\n\n\nWeak instructions: <\/strong>You are a travel booking assistant. Help users book travel.<\/p>\n\n\n\n
Strong instructions:<\/strong> You are a travel booking and expense management assistant
designed to help employees plan, book, and manage business
travel. Always confirm trip dates and budget before making bookings.
Prefer direct flights when the cost difference is less than 20%
compared to connecting flights. Never book accommodation outside approved vendor list.
If the user’s request exceeds their allocated travel budget,
flag this explicitly before proceeding and ask for manager
approval confirmation.<\/p>\n\n\n\nSame agent. Same model. Same tools. Completely different behaviour – and completely different risk profile for the business.<\/p>\n\n\n\n
The Four Elements of Strong Instructions<\/strong>
After writing (and debugging) a lot of agent configurations, I’ve settled on four elements that every instruction set needs:<\/p>\n\n\n\n![\"\"](\"\/wp-content\/uploads\/2026\/04\/image-7-1024x555.png\")
<\/figure>\n\n\n\nElement 1: Role<\/strong>
This seems obvious, but the specificity matters. “You are a customer service assistant” is not a role. A role includes context about the business, the user base, and the purpose.
– Weak: You are a customer service assistant.<\/em>
– Strong: You are the first-line support assistant for a SaaS platform (subscription management and billing). You interact with small business owners who have limited technical knowledge. Your primary goal is to resolve billing queries, subscription changes, and account access issues without escalating to a human agent when possible.<\/em>
The LLM uses that context to calibrate every response – the vocabulary it uses, how much it explains, what it treats as in-scope.<\/p>\n\n\n\nElement 2: Behaviour<\/strong>
This is about operational style. How does the agent communicate? What does it do first? How does it format responses?
Examples of useful behavioural instructions:<\/p>\n\n\n\n- \n
- Always summarise the action you’re about to take before taking it.<\/li>\n\n\n\n
- Use bullet points for lists of more than three items.<\/li>\n\n\n\n
- If the user seems frustrated, acknowledge their frustration before proceeding.<\/li>\n\n\n\n
- Respond in the same language the user writes in.<\/li>\n\n\n\n
- Never provide legal or medical advice – redirect to appropriate professionals.<\/li>\n<\/ul>\n\n\n\n
These aren’t constraints (Element 3) – they’re style and process guidelines. The distinction matters because you’ll edit them for different reasons.<\/p>\n\n\n\n
Element 3: Constraints<\/strong>
This is the safety layer. Constraints are things the agent must never do, or must always check before doing.<\/p>\n\n\n\n![\"\"](\"\/wp-content\/uploads\/2026\/04\/image-8-1024x526.png\")
<\/figure>\n\n\n\nI’d argue constraints are where the security posture of your agent lives. A missing constraint is an attack surface.<\/strong> You can see agents manipulated into revealing information they shouldn’t because nobody write “never disclose internal pricing structures to users outside the enterprise network”.<\/p>\n\n\n\n
Element 4: Handling Ambiguity<\/strong>
This one is underrated. What does your agent do when it doesn’t have enough information to proceed confidently?
Options to specify:<\/p>\n\n\n\n- \n
- Ask for clarification – If the user’s request is ambiguous, ask one clarifying question before proceeding.<\/li>\n\n\n\n
- State assumptions – If information is missing, state the assumption you’re making before acting on it.<\/li>\n\n\n\n
- Escalate – If you cannot resolve the issue within three attempts, offer to connect the user with a human agent.<\/li>\n\n\n\n
- Decline gracefully – If the request is outside your scope, explain what you can help with instead.<\/li>\n<\/ul>\n\n\n\n
Without this guidance, agents tend to make up the missing information or proceed with false confidence. Both are worse than asking a clarifying question.<\/p>\n\n\n\n
Common Mistakes<\/strong><\/p>\n\n\n\n
- \n
- Instructions that are too short
Two sentences is not a system prompt. The LLM needs enough context to handle the full range of scenarios your users will throw at it.<\/em><\/li>\n\n\n\n- Contradictory instructions
“Be concise” and “always provide a detailed explanation” in the same prompt creates unpredictable behaviour. Review for internal consistency.<\/em><\/li>\n\n\n\n- No failure handling
If a tool call fails, what should the agent do? If the user’s request is clearly malicious, how should it respond? Silence on edge cases means the model makes its own decisions.<\/em><\/li>\n\n\n\n- Instructions that describe desired output instead of behaviour
“Give excellent responses” is not an instruction. “Always provide three concrete examples when explaining a technical concept” is.<\/em><\/li>\n\n\n\n- Never testing adversarial inputs
Write your instructions, then try to break them. Ask the agent to do something outside its scope. Provide contradictory information. Try to get it to ignore its constraints. If it breaks, your instructions aren’t done yet.<\/em><\/li>\n<\/ol>\n\n\n\nPros and Cons of Instruction-Heavy Configuration<\/strong>
Pros:<\/strong><\/p>\n\n\n\n- \n
- No code changes needed to alter agent behaviour – just update instructions<\/li>\n\n\n\n
- Accessible to non-developers (product owners, domain experts can contribute)<\/li>\n\n\n\n
- Fast iteration cycle – change, test, observe<\/li>\n\n\n\n
- Audit trail if you store instructions in version control<\/li>\n<\/ul>\n\n\n\n
Cons:<\/strong><\/p>\n\n\n\n
- \n
- LLMs don’t follow instructions with 100% consistency – you need testing<\/li>\n\n\n\n
- Complex constraints can conflict with each other in unpredictable ways<\/li>\n\n\n\n
- Very long instruction sets can consume significant context window tokens<\/li>\n\n\n\n
- Requires domain expertise – you need to know what the agent should do before you can write it down<\/li>\n<\/ul>\n\n\n\n
My Framework for Writing Instructions<\/strong>
I use this process whenever I’m building a new agent:<\/em><\/p>\n\n\n\n- \n
- Start with the user journey – what does the user want to accomplish?<\/li>\n\n\n\n
- Map the failure modes – what are the five worst things this agent could do?<\/li>\n\n\n\n
- Write the role – one paragraph, specific and contextual<\/li>\n\n\n\n
- Write the constraints first – safety before capability<\/li>\n\n\n\n
- Add behaviour guidelines – style, format, escalation paths<\/li>\n\n\n\n
- Specify ambiguity handling – what does it do when unsure?<\/li>\n\n\n\n
- Test with ten real scenarios – including at least three edge cases<\/li>\n\n\n\n
- Iterate – treat instructions as a living document<\/li>\n<\/ul>\n\n\n\n
The instructions you write on day one are not the instructions you’ll run in production. That’s normal. The discipline is in the iteration.<\/p>\n\n\n\n
In the next article, I’ll cover tools – the other half of the agent equation. Because even perfect instructions can’t make an agent useful if it doesn’t have access to the right actions.<\/p>\n","protected":false},"excerpt":{"rendered":"
Here’s a pattern I’ve seen repeated across dozens of AI projects: teams spend weeks selecting the right model, configuring the infrastructure, setting up integrations – and then write the agent instructions in about ten minutes.Then they’re surprised when the agent behaves inconsistently.The instructions field isn’t a formality. It’s the most important configuration decision you’ll make. […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/bogdanburuiana.com\/index.php\/wp-json\/wp\/v2\/posts\/1480"}],"collection":[{"href":"https:\/\/bogdanburuiana.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/bogdanburuiana.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/bogdanburuiana.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/bogdanburuiana.com\/index.php\/wp-json\/wp\/v2\/comments?post=1480"}],"version-history":[{"count":3,"href":"https:\/\/bogdanburuiana.com\/index.php\/wp-json\/wp\/v2\/posts\/1480\/revisions"}],"predecessor-version":[{"id":1485,"href":"https:\/\/bogdanburuiana.com\/index.php\/wp-json\/wp\/v2\/posts\/1480\/revisions\/1485"}],"wp:attachment":[{"href":"https:\/\/bogdanburuiana.com\/index.php\/wp-json\/wp\/v2\/media?parent=1480"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/bogdanburuiana.com\/index.php\/wp-json\/wp\/v2\/categories?post=1480"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/bogdanburuiana.com\/index.php\/wp-json\/wp\/v2\/tags?post=1480"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- Contradictory instructions
- Instructions that are too short