Agents for Humans: 56 Supplier Changes, Two Notes for a Shop Owner #AgentsforHumans
I replayed five months of real supplier history through a Strands agent to find out when a shop owner should be interrupted. An initial result of zero exposed a setup problem and shaped a system that turns technical changes into useful next steps.
Series: Building Still Working (3 articles)
- 1Agents for Humans: 56 Supplier Changes, Two Notes for a Shop Owner #AgentsforHumans This article
My first measurement returned zero.
I am building Still Working for the Agents for Humans hackathon. It reads the public API contracts of four suppliers, matches changes to a shop's routines, and uses a Strands agent on AWS Bedrock AgentCore to explain a possible business consequence.
Maya is the illustrative shop owner: homeware online and at one counter, twelve people and a freelance developer. I used real supplier history to put that design through changes I had not invented.
The answer I did not want
I reconstructed daily states from the suppliers' public repositories. The first profile was too thin. None of the potentially breaking changes matched it.
It would have been easy to present that as a reassuring result. The tool stayed quiet. What I had actually demonstrated was that an incomplete profile can make an apparently useful monitor irrelevant.
I added routines covering stock, payroll and reconciliation, then widened the calls watched by the routines already present. That made the example more representative of the shop I was describing. It also means the profile was informed by the history used to measure it. I cannot call this a held-out evaluation.
That distinction matters more than making the headline number look good.
What the history says
The current record spans 150 days. There are 23 supplier-day change records across 22 calendar dates, containing 56 individual changes. Nine have a potentially breaking shape. Three records contain a removal mapped to the shop's payroll or stock routines.
Xero removed employee calls from its published contract on 24 April, restored them, then removed them again on 29 April. Square removed an inventory-transfer call on 14 July. Those publication changes are observed facts. Whether the shop depends on each affected call is the inference the developer needs to check.
My five-day repeat rule produces one payroll note from the April sequence. The Square change produces the other, about stock moving between the counter and website.
I then replayed every record against the deployed AgentCore runtime, carrying the returned delivery ledger into the next invocation. It rendered two notes. Only those two cases invoked the model.
Two notes from 56 changes. That ratio is the product.
It is notification volume, not accuracy. It does not prove an outage was prevented, and it does not tell me how many important changes the detector missed. The five-day window is a chosen tradeoff: it can also suppress a distinct problem affecting the same routine.
Why use an agent here?
Fetching and matching do not need one. Turning a publication into a useful explanation does.
The recorded Square note starts with a possible consequence: the website might keep selling after the counter sells the last item. Underneath is a section for Priya, the developer, identifying the changed call and asking her to check whether the integration uses it.
That is the division I wanted. Code decides whether the change qualifies for attention. The model writes the explanation. The owner gets a next step, and the developer gets evidence.
I have not conducted customer testing or measured savings. The next useful measurement needs fresh supplier history and an actual integration whose dependencies can be checked. A better retrospective ratio would not answer that question.
Series: Building Still Working (3 articles)
- 1Agents for Humans: 56 Supplier Changes, Two Notes for a Shop Owner #AgentsforHumans This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article