JGS Agile Package October Update: 25 Gaps Developed, Verification Under Way

October 2026 progress report, with a look at how one feature was built using AI agents

Anyone who has worked on ERP implementations knows that the same requests come up again and again, no matter the company:

• "We want to register a customer and a vendor in one step."
• "Changes to GL accounts or items should go through approval."
• "We need to see journal and inventory transactions in one place, not across several screens."

In most projects, requirements like these are analyzed, designed and developed from scratch every time.

At JGS Consulting, we are analyzing these recurring requirements up front and building the extensions they need on top of the standard capabilities of Microsoft Dynamics 365 Finance & Operations (D365 F&O). The result is the JGS Agile Package.

Our previous post explained why we are building the package and what we expect it to change in implementation projects. This time we go one level deeper: how much has actually been built, and how far has verification progressed?

The short answer: as of October 15, 2026, all 25 gaps in the JGS Agile Package have finished their planned development work and moved into test preparation and execution. No feature has received a final pass verdict yet.

Below we share the current status and walk through how one real feature was built.

25 gaps, from analysis and design to development

We manage the package in units we call gaps. A gap is an area where standard D365 functionality and real business requirements differ, or where additional review and implementation is needed.

Our internal project, which started on September 27, 2026, defined 25 gaps. Analyzing and designing them produced the following deliverables:

Deliverable	As of Oct 15
Gaps	25
Requirements	110
Business rules	660
Acceptance criteria	1,892
Test cases	1,026
Regression test cases (included in test cases above)	105

Each of these artifacts has a distinct job. Take a requirement such as "check whether a business partner has suspended or closed its business when registering it." We first turn it into business rules: under what conditions to look up the status, and what to show as a result. We then write acceptance criteria that define what "working correctly" means for each rule, and finally link those to test cases that can be run in the system.

In other words, every requirement flows through a traceable chain: business rule → acceptance criteria → test case.

The 25 gaps span a wide range of business areas: master data registration and approval, configuration, consolidated inquiries and reporting, cost basis setup, fixed assets, public API integration and dashboards. They also include integration between JGS's VAT package and the Project module.

All development uses the extension model, so Microsoft's standard source code is never modified. That said, what sets this project apart is less the extension approach itself and more how we carry analysis and design all the way through development and verification, and keep them linked.

"Development complete" does not mean every gap took the same path

All 25 gaps have completed their planned development, but they did not all get there the same way.

We are using this internal project to validate the JGS D365 F&O AI Delivery Methodology, our own implementation methodology built around AI agents. We connected the development phase to the methodology on October 3.

For features developed before that date, we compared the names and composition of the implemented objects against the design documents and recorded the results. This confirms that what was built matches the design on paper. It does not mean the features' behavior has been verified.

For features developed after October 3, development starts from an approved design document, and build and code review results are captured as methodology deliverables.

So we are gradually moving from "build first, then reconcile against the design" to "build from an approved design and keep a traceable record of the process." Seeing that difference in practice is itself one of the things this project is helping us validate.

How far has testing progressed?

Finished development is not the same as a usable package. We still need to confirm that business rules were implemented as designed, that features behave correctly under errors and edge cases, and that nothing existing has been broken.

We use AI agents to write test cases and test result summaries, and prepared tests go through an automated first run. The decision on whether a feature finally passes is made by a person, based on those automated results.

Here is where the 25 gaps stood on October 15:

Test status	Gaps
Automated first run complete, awaiting human verdict	15
Test cases written, not yet run	6
Test cases not yet written	3
Awaiting approval to start testing	1
Total	25

The 1,026 test cases mentioned earlier cover the 21 gaps for which test cases are ready.

The 15 gaps that have completed an automated first run have not yet received a final pass verdict either. For that reason, we are not publishing pass or fail counts from the automated runs in this update. We will share results once the responsible consultants have reviewed them and made a final call.

So how do AI agents and people actually divide the work during development?

A real example: checking whether a business partner has suspended or closed its business

Let's look at one feature from the internal project.

Using a business partner's business registration number, the feature periodically queries the registration status held by the Korean National Tax Service and shows on the partner record whether the business is suspended or closed.

The goal is simple, but putting it into real use required several decisions first: how often to query, where to store the results, and what to do when a query fails.

We split the roles so that the AI agent does the work and the consultant makes the business decisions.

1. Clarifying the requirement. The consultant described the purpose of the feature. While organizing it, the AI agent raised four key questions that needed answers. The consultant's answers went into a requirements summary, which the analysis phase then broke down into five requirements. A separate reviewer AI checked the analysis.

2. Design and business decisions. The design phase produced one design document and one configuration specification. Along the way, seven items surfaced that needed a business owner's decision. The AI proposed a recommendation for each, and the consultant made the final call: six followed the recommendation, and for one the consultant chose a different option. The AI's proposal was not simply adopted; the person responsible decided what fit the actual business.

3. Readiness check before development. After design, 17 items still needed confirmation. These were collected in a development readiness checklist. Some were settled before development started; for the rest, a confirmation plan was written down and they were reviewed during development. The consultant weighed these items before deciding to start development.

4. A problem during development, and a design change. During development, part of the original implementation approach turned out to be outside what the development environment supports. The development agent did not change the approach on its own. The consultant reviewed the options, and the design was revised first so that the affected part would be implemented as a separate table. Development then resumed against the revised design, and the build succeeded.

A successful build is not the same as passing functional tests. What matters here is that when the design had to change, the reason and the decision were recorded before development continued.

5. Testing. We wrote 86 test cases for this feature, including 5 regression tests. The automated first run is done, and the feature is now waiting for the consultant's final verdict.

The principle behind this example is clear. We do not create objects that are not in the approved design. If the design needs to change, the change is reviewed and recorded first, and only then does development continue.

AI agents may do the work, but business decisions and approvals stay with people.

Because this is still an internal pilot, some steps are streamlined. The core principle, however, is unchanged: keep a record of why requirements and designs change, and let a person make the final call.

Next step: final verification of each feature

The main task now is to review test results and reach a final verdict for each feature.

For the 15 gaps that have completed an automated first run, consultants will review the results and, where issues are found, fix and retest. The other 10 gaps will continue with writing and running test cases; one of them must first go through approval to start testing.

It is still too early to put a number on how much development time has been saved, or what efficiency gains to expect in customer projects. What this internal project already does, though, is put into practice a way of linking deliverables from requirements analysis through design, development and testing, while keeping a clear line between what the AI does and what people decide.

The JGS Agile Package is both a product for reusing common functionality and a proving ground for the AI delivery methodology JGS is developing.

In upcoming posts, we will introduce individual features one at a time, starting with combined customer/vendor registration and consolidated transaction inquiry. For each, we will explain why it is needed, how far standard D365 can take you, and what changes in day-to-day work once the package is applied.

We will share actual screens and verification results for features as they pass final testing, and update the figures in our next progress report.

The development and test status in this post is as of October 15, 2026, and may change as the project progresses.

If you are implementing or enhancing D365 and would like to know more about the JGS Agile Package's features or how it is applied, please get in touch: https://jgs.ai.kr/support/contact

JGS Consulting — Designing the future of business.

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