Agents for Humans: My Agent Was Deployed, but the Daily Job Did Not Call It #AgentsforHumans
How I connected GitHub Actions to Bedrock AgentCore using temporary credentials, shared delivery controls and a persistent queue. The result keeps supplier checks publishing through AWS failures and preserves unfinished work for the next run.
Series: Building Still Working (3 articles)
- 2Agents for Humans: My Agent Was Deployed, but the Daily Job Did Not Call It #AgentsforHumans This article
A working deployment and a working collector can still leave you with a product that does not run end to end.
That was the gap I found while finishing Still Working for the Agents for Humans hackathon. The project watches public supplier contracts and writes a plain-English warning for an illustrative shop owner, Maya. Its judgement layer ran on AWS Bedrock AgentCore. The scheduled collector ran in GitHub Actions. The connection between them was missing.
Local demonstrations and a green collector were not evidence that today's relevant change would reach the deployed agent.
The connection I added
The daily job now follows one explicit path:
- Fetch the suppliers' public contracts and record structural changes.
- Queue relevant records and publish the supplier check in a credential-free collection job.
- In a separate job, invoke the deployed runtime for queued and pending records, supplying the existing delivery ledger.
- Save approved notes and the returned ledger, then publish the agent-review status.
GitHub authenticates using OIDC. The role trusts this repository's main branch and can invoke only this runtime and its default endpoint. There is no stored AWS access key and no deployment permission in that role.
The first actual workflow run exposed a useful detail. Assuming the role succeeded. Invoking the runtime failed, because the permission covered the runtime ARN but not its
runtime-endpoint/DEFAULT resource. The error named the missing resource. I added that exact endpoint rather than granting broad account access.That first version stopped before publishing a fresh reassuring page. I have since separated collection from cloud delivery: a failed AWS call leaves the supplier check available but explicitly marks the agent review incomplete. A fresh timestamp must not turn a failed review into an all-clear.
The deployed copy had another problem
While reading the deployed bundle, I found it had fallen behind the local implementation. The local agent had newer date and delivery controls, but the cloud copy did not share all of them.
I replaced the handwritten copies with generated controls from the canonical local definitions. The deployable still imports only its own bundle. A check fails if the generated files differ from their source.
That gives me two separate checks: the bundle can run independently, and its controls agree with the implementation I am testing. Neither assertion substitutes for the other.
Memory belongs to a caller
The runtime does not claim that its process memory is durable. Each authenticated invocation receives a delivery ledger and returns the updated one. GitHub Actions persists that ledger with the notes it publishes.
A tool call the model attempted is not a delivery. The ledger changes only when the note passes the controls and renders successfully. If the model finishes without a usable note, the case stays pending. Pending cases are retried even when no new supplier change arrives. Collection now queues relevant changes before AWS access is attempted, so a failed first invocation cannot make yesterday's change disappear from tomorrow's workload.
For a real customer product, this would need private storage and an authenticated review interface. The public repository stores only the illustrative demonstration's state.
Test the path you plan to show
I replayed all 23 historical supplier-change records against the actual deployed runtime. The saved evidence includes the inputs, responses and ledger. The replay rendered two notes and invoked the model only for those two cases.
I also added a model-free runtime probe to the daily workflow. A morning with no relevant changes must still prove that the configured role can reach the deployed contract; otherwise a broken permission could remain invisible until the first important event.
For a fresh demonstration,
python tools/live_demo.py now matches the historical Square change, asks the deployed runtime for a new stock warning, then sends the same change with the returned ledger. It must render one note followed by no repeated interruption. Each result comes from AWS at execution time, and the demo ledger stays separate from the daily state.The main lesson was embarrassingly practical: trace one event from its source to the thing the person reads. A deployment screenshot proves less than I wanted it to.
Series: Building Still Working (3 articles)
- 2Agents for Humans: My Agent Was Deployed, but the Daily Job Did Not Call It #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