The AI Knowledge Base Agent: How It Turns Calls, Tickets and Documents into SOPs in Odoo and MYOB Acumatica

An AI knowledge base agent reads call transcripts, helpdesk tickets and documents, and drafts standard operating procedures, FAQ articles and training notes into Odoo 19 Knowledge or your MYOB Acumatica team’s procedure library. A named process owner approves every article before staff or a support agent can rely on it. Odoo 19 ships voice transcription and article generation today; MYOB Acumatica ships AI Automation prompts as at September 2026.

At a glance

• Who it is for: owners, operations managers and finance leads at businesses of 15 to 200 staff where the way things are done lives in three people’s heads, a folder of 2019 Word documents and a helpdesk queue.
• Problem it solves: the person who knows how to release a credit hold, process a warranty return or close the month goes on leave, and the procedure goes with them.
• Platforms: Odoo 19 Enterprise (Knowledge, Helpdesk, Documents and the AI app); MYOB Acumatica 2025.2 and 2026.1 (AI Automation prompts and the AI Assistant); transcripts from your phone or video-call platform.
• Trigger: a weekly run over the tickets, calls and notes tagged as procedure-worthy, plus an on-demand run when a person tags a thread “turn this into an SOP”.
• Inputs read: resolved helpdesk tickets and their chatter, meeting and call transcripts, existing procedure documents, the record types and screen names involved, and the current version of any article it is updating.
• Systems: the ERP’s own knowledge tool, the helpdesk, the document store, and the model provider your policy allows (Odoo 19 supports OpenAI and Gemini; MYOB Acumatica uses a MYOB-managed model or your own Azure, Bedrock, OpenAI or Anthropic connection).
• What the agent drafts: a procedure with numbered steps, the screen or form each step happens on, the exceptions seen in the source tickets, a short FAQ, and a diff against the previous version when one exists.
• Approval gate: a named process owner reviews the draft, corrects it and publishes it; until then the article is private to the owner and the agent, and no support agent can cite it.
• Audit trail: the source tickets and transcripts linked from the article, the article’s version history, who approved which version, and the model call log.
• Typical cycle time: a first draft of a procedure from 10 to 20 source tickets in minutes; the owner’s review is the real cost, typically 20 to 40 minutes per procedure in our runs, with a review date set on publish.
• What it never does: publish an article, change access rights, delete a previous version, or send anything to staff or customers.
• Typical cost: a scoped agent pilot typically starts from a few thousand dollars ex GST for discovery and sandbox build, per our AI agents for ERP in Australia page.
• Typical timeline: 4 to 10 weeks from discovery to a drafts-first go-live per the same page; the built-in Odoo 19 features can be switched on the same day.
• Last verified: 15 September 2026 against the Odoo 19 AI agents documentation, the Odoo 19 voice transcription documentation and MYOB’s AI Automation documentation.

The returns process at a Queensland equipment distributor we work with existed in exactly one place: the head of a service coordinator who had done it for six years. When she took long service leave, the two people covering her spent the first week asking the helpdesk queue how she’d handled each case, because the tickets were the only written record. The Word document in the shared drive described a version of the process from before the ERP went in.

That’s the problem an AI knowledge base agent is for. Not writing a wiki nobody reads, but turning the record you already have, tickets, calls, chatter, into procedures a person can check and staff can find. This guide covers what the agent reads, what it drafts, what Odoo 19 and MYOB Acumatica ship for it today, and why the process owner’s approval is the whole design.

What is an AI knowledge base agent?

An AI knowledge base agent is software that reads the unstructured record of how your business does things, call and meeting transcripts, resolved helpdesk tickets, emails, old procedure documents, and drafts structured articles from it: standard operating procedures (SOPs), FAQ entries and training notes. It writes drafts into your knowledge tool. It does not publish them. A named process owner reads each draft, fixes what the agent got wrong, and publishes it, which is the same drafts-first pattern behind every one of the AI agents for ERP in Australia we build.

The distinction from a general-purpose chatbot matters. A chatbot answers a question once and forgets it. A knowledge base agent produces an artefact that lives in the ERP, has a version history, has an owner and a review date, and then becomes a source the other agents in your business can be restricted to. Get this one right and the service triage agent answers from your procedures instead of from the model’s general knowledge.

What does the agent read, and what does it draft?

Three kinds of input, each with a different quality problem.

• Helpdesk tickets and chatter. The richest source and the messiest. A resolved ticket shows what was asked, what was tried and what worked, but ten tickets about the same procedure will describe it ten ways. The agent’s job is to find the common steps and list the variations as exceptions, not to pick one ticket and call it the process.
• Call and meeting transcripts. Handover calls, training sessions, the weekly ops meeting. Odoo 19 can transcribe a meeting recorded in a record’s notes or a Knowledge article and generate a summary of decisions and action items, and the audio is discarded once the transcript exists, per the voice transcription documentation. Transcripts from your phone or video-call platform work the same way once they’re in the document store. The call logging agent covers the recording side.
• Existing documents. The 2019 Word file, the PDF the previous consultant left, the checklist taped to a monitor. Usually partly wrong. The agent reads them as evidence of intent, then checks each step against what the tickets show people actually do.

From those it drafts one procedure at a time: a title, who owns it, numbered steps with the screen or form each happens on, the exceptions seen in the sources with a note on how each was handled, a three-question FAQ, and, when it’s updating an existing article, a diff showing what changed and which source justified the change. Every draft cites its sources by ticket number or transcript date, so the reviewer can check a step in thirty seconds instead of trusting it.

A worked example: the returns procedure

Back to the distributor. Here’s how the agent handled the service coordinator’s returns process, and where the person earned their keep. As always, details are changed and combined across engagements so nobody is identifiable.

The agent read 14 resolved returns tickets from the previous quarter, the transcript of a 40-minute handover call recorded in Odoo before the leave started, and the old Word document. It drafted a nine-step procedure: log the return against the original sales order, check the warranty date on the lot, raise the return picking, inspect and record the fault code, and so on through credit note or replacement, with four exceptions (no serial number on the original invoice, return outside warranty, damaged in freight, customer wants a swap not a credit) pulled from specific tickets. The draft went into a private Knowledge article visible only to the process owner and the agent’s user.

The owner’s review took 35 minutes and made two corrections that matter. Step six said “the system automatically issues the credit note once the return is validated”. It doesn’t; a person posts it, and the ticket the agent cited described the coordinator doing exactly that. The agent had turned a human step into a system step, which is the most common error we see in this pattern and the most dangerous, because an SOP that says the system does something is an SOP nobody checks. The second correction was a screen name from the Word document that hasn’t existed since the version upgrade. The agent had trusted the document over the tickets.

After the corrections the owner published the article to the service team, locked it against casual edits, and set a review date three months out. The article then became a source for the service triage agent, with the agent’s Restrict to Sources option switched on so it answers returns questions from the approved procedure only. Two weeks later, the covering staff were closing returns tickets from the article without asking the queue.

What do Odoo 19 and MYOB Acumatica ship for this today?

More than most people expect, and less than the announcements suggest. Everything in the table was checked against vendor documentation on 15 September 2026.

Two Odoo details are worth pulling out. The agents documentation is explicit that an agent with no topics can only provide information, not change data, and that Restrict to Sources limits it to the uploaded, active sources. That’s the switch that turns a knowledge base from a document store into a control. And the support workflows documentation says the quiet part plainly: the quality of the sources directly determines the quality of the responses. Which is the whole argument for having a person approve the sources.

On the MYOB side, the useful primitive is the AI Automation prompt attached to a form. MYOB’s own data masking example is a prompt that generates closure notes for a support case with the owner and business account masked, which is a knowledge base agent’s first step in miniature. The prompt library has the pattern; the approval step is yours to add. What MYOB Acumatica ships and what remains a global Acumatica announcement is covered in our MYOB Acumatica AI guide, and the platform’s built-in features in Odoo are in AI in Odoo.

Why must a person approve every SOP?

Because a wrong procedure is worse than no procedure. Nobody follows a missing SOP; everybody follows a published one.

The failure modes are specific. The agent turns a human step into a system step, as above. It promotes one person’s workaround into policy because that person wrote the most tickets. It carries a tax treatment forward from an old document: a returns SOP that says to credit the GST on a return that was originally GST-free replicates a Business Activity Statement (BAS) error across every person who follows it. It describes the screen as it was two versions ago. None of these are rare, and none of them are visible in a fluent, confident draft.

The approval gate is therefore not a review of tone. The process owner checks three things: that each step is what a person does today, that any step touching tax codes, pricing, stock or customer money is marked as a human action, and that the exceptions are real. Then they publish, lock, and set a review date. When the model provider retires the model, which MYOB warns can happen with little notice, the approved articles are unaffected. That’s the point of writing them down.

“The agent’s draft is a witness statement, not the verdict. It tells the process owner what the tickets say happened. The owner decides what the procedure is, and their name goes on it. Skip that and you’ve automated the spread of your worst habit.”

Bill Alvarez, Practice Manager, Auboros

What about privacy and recording the calls?

Three questions to settle before the first transcript goes anywhere.

First, recording. Whether you can record a call is governed by state and territory listening-device laws, and they differ. Queensland’s Invasion of Privacy Act 1971 lets a party to a conversation record it; New South Wales’ Surveillance Devices Act 2007 is stricter, and every jurisdiction restricts what you can do with a recording afterwards. Tell people the call is recorded, keep it to internal handover and training calls until you’ve had advice, and don’t feed customer calls in without it.

Second, what the model sees. A handover call transcript contains staff names, customer names and sometimes account details. Under the Australian Privacy Principles you need a reason to collect and use that personal information, and the OAIC’s guidance on commercially available AI products is the place to start. In MYOB Acumatica, mask the fields the model doesn’t need. In Odoo, scope the agent’s sources to the tickets and transcripts the procedure requires, and remember that on Odoo Online the model calls go to OpenAI or Gemini under Odoo’s keys unless you supply your own, per the API keys documentation.

Third, who can read the result. An SOP for releasing credit holds is not something the warehouse needs. Odoo Knowledge’s access rights and Members only visibility handle that per article; in MYOB Acumatica the prompt runs under the user’s own role. Record which agent produced which article in your agent register, so the December 2026 privacy policy disclosure has an accurate list to draw on. The wider controls are in our AI agent governance guide.

How we run this ourselves

We’d be cautious about anyone selling this pattern who doesn’t use it. Our own content and QA pipeline runs on scheduled agents, and the operating rules those agents follow live in a learnings file that an agent appends to at the end of every run: what broke, what a source turned out to say, which rule changed. A person reads the additions and edits the standing rules. When a run goes wrong, the fix is a line in that file, approved by Josh or Bill, and the next run reads it. It’s the same loop as the returns procedure above, with a different subject, and it has been running since July.

The two lessons from running it are the two we now build into every client version. Make the agent cite the source for each step, because an uncited draft can’t be reviewed in the time an owner actually has. And date every article, because a procedure with no review date is a procedure that’s wrong and doesn’t know it yet.

Goes well with

• AI agents for ERP in Australia: which operational agent to point at the approved knowledge base first, and what a scoped pilot costs.
• The AI service triage agent: what happens once the procedures exist, an agent that sorts enquiries and drafts replies from your approved articles only.
• The AI call logging agent: where the transcripts come from, Australia’s recording rules in more depth, and who approves each note.

Losing procedures every time someone goes on leave?

Auboros builds drafts-first AI agents over Odoo and MYOB Acumatica from Brisbane, and a knowledge base agent is often the first one we recommend, because every other agent gets better once your procedures are written down and approved. If you want to see what it would draft from your own tickets, book a free consultation. We’ll run it against a sample and let you judge the draft yourself.