An AI support team for a Sterling WMS estate, with humans in charge
I built a governed multi-agent system that helps support a multi-solution IBM Sterling WMS estate. It investigates incidents, proposes data and code fixes and drafts reports, and it never changes production on its own.
Many codebases, many sites, one support team
Large Sterling estates often run several solutions that started from a common base and then diverged. Each has its own code, WMS version, build toolchain and deployments. Answering even a simple question means knowing which codebase, which version and which site's data you're looking at.
That context lives in people's heads, and it's exactly where generic AI assistants go wrong: confidently right about one codebase and wrong about the site in front of you.
Agents that know which estate they're in
- Solution vs. instance: code questions are scoped to a solution, data questions to a specific deployment, so answers stay right about both
- Version-aware: the WMS version drives which documentation, jars and JDK an agent uses
- Cited answers: generated documentation and explanations must cite the code and configuration they came from
- Gated changes: agents propose; people approve and deploy
From incident to approved fix
- 01
Triage
Classifies an incoming ticket, finds the affected solution and site, and gathers evidence from code, configuration and data.
- 02
Explain
Answers "why does it behave like this?" with citations back to the code and configuration it read.
- 03
Design
Proposes a fix or feature design against that specific solution’s codebase and configuration.
- 04
Develop
Produces the code change, compiled against the right WMS version, JDK and Sterling jars.
- 05
Test
Drafts a test plan and runs the checks it can, reporting what passed and what needs a person.
- 06
Approve
A human reviews and approves. Deployment to Sterling remains a human step, always.
How it's built
The swarm runs on SwarmKit, my open-source runtime for governed multi-agent AI. Agents, skills, approval gates and policies are defined as data rather than code, so the system can be reviewed and changed like configuration. SwarmKit is on GitHub, with documentation at delivstat.github.io/swarmkit.
- Separate agent topologies for triage, explanation, design, development, test planning, test runs, configuration and documentation
- Purpose-built MCP tool servers give agents controlled, read-only access to the estate
- Quality gates chain schema validation, an automated judge and human approval, and retries escalate to a person instead of being dropped
- Every tool call passes one permission check, and approval rights reserved for humans can't be granted to an agent
- An append-only, hash-chained audit trail records every step
- Builds stop at the compiled jar; the swarm never runs installers or touches a Sterling installation
What the agents can see
- Code
- Read-only access to each solution’s source, confined to that solution
- Data model
- Searchable table and entity documentation per solution and WMS version
- Configuration
- Reads configuration exports from each deployment directly
- Data
- Instance-scoped investigation queries for data issues
- Product docs
- Indexed IBM documentation, matched to the WMS version in use
- Conventions & specs
- Checks proposals against the estate’s coding conventions and Sterling XML schemas
- Tickets
- A ticket store the swarm reads from and drafts updates to
Want this for your estate?
The same approach works for other Sterling OMS and WMS estates, and for operations platforms beyond Sterling. I can help you assess where agents would genuinely help, and build them with the controls your auditors will ask about.