Weekly field notes: silence is not a stop signal
A quiet bot is not necessarily finished, and a cancellation is not proof that its side effects stopped. This issue connects three public guides on missed routines, MCP cancellation, and narrow credentials into one practical review: record the expected result, verify uncertain effects, and limit what a bot can do in the first place.
AI-assisted editorial: researched and drafted with AI using the primary sources linked below. Examples are illustrative; they are not measured product results. Editorial policy.
Key takeaways
- Watch for an expected run from outside the routine itself; a failed-delivery queue cannot reveal a schedule that never invoked its target.
- Current MCP transports prohibit further messages after cancellation, but the server may already have performed a side effect; check the effect separately.
- Give a bot only the provider permissions its real API calls need, then test the full path with that narrower credential.
First, prove the routine actually ran
Our guide to silent recurring routines separates three events: the schedule never invoked its target, delivery to the target failed, and a worker started but never finished the intended result. EventBridge Scheduler's dead-letter queue can capture a failed target invocation after configured retries. It cannot describe a schedule that never made an attempt, so give each expected slot a deadline and check for its completed record from a separate watchdog.
Try this with one routine you own. Write down its slot ID, the result it should produce, and a time after which absence is actionable. If that deadline passes, inspect the invocation record, any failed-delivery evidence, and the worker's result separately. An empty failure queue is not a success receipt.
Sources: Configuring a schedule's dead-letter queue in EventBridge Scheduler.
Then, treat cancellation as an uncertain outcome
Our MCP cancellation guide explains the current transport split. On stdio, the client sends notifications/cancelled for the request ID. On 2026 Streamable HTTP, it closes that request's response stream. Servers should stop work as soon as practical, and the current transport rules prohibit further messages for the cancelled request. That wire silence still cannot tell you whether a file, email, or other side effect happened before the cancellation took effect.
For an illustrative report bot, stop waiting after a timed-out tool call, record 'cancelled, outcome unverified,' and read back the report destination before retrying. If a report already exists for the slot, reconcile it instead of generating a second copy. If no reliable readback exists, leave the outcome for review rather than claiming a successful stop.
Sources: Cancellation - Model Context Protocol, stdio - Model Context Protocol, Streamable HTTP - Model Context Protocol.
Finally, make the credential smaller than the failure
Our API-key scoping guide uses Stripe restricted keys and GitHub fine-grained tokens to show a separate control. A narrow credential limits what a bot can ask a provider to do even when a prompt, bug, or retry goes wrong. Stripe lets you assign permissions by resource; GitHub lets a fine-grained token target selected repositories and named permissions. The exact grants still depend on the API calls your bot makes.
In the same illustrative report bot, start with a read-only provider credential if its job is only to gather data. List each endpoint it calls, map that endpoint to the provider's current permission documentation, and test the routine's less common branches before relying on it. Keep the write credential for the report destination separate, with a stable slot ID or another duplicate-prevention rule.
Sources: Restricted API keys, Managing your personal access tokens - GitHub Docs.
The public BotBento update
The BotBento blog now has the full guides on detecting a silent routine, understanding MCP tool-call cancellation, and scoping a bot's API key. Read them in that order if you want to apply this week's exercise to a real workflow: expected result, uncertain stop, then permission ceiling.
BotBento remains a pre-release workspace. These guides and this public newsletter archive are educational material; they do not claim that the app's bot runtime, monitoring, or provider connections are generally available. Email delivery is a separate, confirmed-subscription step after the archive is live.
Primary sources
Sources checked 2026-10-02. Standards and product documentation can change; follow the linked version when implementing.
- Configuring a schedule's dead-letter queue in EventBridge Scheduler — Amazon Web Services
- Cancellation - Model Context Protocol — Model Context Protocol
- stdio - Model Context Protocol — Model Context Protocol
- Streamable HTTP - Model Context Protocol — Model Context Protocol
- Restricted API keys — Stripe
- Managing your personal access tokens - GitHub Docs — GitHub
BotBento is in development. Suggest a correction.