When I started building AI agents for Business Central scenarios, my initial focus was on making the agents capable. I wanted to explore how AI could help consultants and developers solve real-world Business Central challenges faster and more effectively. The goal was not just to create an agent that could answer questions. I wanted the agent to understand Business Central concepts, analyze problems from a consultant’s perspective, identify possible causes, and provide recommendations that could actually help someone working on a live environment.
Like many developers exploring AI, I spent a lot of time experimenting with different models, prompts, tools, and workflows. I tested different ways of providing information to the agent and observed how small changes in the input could completely change the quality of the response. The early results were promising. The agents could understand questions, process information, and provide answers that were useful. In many cases, they were able to summarize complex information and provide insights much faster than traditional manual analysis. However, after working with different scenarios, I started noticing a pattern. The quality of an AI agent was not only determined by the model behind it. A powerful model does not automatically create a powerful solution. The way we guide the agent, the information we provide, the tools we expose, and the instructions we define have a major impact on the final outcome.
Two agents using the same AI model can behave completely differently depending on how they are designed. One may provide generic answers, while another can behave like a focused Business Central consultant. That realization changed my approach. Instead of only focusing on the AI model, I started spending more time designing the instruction layer of the agent. The instructions became the foundation that defines how the agent thinks, investigates, prioritizes information, and communicates the final response. This is where I started focusing more on instruction design and treating it as an important part of AI solution architecture rather than just a prompt.
The Problem With Traditional Prompts
When we start building AI solutions, the most common approach is to put everything inside the prompt. We define the role of the agent, explain what it should do, provide examples, and add instructions about how we expect the response to look.
For example, a typical prompt may look like:
“You are a Business Central expert. Analyze this issue, identify the root cause, check possible customization impact, and provide a practical recommendation.”
Initially, this approach works well. It is simple, quick, and helps us understand the capabilities of the AI model. However, as the agent becomes more advanced and starts handling multiple scenarios, the prompt naturally continues to grow. Every new requirement adds more instructions. Every new scenario adds more rules. Over time, the prompt becomes a large block of text that needs to be sent repeatedly whenever the agent is used. The challenge is not only maintaining a long prompt. It also impacts efficiency. The agent spends time processing instructions that remain the same instead of focusing completely on the actual business problem.
This made me rethink how I was designing my AI agents. I realized that instructions should not be treated as temporary text inside a prompt. They should become a structured part of the agent design itself.That is where I started moving towards dedicated instruction files and a more organized approach to building Business Central AI agents.
Moving From Prompts to Instruction Files
The biggest change I made was separating the agent’s permanent behavior from the user’s actual request. Initially, I was putting everything inside the prompt, but I realized that the agent’s core instructions should not change every time someone interacts with it.Instead of adding the same explanations repeatedly in conversations, I started creating dedicated instruction files that define how the agent should operate. These files became the foundation of the agent by describing its role, the type of problems it should handle, the investigation approach it should follow, and the expected format of the response.
For example, a Business Central troubleshooting agent should not only understand the error message provided by the user. It should also understand how an experienced consultant approaches troubleshooting. The agent should first understand the issue, identify the impacted area, analyze possible causes, consider whether the problem is related to configuration or customization, and then provide practical next steps.
By moving these rules into a dedicated instruction layer, the conversation becomes much cleaner and more focused. The user can concentrate on explaining the actual business problem instead of repeating how the agent should think.
The agent already understands its role, its process, and the type of response expected. This makes the workflow more consistent and creates a better foundation for scaling AI agents across different Business Central scenarios.
Defining the Agent Role Clearly
One of the first improvements I made was changing how I define the role of the AI agent. When building an agent, it is easy to start with a simple instruction like: “You are a Business Central expert.” While this sounds correct, it leaves many important questions unanswered.
What type of expert should the agent behave like? Should it think like a functional consultant, a technical developer, a support engineer, or an architect?
The difference matters because each role approaches a problem differently.A functional consultant may focus on business processes and configuration. A developer may investigate AL code, extensions, and technical implementation. A support consultant may focus on troubleshooting and identifying the quickest resolution path.
Instead of using a generic role definition, I started making the responsibility much clearer inside the instruction file. For example, a Business Central technical agent should understand AL development, extension architecture, debugging approaches, performance considerations, and common implementation patterns. The clearer the role definition, the better the agent can align its analysis and responses. I found that a well-defined role reduces unnecessary explanations, improves consistency, and helps the agent behave more like the type of consultant we want it to represent.
Teaching the Agent How to Think and Setting Boundaries
Another important lesson I learned was that instructions should not only define what the agent knows, but also how it should approach a problem. Having knowledge alone is not enough. The agent also needs a structured way of thinking when analyzing a real-world Business Central scenario.
For example, when investigating a Business Central error, the agent should not immediately jump to a solution. A good troubleshooting approach starts by understanding the situation. What happened? When did the issue occur? Which process was running? Is the behavior related to standard functionality or a customization? Is there enough information available to provide a reliable recommendation? By defining this investigation process inside the instruction file, the agent starts behaving more like an experienced consultant instead of simply generating a quick response. The instructions guide the agent to analyze the situation step by step before suggesting possible actions.
Another area I started focusing on was defining boundaries and limitations. AI agents are designed to be helpful, but without clear boundaries they may try to fill gaps by making assumptions. In technical scenarios, incorrect assumptions can lead to wrong recommendations. For example, if the agent does not have enough information about a customization or a specific implementation detail, it should identify what information is missing instead of pretending to know the answer.
Good instructions help the agent understand not only when to provide an answer, but also when to ask for additional context. This improves the reliability of the responses and builds more trust when using AI for Business Central consulting and development activities.
Creating Different Instructions for Different Scenarios
While building AI agents, I also realized that one instruction file is not always the right approach. Business Central covers many different areas, and each scenario requires a different way of thinking and analysis.
Error troubleshooting requires a structured investigation approach. Code review requires understanding development patterns, AL best practices, and maintainability concerns. Performance analysis requires focusing on optimization, database interactions, and identifying possible bottlenecks.Trying to combine everything into one large instruction file can make the agent harder to control. The instructions become longer, the context becomes heavier, and the agent may spend time processing information that is not relevant to the current task.
A better approach is creating focused instruction sets based on the purpose of the agent. A code review agent receives guidance around development quality and architecture. A troubleshooting agent focuses on identifying issues and possible root causes. A performance analysis agent focuses on finding optimization opportunities. Each agent receives only the knowledge and guidance it actually needs. This makes the workflow more efficient, easier to maintain, and easier to improve as the solution evolves.
Another improvement I applied was controlling the response structure. Without clear guidance, AI can generate very detailed explanations, but in consulting scenarios, more text does not always mean more value. Developers and consultants usually need clear, actionable information that helps them make decisions quickly. By defining the expected response format inside the instruction file, the agent can provide more consistent results. Instead of a general explanation, the response can focus on the actual problem, possible cause, impact, recommendation, and next steps.
This makes the output easier to review, easier to share with others, and more practical for real Business Central support and development scenarios.
My Biggest Learning
My biggest learning from building AI agents is that creating a successful AI solution is not only about connecting an AI model with data and tools. The real challenge is designing the complete workflow around the agent and making sure every part of that workflow works together effectively. The AI model provides the intelligence, but the instructions provide the direction. Without clear guidance, even a powerful model may produce inconsistent results. A well-designed instruction file helps define how the agent should think, what information it should focus on, how it should analyze a problem, and how it should communicate the final response.
Through this experience, I realized that instruction design can significantly improve consistency, reduce unnecessary processing, and make the agent behave much closer to the way an experienced Business Central consultant approaches a problem. As more organizations start adopting AI agents, I believe instruction design will become an important part of solution architecture. Similar to how we carefully design databases, integrations, and application workflows, AI workflows also need proper architecture.
The future of AI is not only about creating smarter models. It is about creating better-designed agents that understand the task, use the right context, apply the right tools, and deliver meaningful business results.
Leave a Reply