How a Pharmacy Fulfillment Platform Provider Replaced Hardware-Dependent Testing With AI-Built Simulators

At a glance

Pharmacy fulfillment platform provider
Healthcare & Life Sciences
AI tooling integration, simulator development, testing enablement, process modernization
Claude, a web application simulator (CLI + REST tool), a dispensing hardware simulator (.NET 8), desktop application UI automation (FlaUI), Simulator Configuration Tool, Canister Station Simulator, Release Tag Diff Analyzer; protocols include JSON-lines IPC, HTTP REST, XML over TCP sockets typical of dispensing hardware, and serial framing typical of canister station hardware
The Challenge: Testing That Couldn't Start Without the Hardware, the Office, or the Right Specialist

The company’s testing process depended on physical equipment located in its office, and that dependency shaped everything downstream of it:

  • Validation required being on-site. Certain validation activities could only happen near the devices under test, so testing couldn’t start until someone with the right equipment access was in the room.
  • Validation was concentrated late in the development cycle. That access constraint pushed hardware-dependent testing toward the end of each cycle, leaving a short window to catch integration problems before release.
  • System behavior lived in people, not documentation. Documentation of how the hardware and software were supposed to interact was incomplete, so the dependency wasn’t just on hardware: it was on the small number of people who understood it.

The company wanted to move validation earlier in the development cycle, reduce its dependency on specialized availability, and modernize its testing practices.

Gorilla Logic's Solution: Three Simulators Built Through Chronicle and an Agentic SDLC

The first challenge wasn’t building the simulators. It was discovering exactly what they needed to simulate. Much of the expected behavior of the physical hardware, including error conditions and protocol interactions, wasn’t fully documented. Critical knowledge lived across existing documentation, source code, device protocols, and the experience of a small number of specialists.

Gorilla Logic started by running Chronicle, its structured and repeatable workflow for reconstructing how a system behaves. Chronicle first mapped the available information, then analyzed the system in greater depth, synthesized the findings, and finally validated them with the people who understood the system best. When expected behavior wasn’t clearly documented, the team captured it.

That process transformed knowledge that had previously lived in people’s heads into documented and validated requirements for all three simulators: the dispensing hardware simulator, web application simulator, and Canister Station Simulator.

Once the team knew what the hardware needed to do, the next challenge was turning that knowledge into working software efficiently without giving up engineering control.

Instead of treating Claude as a coding assistant working task by task, Gorilla Logic built an agentic SDLC around the requirements produced by Chronicle. The system operated more like a small development team than a single AI assistant.

A Planner agent handled intake and scoping, proposed the technical approach, and transformed the validated requirements into structured work items small enough to deliver in roughly a day. Each work item was tied to acceptance criteria before implementation began.

From there, a Generator agent created the development workflow needed to execute the plan. An orchestrator routed the work to developer agents that followed strict test-driven development practices. When repeated failures occurred, agents were required to stop and escalate rather than continue generating changes indefinitely. A reviewer operated in a separate context and independently re-ran the checks instead of simply accepting the developer agent’s results.

That agentic workflow accelerated implementation, but AI never controlled the final engineering decision.

Developers committed their work locally, and the orchestrator pushed changes only at the end of a phase and only after Gorilla Logic reviewed and approved them. Nothing merged into the main branch without a person signing off. AI-generated code was therefore treated the same way the team would treat code produced by any other contributor: it had to satisfy the requirements, pass its checks, survive independent review, and clear a human gate before becoming permanent.

That combination of Chronicle, agentic development, and human oversight created a repeatable path from undocumented system behavior to validated software.

The approach also helped the team make pragmatic implementation decisions along the way. For the dispensing hardware simulator, Gorilla Logic selected .NET 8 instead of .NET 6, enabling the lightweight background server that allows automated tests to drive the simulator over the network rather than through its desktop interface.

For the web application simulator, the team avoided an unnecessary rewrite. Instead, Gorilla Logic extended the existing simulator with a new CLI and REST layer, preserving previously validated behavior while making the simulator accessible to automated workflows.

The same approach produced supporting capabilities around the simulators. A Simulator Configuration Tool replaced manual, error-prone configuration with a desktop workflow supporting snapshots and rollback, while the Release Tag Diff Analyzer introduced another agentic workflow that compares release tags or pull requests and drafts corresponding test proposals.

The result wasn’t simply three simulators. Gorilla Logic created a repeatable way to capture system knowledge, translate it into software requirements, accelerate implementation with AI, and still keep engineers responsible for what ultimately reaches production.

The Results

Testing That No Longer Waits on a Person, a Device, or an Office


Validation moves earlier in the development cycle.
The narrow pre-release window used to be the only place integration problems could surface. Now they show up while there’s still time to fix them.

Testing no longer depends on office access or a handful of specialists. An engineer used to need to be on-site, near the physical dispenser, before certain checks could even start. That same validation now runs from any engineer’s laptop, because the system behavior that used to live only in a few people’s heads is documented and shared across the team.

A bad configuration change is now recoverable. A misconfiguration used to be a mistake the team lived with. The Simulator Configuration Tool’s snapshot and rollback support turns it into something the team undoes.

Failure scenarios that were impractical to stage now run on schedule. Getting the physical dispensing hardware to misbehave on command, to see how the system handled a protocol error or a chaos condition, was hard to arrange and harder to repeat. The dispensing hardware simulator’s fault-injection and chaos modes run those same scenarios whenever the team needs them. And because all three simulators already run headless behind an API or CLI instead of needing someone driving a UI, wiring them into a CI pipeline is integration work now, not a re-architecture.