-
-
A supplier change becomes a plain-English stock warning, with a developer handoff and the agent’s decision receipt alongside it.
Open the daily page See the recorded warnings Try a review decision
Inspiration
The counter sells the last item. The website keeps taking orders.
A small business can look healthy while a connection behind it quietly stops working. Payments, payroll, stock, accounts and shipping depend on suppliers whose software keeps changing. Those suppliers publish technical updates. The person running the shop needs to know what it means for Monday morning.
I built Still Working to close that gap: turn a relevant supplier change into a useful warning, explain the business consequence, and prepare the detail for the developer who can help.
The harder question was when to stay quiet. Forward every update and the owner gets another inbox to ignore. I wanted an agent whose restraint was something I could demonstrate.
What it does
Still Working watches the public API contracts of Stripe, Square, Xero and ShipEngine and connects changes to eight routines in a shop profile.
The example follows Maya's twelve-person homeware shop. When a change deserves attention, she gets a plain-English note: what changed, what it could mean, and what to do next. A separate section is ready to forward to Priya, her freelance developer.
Repeated warnings are held. Uncertain dependencies wait for human review. The review workbench lets someone confirm the dependency, dismiss the case, or leave it pending.
Most mornings, the page has two words for her: Still working.
How I built it
I separated the work into three layers:
- Collect: Python fetches and compares published supplier contracts.
- Match: Deterministic code connects changed calls to the shop's routines.
- Explain: A Strands agent on Amazon Bedrock AgentCore writes the business consequence and next step.
The model handles explanation and judgement. Delivery controls live in code.
A Strands Transform intervention stamps known factual fields. Deny blocks ineligible delivery attempts. Local Confirm supports human approval; the deployed path holds uncertain cases before constructing an agent and accepts a case-specific decision from its authenticated caller.
The delivery ledger records successfully rendered notes. Quiet and repeated cases never construct a model. A refused note stays eligible for retry.
GitHub Actions runs collection separately from cloud review. Collection publishes supplier freshness and queues relevant changes without AWS credentials. The second job uses temporary OIDC credentials to invoke AgentCore and publish the result. An AWS failure leaves unfinished work queued and the review status visibly incomplete.
Explore the architecture · Read the technical design
What I can demonstrate
150 days of real supplier history. 56 individual changes. 23 supplier-day records. Two rendered notes.
I replayed every record against the deployed AgentCore runtime, carrying its returned delivery ledger into the next invocation.
The first Xero payroll change produced a warning. The repeat five days later was held. A Square inventory-transfer change produced the second warning, about stock moving between the counter and website. Only those two cases invoked a model.
That ratio is the product.
Every input, response and decision is available in the browser replay without an AWS login. A separate captured scenario demonstrates human-review outcomes. The video also shows fresh AWS execution: one new warning, followed by a second invocation that remembers it and stays quiet.
Come back during judging: the daily page shows when the suppliers were checked and when agent review completed, with a link to the actual run.
Challenges and what I learned
My first measurement returned zero. The profile omitted important routines. That taught me that a quiet monitor is only useful when it understands what the business depends on.
The model invented a date and filed it under FACT. My first fix corrected the tool input but lost the date before rendering. Three tests passed over that gap. I moved the checks to the note the owner actually reads, and made sure rejected notes cannot enter the delivery ledger.
The agent was deployed, but the daily collector did not call it. I connected the full path, added a deployed runtime probe, and replaced drifting copies of the delivery controls with generated code from one canonical source.
The strongest lesson was to follow the whole chain: supplier publication, business routine, agent decision, rendered note, saved memory. A successful tool call or a green test is useful evidence only when it checks the behaviour that matters.
The project now passes 366 tests, including delivery controls, rendered dates, repeat suppression, runtime isolation and recovery of queued work.
What's next
Validate the mappings against a real shop integration, evaluate missed changes using fresh supplier history, and add private storage and authenticated reviewer access.
The next milestone is a shop owner who can trust the quiet as much as the warning.
Build journal
I documented three parts of the build on AWS Builder Center:
- 56 supplier changes, two notes for a shop owner
- My agent was deployed, but the daily job did not call it
- My agent invented a date and filed it under FACT
Try it yourself
Open the daily page, inspect the recorded warnings, and try the review workbench. The README includes local setup, tests and instructions for reproducing cloud execution.
Evidence and disclosure
Maya, Priya and the shop are illustrative; supplier publications and captured AWS responses are real. The profile and repeat rule were refined using this history, so the ratio measures retrospective notification volume, not accuracy or customer savings. Published contracts show publication changes, not confirmed integration failures. Review examples use simulated choices; live decisions require operator import. No customer testing has been conducted.
A previous CI experiment comparing a generated artifact with a vendor API informed the design. No code from it is included. Still Working is MIT licensed.
Log in or sign up for Devpost to join the conversation.