How JGS Uses AI Agents in D365 Projects: Two New Series

On a D365 implementation project, the sentence you hear most often is "But we said that in the meeting." Requirements come out of meetings, while the design document, the code, the tests and the manual are each written later, by different people. Along the way, things get left out or read differently.

These days there is a lot of talk about drafting documents quickly with AI agents. But someone still has to check that a quickly drafted document is right.

JGS Consulting is testing, first-hand on an internal project, how to use AI in Microsoft Dynamics 365 Finance & Operations (D365 F&O) implementations. Starting next week, we will share that work in two blog series.

Why we are starting two series

JGS is doing two things at once right now.

• Building JGS Agile Package (in testing), a package that bundles the requirements that come up again and again on implementation projects
• Building that package with an AI-agent-based delivery method, the JGS D365 F&O AI Delivery Methodology

Both come from the same internal project: Series A shows what we build, and Series B shows how we build it.

Four principles for how JGS uses AI

The goal of this method is not faster documents. It is to make sure that what was confirmed in a meeting carries through to the design, the code and the tests without gaps.

Below is the opening page of our methodology guide. It brings together the principles and roles, the process, the agents for each phase, Git integration and the tool guides in one document.

• Agents draft: An agent writes the first draft at each phase. A requirement without a source is not accepted. If there is no source, such as a timestamp in the meeting recording, a screenshot or a document, the requirement is marked as an "assumption".
• Critics review: We keep the working AI and the reviewing AI separate. The reviewing AI is read-only and uses a different model from the working AI to point out defects.
• People approve: The method puts a gate between phases, where a person approves. Whether the work moves on is a person's decision.
• Git keeps the record: The master copies of the requirement, design and test documents are kept in Git, and each approval is recorded as the confirmation of one specific version (commit).

The phases are kickoff → analysis → design → development → testing → manual → cutover. On our internal project, we have applied the method from analysis through testing so far. In testing, agents write the test cases and the test summary and carry out the first automated run, and people decide whether a test passes. The manual phase is not in use yet.

Below is the process diagram from the guide. The red diamonds between phases are the gates where a person approves, and each phase pairs a working agent with a critic. Master documents and their history are kept in Git, and documents for submission in SharePoint.

Because the internal project is a trial of the method itself, some parts of it run differently from the principles above. There are no customer meetings in internal package development, so the requirements are based on existing functional design documents and consultants' instructions rather than meeting recordings, which is why they are marked as "assumptions". Agents do the work at each phase, while the people responsible give the phase approvals and the go-ahead for development. Series B will report openly on what works well in this setup and what is risky.

Example: the path of one requirement

The following hypothetical example illustrates the flow the method defines.

1. Right after the meeting: Someone in the meeting says, "We want the inventory movement ledger the way it is used in Korea: opening balance, receipts, issues and closing balance." The analysis agent extracts the requirement from the recording and the transcript, and attaches the time of the statement as its source. The reviewing agent flags missing conditions, such as how receipts and issues should be broken down by type.
2. Analysis approval: A consultant reviews the requirement and its source and approves it.
3. Design: The design agent first checks the standard D365 source code to see whether standard functionality covers the requirement. It then drafts a solution in which receipt and issue types are configurable rather than hard-coded, along with the functional design document (FD) and the acceptance criteria. After review, the design document is generated in Word.
4. Development readiness check: Development starts only after a consultant and a developer have settled the open items left in the design.
5. Development: The development agent writes code only within the development scope listed in the design, and the code goes through a build and a code review.
6. Testing: Test cases are created from the acceptance criteria. One such condition is whether the receipt and issue columns of the ledger change accordingly when the type setup is changed. People decide whether a test passes.

Because the same requirement ID runs from the statement in the meeting to the test case, you can trace back to where something was dropped.

Weekly schedule

• Monday · Series A. JGS Agile Package: Starting with an overview of the package, we introduce, one at a time, the basic features that implementation projects have always needed, such as unified customer and vendor registration, master data approval, the inventory movement ledger, the ledger by account inquiry, cost elements and partial disposal of fixed assets. Line-level inquiry lets you query order, receipt, shipment and journal lines directly, instead of picking a header first and then viewing its lines. Beyond these basic features, packages built on new concepts will be introduced in separate posts. The package is in testing now. Each post first explains why a feature is needed and how the work changes; once a feature has completed testing, a follow-up post shows its actual screens and test results.
• Wednesday · Series B. AI-driven delivery: We cover, in turn, the AI agents for the analysis, design, development and testing stages, review (critics), approval and Git controls, operations, and risks.
• Friday · Progress and practice: Once a month for each series we report progress, and in between we publish practical D365 and implementation guides.

Where we are now

The internal project started on September 27, 2026. As of October 9, we have registered 25 gaps (requirements that standard functionality alone does not cover), and according to each gap's progress card, all 25 are in the testing stage. How far testing has progressed differs from gap to gap. The package is updated every day, so the figures are as of the publication date. Detailed figures, and the points where people stepped in, will follow in the progress posts.

Who these series are for

We hope the two series are useful if you are heading into a D365 implementation or upgrade and worry about missed requirements, or if you want to use AI on your project but are concerned about verification and control.

If you would like to know how this could be applied to your own project, please contact us.

한국어 글은 네이버 블로그에서 보실 수 있습니다: blog.naver.com/jgsconsulting