The challenge
D.W. Morgan has operated as a technology company inside the logistics industry for thirty-five years. Its shipment visibility platform and its transportation management system are proprietary, built and maintained by its own engineers. That software was about to be rewritten for a new product generation, and IT leadership recognized that the engineering habits carried into a rewrite tend to outlive the people who set them.
The company faced three pressures at once.
- A once-in-a-decade rewrite was about to start.Adopting agent-assisted development before writing the first line of a new codebase costs a fraction of retrofitting it into a settled one. The window to get the practice right was closing.
- Stated confidence outran demonstrated capability.An internal survey of AI attitudes returned encouraging results, yet leadership judged the team to be some distance from current industry practice. Developers answer surveys about tools they have read about; an enablement program has to measure what they can do with a specification, an agent, and a deadline.
- Operational work was consuming engineering capacity.Support tickets were triaged by hand. Diagnosing a stuck shipment status or a silent carrier timeout meant an engineer reading code and logs. QA ran manually for every feature. Finance narratives came from a general-purpose BI assistant that could not be customized and that drew on a shared compute pool at a rate that capped how often anyone could use it.
Leadership set one further condition. The company did not want the work outsourced. Its own engineers would design, build, own, and commit the code, with experienced practitioners reviewing the work as it happened.
Most AI enablement programs end when the training ends. D.W. Morgan wanted the training to end with working systems in its own repository, built to standards its team could defend in a code review.
The approach
Apper Digital Inc. delivered the Enable and Architect phases of its Claude Professional Services framework, with its Claude Certified Architects embedded in the build rather than delivering it. The engagement was performed under the leadership of D.W. Morgan's IT Director, JC Nachor, whose direction kept the work anchored to the operational problems the company had already measured.
Enable: a curriculum built from a diagnostic
The engagement opened with a learning needs analysis of the Engineering and Solutions teams covering AI tool usage, specification and code review practice, testing maturity, CI posture, and attitudinal readiness. Self-assessment was paired with a short practical exercise, so that what engineers reported could be compared against what they produced. The output was a per-competency gap map.
The curriculum was then built from that map. Core modules covered model capabilities and failure modes, specification-driven development, AI-native workflows in Claude Code, agent design with tool use and the Model Context Protocol, testing and evaluation in an AI-assisted codebase, reviewing code a model wrote first, and governance of what may be sent to a model. A separate session for IT leadership covered direction-setting, role definitions, and the measurement changes AI-native development requires.
Architect: senior guidance inside the build
A senior AI solutions architect worked alongside the D.W. Morgan team for eight weeks in weekly working sessions with formal review checkpoints. The sessions covered agent architecture and integration boundaries, model routing and token cost design, prompt and specification review, structured code and design review, evaluation harness design, data handling and access control, and production readiness.
Architectural decisions were taken jointly. D.W. Morgan's engineers carried them into the code. Apper Digital's role was to be present at the point where a design choice was still cheap to change.
Where a partner delivers a system alone, the client receives a working artifact and the partner keeps the knowledge. Where the client's engineers implement while the partner sits inside the design and review decisions, the knowledge transfers as the system is built. The second path takes longer and leaves a more capable engineering organization behind.
What the teams built
Fourteen engineers in four teams designed and built four agentic systems, each aimed at operational work the company had already measured. All four run on the Claude Agent SDK. All four carry a human approval gate by design.
- Claude agent
- Human decision or approval
- Existing system or data
- File or output
Finance research agent
- report data
- KPI definitions
- follow-up
- escalate
Four chat interactions with the incumbent BI assistant consumed 22,569 capacity-unit seconds over eleven minutes, 6.53 percent of the entire twenty-four hour compute budget, at roughly US$0.28 per request. The shared capacity supported around sixty-one requests per day, falling to around fifty-four after scheduled refresh load, across every user and every report.
A Claude research agent over the reporting platform's API, exposed through purpose-built tools for retrieving report data, retrieving KPI definitions, asking follow-up questions, and escalating to a human. It surfaces interpretation rather than restating figures, flags items for review, and answers ad hoc questions in a scoped chat interface. It advises the finance team and is not permitted to decide autonomously.
One finance domain, one reporting period, and only the datasets finance has approved for exposure.
Zero invented figures across the labeled evaluation set. At least a 25 percent reduction in compute cost per query against the measured baseline. Summary structure controllable through prompt and configuration.
Legacy backend migrator
Applications on a long-unsupported version of Ruby on Rails, targeted for a modern Go backend. A simpler prior effort, merging two repositories of the same application, occupied five developers for close to a year alongside their normal workload.
An orchestrated pipeline of three specialized sub-agents. An extractor produces a behavioral specification in which every business rule cites the file and method it came from, plus a harvested test case set. A generator produces the Go implementation from that specification. An evaluator runs both implementations against identical inputs and categorizes every discrepancy: a generation bug routes back to the generator for a targeted patch; a missed requirement halts the run for a human to correct the specification; a format or environment difference halts the run for a human to adjust normalization.
Expected outputs are captured by executing each test input against the live Rails application at evaluation time. The specification is never treated as the authority on its own correctness.
Functional parity across the full test set, or documented residual failures at the iteration cap. Every extracted rule traceable to source. Generated Go builds cleanly and passes standard vetting and formatting checks.
Shipment incident investigator
- pull logs
- search code
- run tests
- Likely cause, cited
- Reproduction steps
- Candidate fix as a diff
- Test results, stated uncertainty
Well-documented problem tickets take about thirty minutes. Data updates with no code change take about two and a half hours. Complex tasks take about ten hours. Tickets requiring a script or code change take one day for simple cases and three days for complex ones, excluding client correspondence.
An assistant that pulls the relevant logs, searches the codebase, explains the likely cause with cited evidence, proposes reproduction steps and a candidate fix as a diff, and runs the tests. It states what it is uncertain about. It reads production and is structurally incapable of changing it.
Three real incident classes (duplicate status update, stuck status, carrier timeout) over safe mock data, through two purpose-built tools alongside standard file and search access.
At least a 50 percent reduction in time to an engineer-validated first diagnosis across the three incident types. Known root causes identified with evidence, reproduction steps, a proposed fix, and test results. No invented file names. No writes to production.
Agentic QA tester in CI
A QA engineer reviews acceptance criteria, writes test cases, generates test data, runs the tests, documents failures, and reports status, for every feature, with effort scaling directly with feature complexity.
Four cooperating agents around a shared ticket. A test planner drafts a structured plan from the ticket's acceptance criteria. A plan reviewer scores it against a fixed rubric. A test executor drives a real browser against the running application from the human-approved plan, recording pass or fail per case with evidence. An execution reviewer scores the results against a second rubric before anything is written back. The sequence runs as a dedicated CI pipeline, triggered when feature code reaches the QA environment.
A single project. Ticket access through the vendor's official command line tool with one narrow interface for screenshots. Browser automation inside the pipeline container.
At least 95 percent of acceptance criteria covered by a generated test case. At least 95 percent of test cases running to completion without tooling errors. Scenario diversity of at least 3 out of 5, test data relevance of at least 4 out of 5, stakeholder relevance of at least 3 out of 5. Every approval gate blocks until a human approves.
Five patterns that recurred across all four systems
Four teams working on unrelated problems arrived at the same structural decisions. These are the transferable part of the engagement.
- Specialized agents with restricted toolsetsEach agent receives only the tools its job requires. An extractor that can read and search but cannot write cannot modify the source it is analyzing.
- Coordination through files rather than conversationSub-agents exchange specifications, test cases, results, and feedback as files in a shared workspace. Every intermediate artifact can be inspected, version-controlled, and replayed.
- Human checkpoints at stage boundariesEach system is autonomous within a stage and pauses between stages. Placing the checkpoint at a boundary keeps the automation useful while keeping the approval decision with a person.
- Ground truth that does not come from the modelThe migrator compares against the running legacy application. The QA reviewers score against rubrics written in advance. The investigator cites specific log lines and source files.
- Categorized failure rather than binary failureKnowing that a test failed is far less useful than knowing why and who should act. Encoding that distinction is what turns a refinement loop into one that converges.
Results and what comes next
The Enable phase is complete. The Architect phase runs to November 1, 2026, and the four systems are in active development by D.W. Morgan's engineers.
The fourteen engineers are the initial batch of D.W. Morgan's Claude Agentic AI Champions. Under JC Nachor's leadership, their objective is to establish an AI Center of Excellence within the IT organization's team of more than thirty, carrying the practice from this engagement to the engineers who follow.
The baseline figures in this story are measured from the company's own operations. The improvement figures are the acceptance thresholds each team is building against, and they should be read as targets rather than results already banked. We are publishing at this stage because the baselines and the criteria are themselves the interesting part: a team that can state what it is measuring, what the current number is, and what threshold counts as success has already done the harder half of the work. Measured results will be published once the evaluation sets have been run.
Governance and ownership
Lessons for engineering leaders
- 01Sequence the enablement before the rewrite.Establishing AI-native practice first costs a fraction of retrofitting it into a settled codebase and culture.
- 02Measure readiness with a practical task rather than a survey.Ask people to produce something small and compare it with what they reported about themselves. The gap between the two is the curriculum.
- 03Pick first use cases that are bounded, high-volume, and already measured.Every system here had a before-state someone had quantified, which is why the teams could write success criteria rather than aspirations.
- 04Decide what you want to own when the work ends.A partner delivering alone is faster. A partner inside the architecture while your engineers implement leaves you with a team that can design the next system without help.