After GMP Agent Training, I Built an Auditable Pipeline with WorkBuddy

Title: After watching the GMP Agent training, I built a traceable deviation ledger using Dify

Recently, I came across a training session held in Shanghai from September 10 to 12, focused on building your own GMP agent using WorkBuddy. I quickly checked it out and couldn't help but chuckle—many teams have overly naive expectations of AI, thinking that just by throwing an SOP into it, the AI will automatically ensure compliance. GMP (Good Manufacturing Practice for pharmaceuticals) is all about traceability, which is the real challenge.

I've been using WorkBuddy for a month now. Initially, I used it to handle morning meeting materials and research reports, but later a colleague dragged me in to help organize deviation reports for a pharmaceutical client. That's when I realized WorkBuddy shouldn't be treated as an automated report generator; it should be an auditable structured workspace. The CRAFT prompt structure, local knowledge base, and Skill imports mentioned in this training perfectly clarify this path. In WorkBuddy, a "Skill" can be understood as a pre-written capability template, such as a compliance gap scan. You don't need to teach it how to read files from scratch; you just load it and clearly define the task boundaries.

However, for this post, I'm switching topics to apply the same logic to a smaller experiment: using Dify, which I've only been learning for a day, to turn GMP deviation reports into a traceable deviation ledger. I've tried Dify for less than a day and am just getting started with FastAPI, so this isn't about engineering perfectionism—it's just about a conservative starting approach.

Let's start with the practical steps on how to build the most conservative ledger assistant from scratch. Open Dify, but don't rush to make it check the report. First, create a local folder named with the date, e.g., 2026-09-07_ledger. Inside, place only three types of things: original files, fixed templates, and a field list. Original files are PDFs or Excels, the template is a Word doc, and the field list specifies source, date, publication status, conclusion, and citation page numbers. This step is crucial because when Dify reads local files, the messier the files, the more the output looks like free-form improvisation.

Then go back to Dify and create a new knowledge base or workflow, naming it something like GMP Deviation Ledger. If your company has existing templates or plugins, load modules similar to document preprocessing or compliance checks; if not, start with pure task descriptions. Don't just write "Help me evaluate this deviation report"—that's too vague. I usually rewrite it using the CRAFT structure taught in the training: Context is a pharmaceutical client's deviation report, Role is a compliance ledger assistant, Action is extracting key facts and marking sources, Format is outputting a source-date table and a draft ledger entry, Tone is conservative and auditable. Finally, always add a line: "Information without a source must not be included in the conclusion."

Next, click "Add File" or upload to the knowledge base, selecting the 2026-09-07_ledger folder we just created. Beginners might ask, what's the difference between mounting and uploading? My understanding is that mounting is like designating a workspace for the tool, allowing it to read by directory; uploading tends to grab single files, requiring re-uploads for updates. The expected result here is that the task interface will display a list of read files. If filenames, dates, and source fields are clear, it will first output a summary draft; if fields are missing, it will indicate that confirmation is impossible. This warning is important—it exposes the risks.

If deviations involve listed companies or industry events, I'll only use Akshare and East Money (which I've just started learning) to pull some public announcements and market clues; I've used Huibo Investment Research for less than a week and only as a source for research reports. They don't replace deviation reports but add another column of clickable evidence to the ledger. The newer the public information, the stricter the date checks; the messier the sources, the more you need to break down fields.

I previously hit a pitfall with WorkBuddy. The first time I had it read over ten mixed PDF and Excel files and asked it directly to summarize deviation causes, it treated clauses from old SOPs as new requirements, completely ignoring dates. Later, I learned my lesson: first, make it do one thing—generate a source-date table. Just four fields: filename, file date, source, and citable page number. After running that, start a second task using this table as input to perform gap analysis. Breaking steps apart stabilizes output quality significantly. This method might not suit every team, but for me, morning meeting prep time dropped from 90 minutes to 56 minutes—a roughly 37.5% saving. The number isn't rigorous, but the process is definitely more stable.

I also set up permissions and collaboration along the way. In financial analysis, the biggest fear is an AI draft being sent out directly. My setup is: the raw regulatory library has write access only for compliance and research leads; sales and other teams have read-only access. Tool-generated outputs are uniformly placed in drafts, with filenames appended with _review_by_[Lead Name]. Any external material must pass through two roles: one person verifies sources, another verifies conclusions. Don't skip this step. AI can do the work, but signing authority cannot be outsourced.

Daily maintenance isn't complex either. On Fridays, I run an empty-field check in Excel to see if new files are missing dates, sources, or version numbers. My habit is to update the regulatory library monthly, moving expired files to archive—don't delete them, keep the trail. The training mentioned that knowledge base quality affects retrieval quality, and I feel this strongly. Knowledge base quality comes from feeding data, but you must clean it before feeding.

Traditional general-purpose large models can only handle simple Q&A and struggle to deeply adapt to regulations, internal SOPs, and inspection systems.

This statement holds true for pharma companies, and equally for us who do research reports, client materials, and compliance reviews. The actual return on AI depends on whether it can turn every step into a checkable object. So, my action advice for those encountering these tools for the first time: don't start by building a comprehensive agent. Take ten real files, create a local folder, write a field list, and make a small task responsible only for generating a source-date table. Get this minimal process working before considering Skills, expert roles, and automated weekly reports.

Looking ahead, for scenarios like GMP, investment research, and legal, making processes readable by AI and reviewable by humans is more practical than stacking models.