I have launched Q on KursiCopilot.no – a knowledge agent designed to make it easier to find relevant, source-grounded answers about Microsoft Copilot, courses and practical use. The technology is interesting, but the work began elsewhere: with the need, the information flow and what the user should actually be able to accomplish.
What should Q help with?
Kurs i Copilot contains guidance, course information and professional content for several audiences and situations. The challenge is not necessarily a lack of content. It is often finding the right content quickly enough – and understanding what is relevant in your own working day.
Q is designed to close this gap. Users can ask a specific question, receive a concise answer grounded in controlled sources and choose whether to explore the topic in more depth. Where appropriate, Q can also point them to a course, a guide or a conversation.
The workflow came before the technology
I did not begin with the question ‘which model should I use?’. I described the workflow first:
- What is the visitor trying to accomplish?
- Which sources should Q be allowed to use?
- When should the agent ask a clarifying question?
- How concise should the first answer be?
- When is it appropriate to suggest a next step?
- What should Q do when the sources are not sufficient?
This made it easier to separate the user experience from the technology underneath. The model is an important part of the solution, but whether the agent is genuinely useful depends on how the instructions, knowledge base, interface and governance work together.
Controlled knowledge instead of unconstrained answers
Q is not meant to answer anything and everything. It first retrieves relevant information from a defined knowledge layer containing content from Kurs i Copilot, Naviqon and approved professional sources. The language model then receives the source context together with clear instructions for how to formulate the answer.
This is a common pattern for source-grounded knowledge agents. It does not eliminate all uncertainty, but it provides more control than allowing the model to rely on general knowledge alone. Time-sensitive information must be retrieved afresh from authoritative sources, and Q should say so when the evidence is insufficient.
A generic pattern – and a pragmatic implementation
The architecture below shows the flow from question to answer and onward action. It is not tied to one particular platform. The same pattern can be implemented with different tools, provided that sources, instructions, access, logging and follow-up are treated as parts of a single workflow.
Architecture for a controlled knowledge agent
A generic solution pattern for source-grounded answers and meeting booking
Visitor
Asks a question or uses a quick choice on kursicopilot.no.
Website and knowledge agent
Manages the dialogue, access boundaries and logging.
Controlled knowledge layer
Finds a limited number of relevant sources before the model responds.
Language model
Uses the instructions and the retrieved source context.
Answer and next step
Provides a concise answer or a deeper explanation. An action can start booking or follow-up.
The current solution uses GPT-5.6 Terra to formulate the answers. Terra is available through the OpenAI API and was chosen because it offers a good balance of quality, speed and cost for this type of focused dialogue. The model choice alone does not make the answers better; the controlled context and clearly defined task do most of the work.
Why I chose this combination
I wanted a solution that could be launched pragmatically, adjusted quickly and still provide control over content, cost and next steps. I therefore separated it into four layers:
- The interface makes it easy to ask questions and choose a direction.
- The knowledge layer defines which sources the answers should be based on.
- The language model formulates the answer in a natural and varied way.
- The governance layer sets boundaries for dialogue, cost, logging and subsequent action.
This separation also makes it easier to replace components later. The knowledge base and workflow retain their value regardless of which model or platform is used.
Control and cost are part of the solution
An agent that is inexpensive per answer can still become costly if it retrieves too much context or allows conversations to grow without limits. Cost control is therefore part of the architecture, not an afterthought.
For Q, this includes a limited number of sources per answer, concise initial responses, a cap on clarifying questions and logging that makes it possible to monitor usage. The same governance also improves the user experience: less noise, clearer answers and a faster path to relevant content.
Copilot Studio is a natural alternative
The overall pattern can also be built in Microsoft Copilot Studio. For organisations already working in Microsoft 365, Power Platform and Azure, this can be a very natural choice – particularly when the agent needs to use organisational data, permissions and workflows in the Microsoft ecosystem.
As of 13 September 2026, GPT-5.6 Terra is available in Microsoft Foundry, but Microsoft does not document Terra as a directly available primary model in Copilot Studio. Current support for bring your own model in prompts does not include the GPT-5 family either. Using Terra from Copilot Studio today would therefore require a separate REST or API integration, for which the platform provides established integration options.
The choice should therefore be based on the workflow, data sources, governance and where the agent will meet the user – not on the model name alone.
Launch now – improve as we learn
Q has been launched as a first version. The solution is useful enough to put into use, but it is not finished in the sense of being static. Real questions can now reveal which formulations work, where the knowledge base has gaps and which next steps users actually want.
I will pay particular attention to questions that do not receive good enough answers, whether Q uses the right level of detail and how often a conversation should lead to a course, guidance or contact. Improvements will therefore be based on actual use – not assumptions alone.
Q as a case in Kurs i Copilot
Q will also serve as a practical case in Kurs i Copilot. The aim is not merely to demonstrate a chatbot, but to make agent development easier to understand: from needs and information architecture to source selection, instructions, governance and continuous improvement.
This is where I believe many organisations should begin. A good knowledge agent is less about placing ‘AI’ on top of a website and more about making a defined workflow simpler, safer and more useful.
Try Q
Visit KursiCopilot.no and ask Q a question about Microsoft Copilot, courses or practical use.
Does your organisation have a workflow or knowledge need that might be suitable for an agent? Contact Naviqon for an informal, no-obligation conversation.