Agents for Humans: EventBridge Scheduler to AgentCore

Two things about pointing EventBridge Scheduler at Amazon Bedrock AgentCore Runtime, neither
of them in the CLI help.

You do not need a Lambda in between. And the payload you put in the schedule is raw JSON,
even though the AWS CLI rejects raw JSON and demands base64 for the same field. Getting that
backwards cost us two firings and produced an error message that points at the wrong thing.

What follows is from a one-shot schedule that invoked our deployed agent with nobody
watching, then deleted itself.

EventBridge Scheduler's universal target can call the AgentCore data plane directly:

The schedule's Input is the API request as JSON:

The execution role needs one action, scoped to the runtime:

Put aws:SourceAccount on the trust policy for scheduler.amazonaws.com, and set
ActionAfterCompletion: DELETE on a one-shot schedule so it removes itself.

This cost us two firings. InvokeAgentRuntime's payload is a blob, so base64 is the
instinct, and the AWS CLI enforces it, rejecting raw JSON with:

Follow that instinct in the schedule and the runtime logs:

The schedule delivered; the handler received base64 text and could not parse it. Scheduler
passes the member through as written. Send raw JSON in the schedule's Payload, and use
fileb:// with raw JSON for the CLI. Its own error message points the wrong way.

With that corrected, the runtime logged what we were after:

Forty-five seconds is a real investigation on Claude Opus 5. The session ID is the one the
schedule supplied, which is what ties the run to the schedule rather than to a human at a
terminal.

The universal target is fire-and-forget. Scheduler does not read the response, so the
decision card that invocation produced went nowhere. Our agent had done forty-five seconds
of real work and nothing was listening.

So the Lambda comes back, for anything past a demo. Not because Scheduler cannot reach the
service, but because a scheduled sweep has to list what is unhandled, build a payload per
item, and record what came back. That is code, not target configuration.

A second limit, specific to how we deploy: each AgentCore session seeds its own SQLite
database, so a scheduled firing proves the gated path runs unattended. It does not carry
state from one firing to the next. We say that plainly rather than let it be assumed.

aws logs filter-log-events --start-time ... returned zero events for a window that
definitely had them, including with no filter at all. The agentcore logs --since 10m CLI
returned them immediately. If your filter counts look impossible, check the tool before
concluding anything about the system. We reported "0 invocations" twice before realizing
the query was at fault.

Also: a ResourceNotFoundException from get-schedule after the fire time is expected when ActionAfterCompletion: DELETE is set. It means the schedule fired and removed itself, not that the invocation worked. The runtime logs tell you that.

Mostly, don't. For event-shaped work, push instead: an event bus or a queue in front of the
same gated path handles work when it happens and gives you backpressure. A schedule only fires on the clock.

Scheduler earns its place on time-based work, where there is no event to wait for. A nightly
sweep. Anything stuck in a waiting state past its SLA. A retry of failed verifications. If
you are reaching for cron to fake an event you already have, a reviewer will notice, and
they will be right.