Agents for Humans: Deploying a Strands Control Plane on Amazon Bedrock AgentCore
I deployed Authority Cut to Amazon Bedrock AgentCore Runtime without widening the agent's authority. The runtime reached READY, a real InvokeAgentRuntime call returned HTTP 200, and the same Strands control assertions passed inside AgentCore.
How I moved Authority Cut from a public demo to a verified AgentCore Runtime
I did not start Authority Cut by deploying infrastructure.
I started with the control semantics.
The first goal was to prove that a Strands agent could execute routine professional work while human authority stayed outside the model tool surface, and that a later human correction could change downstream execution.
Once that worked in tests and in the public judge service, I wanted one more piece of evidence for the Agents for Humans Hackathon:
Could the same control plane run inside Amazon Bedrock AgentCore Runtime without changing its authority boundary?
The answer was yes, but the deployment path was not the one I expected.
The architecture before AgentCore
Authority Cut is built around a small Strands tool surface:
1
2
3
execute_safe_vendor_work
get_authority_cut
execute_authorized_vendor_workThe agent can execute routine work, inspect the current Authority Cut and resume protected work that has already been authorized.
It cannot approve or revoke authority through the published model-callable tools.
The control plane owns:
the action DAG
policy-defined semantic authority bundles
evidence and execution receipts
current workflow status
grant and revocation state
correction propagation
compensation of reversible descendants
The public judge service already ran the real Strands SDK Agent loop with a deterministic custom Strands model provider.
That gave me a stable baseline before introducing another runtime.
A deliberately thin AgentCore adapter
I did not want the AgentCore integration to become a second implementation of the project.
The runtime adapter is intentionally small:
It cannot approve or revoke authority through the published model-callable tools.
The control plane owns:
the action DAG
policy-defined semantic authority bundles
evidence and execution receipts
current workflow status
grant and revocation state
correction propagation
compensation of reversible descendants
The public judge service already ran the real Strands SDK Agent loop with a deterministic custom Strands model provider.
That gave me a stable baseline before introducing another runtime.
A deliberately thin AgentCore adapter
I did not want the AgentCore integration to become a second implementation of the project.
The runtime adapter is intentionally small:
1
2
3
4
5
6
7
8
def build_agentcore_response(run_proof, payload=None):
proof = dict(run_proof())
proof["agentcore_runtime_adapter"] = \
"BEDROCK_AGENTCORE_DIRECT_CODE"
proof["agentcore"] = \
"RUNTIME_ADAPTER_EXECUTED"
proof["request"] = dict(payload or {})
return proofThe adapter does not add authority.
It does not add new model tools.
It does not reinterpret the correction logic.
It wraps the already-tested Strands proof so that AgentCore Runtime can host and invoke the same semantics.
That was an important design constraint for me. Infrastructure should not quietly widen the agent's capabilities.
My first deployment attempt failed for a very ordinary reason
I opened AWS CloudShell in
CloudShell has a small persistent home volume.
The installation pulled a large dependency tree and eventually failed with:
It does not add new model tools.
It does not reinterpret the correction logic.
It wraps the already-tested Strands proof so that AgentCore Runtime can host and invoke the same semantics.
That was an important design constraint for me. Infrastructure should not quietly widen the agent's capabilities.
My first deployment attempt failed for a very ordinary reason
I opened AWS CloudShell in
eu-central-1, Frankfurt, and initially tried to install the AgentCore CLI through npm.CloudShell has a small persistent home volume.
The installation pulled a large dependency tree and eventually failed with:
1
ENOSPC: no space left on deviceThis was not an AgentCore runtime failure. It was a local CloudShell storage problem.
After cleanup, the home filesystem went from nearly full back to about one percent used.
Instead of fighting the CLI installation, I switched to a more direct path using the AWS CLI and AgentCore control/data-plane APIs.
That turned out to be a better fit for this project anyway.
Building the Direct Code package
The runtime target was:
After cleanup, the home filesystem went from nearly full back to about one percent used.
Instead of fighting the CLI installation, I switched to a more direct path using the AWS CLI and AgentCore control/data-plane APIs.
That turned out to be a better fit for this project anyway.
Building the Direct Code package
The runtime target was:
1
2
3
4
Region: eu-central-1
Runtime: Python 3.13
Deployment: Direct Code / S3 CodeZip
Entry point: agentcore_main.pyCloudShell itself was
I used
The relevant dependencies were pinned:
x86_64, while the AgentCore direct-code package needed compatible runtime dependencies.I used
uv to build the target directory with ARM64 manylinux wheels for Python 3.13.The relevant dependencies were pinned:
1
2
bedrock-agentcore==1.21.0
strands-agents==1.52.0Then I copied the Authority Cut package and
The resulting CodeZip was about 28 MB.
Its SHA-256 was:
agentcore_main.py into the deployment directory and created the ZIP.The resulting CodeZip was about 28 MB.
Its SHA-256 was:
1
67c9ce7de97f48970d3c595e6914fef314011fa5cebccf4f01cd4b6bea32690eI also recorded the exact source HEAD used before packaging:
1
200d71f963bb4496a6f01a6cf1788695b3164739For a hackathon project, I find this kind of evidence useful. It makes "deployed to AWS" a reproducible statement instead of a screenshot-only claim.
Keeping the execution role narrow
I created a dedicated AgentCore Runtime role rather than reusing a broader deployment role.
The runtime needed access to:
the specific S3 CodeZip object
its runtime logs
tracing and metrics required by the runtime
I did not grant the runtime Bedrock foundation-model invocation permission.
That was intentional.
The accepted Authority Cut proof uses a deterministic custom Strands model provider. I wanted the AgentCore acceptance to prove AgentCore deployment and execution without turning a separate foundation-model integration into an implied claim.
So the evidence boundary remains:
Keeping the execution role narrow
I created a dedicated AgentCore Runtime role rather than reusing a broader deployment role.
The runtime needed access to:
the specific S3 CodeZip object
its runtime logs
tracing and metrics required by the runtime
I did not grant the runtime Bedrock foundation-model invocation permission.
That was intentional.
The accepted Authority Cut proof uses a deterministic custom Strands model provider. I wanted the AgentCore acceptance to prove AgentCore deployment and execution without turning a separate foundation-model integration into an implied claim.
So the evidence boundary remains:
1
2
3
4
AgentCore Runtime deployment: PASS
AgentCore live invocation: PASS
Strands loop inside AgentCore: PASS
Foundation-model invocation: UNVERIFIEDI would rather publish one narrow claim that I can reproduce than a broader AWS claim that the evidence does not support.
Creating the runtime
The Direct Code artifact was uploaded to a private S3 bucket with public access blocked.
I created the AgentCore Runtime with:
Creating the runtime
The Direct Code artifact was uploaded to a private S3 bucket with public access blocked.
I created the AgentCore Runtime with:
1
2
3
4
5
6
7
8
Runtime name: AuthorityCutRuntime
Region: eu-central-1
Runtime version: 1
Python runtime: PYTHON_3_13
Entry point: agentcore_main.py
Network mode: PUBLIC
Idle session timeout: 300 seconds
Maximum lifetime: 1800 secondsThe runtime reached:
1
READYon the first status check.
At that point I had deployment evidence, but not yet execution evidence.
For the hackathon I wanted both.
The important test was InvokeAgentRuntime
I invoked the runtime through the AgentCore data plane with a small JSON request asking it to run the verified Authority Cut Strands proof.
The AWS call returned:
At that point I had deployment evidence, but not yet execution evidence.
For the hackathon I wanted both.
The important test was InvokeAgentRuntime
I invoked the runtime through the AgentCore data plane with a small JSON request asking it to run the verified Authority Cut Strands proof.
The AWS call returned:
1
2
statusCode: 200
contentType: application/jsonThen I asserted the response rather than just reading it visually.
The acceptance checks were:
The acceptance checks were:
1
2
3
4
5
6
7
8
AGENTCORE_RUNTIME_DEPLOYMENT=PASS
AGENTCORE_LIVE_INVOCATION=PASS
STRANDS_LOOP_INSIDE_AGENTCORE=PASS
HUMAN_AUTHORITY_BOUNDARY=PASS
SAFE_ACTIONS_PRESERVED=5
REVERSIBLE_EFFECTS_ROLLED_BACK=6
IRREVERSIBLE_TRANSMIT=INVALIDATED
FOUNDATION_MODEL_INVOCATION=UNVERIFIEDThe returned proof also contained:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
execution =
REAL_STRANDS_AGENT_LOOP_DETERMINISTIC_MODEL
agentcore =
RUNTIME_ADAPTER_EXECUTED
agentcore_runtime_adapter =
BEDROCK_AGENTCORE_DIRECT_CODE
authority_mutation_tools = []
authority_boundary =
EXTERNAL_HUMAN_ONLY
receipt_count = 14This was the acceptance point I cared about.
The code was not merely stored in AWS.
The AgentCore Runtime actually invoked the adapter, the adapter ran the real Strands loop, and the same human-control assertions still held.
Why I kept the public demo as well
The project still has a public Vercel judge path:
https://evidencebound-authority-cut.vercel.app
I did not replace it with an AWS-only judge dependency.
The public path is simple for a judge to open in a browser and run without credentials.
AgentCore provides a second execution surface and stronger AWS deployment evidence.
For me, the two surfaces have different jobs:
The code was not merely stored in AWS.
The AgentCore Runtime actually invoked the adapter, the adapter ran the real Strands loop, and the same human-control assertions still held.
Why I kept the public demo as well
The project still has a public Vercel judge path:
https://evidencebound-authority-cut.vercel.app
I did not replace it with an AWS-only judge dependency.
The public path is simple for a judge to open in a browser and run without credentials.
AgentCore provides a second execution surface and stronger AWS deployment evidence.
For me, the two surfaces have different jobs:
1
2
3
4
5
Public judge service
-> easy human verification
AgentCore Runtime
-> AWS deployment and invocation verificationBoth execute the same control semantics.
A historical AWS blocker I did not erase
Earlier in the project, I tested whether a pre-existing EvidenceBound GitHub OIDC deployment role could be reused by the new competition repository.
The role did not trust that repository identity.
The STS assumption failed.
I kept that result recorded as a real blocker for that specific OIDC path.
Later, the successful AgentCore deployment used an owner-authenticated AWS CloudShell path with a dedicated runtime role.
I do not describe the earlier OIDC path as fixed because it was not fixed.
This is a small documentation choice, but it reflects how I want to build infrastructure for autonomous systems: failed boundaries should not disappear from the evidence just because another route succeeded.
What AgentCore added to the project
The control mechanism itself was already implemented before the AgentCore deployment.
AgentCore did not create Authority Cut Sets or Reversible Correction Propagation.
What it added was stronger deployment evidence:
a real managed AWS runtime
a versioned Direct Code artifact
a dedicated execution role
a real control-plane creation call
a real data-plane invocation
a second environment executing the Strands proof
confirmation that the model tool boundary survived deployment
That is exactly the kind of infrastructure upgrade I wanted.
The AWS layer strengthened the proof without becoming the invention.
What is still deliberately unclaimed
The AgentCore acceptance does not prove:
foundation-model-backed execution
authenticated end-user principal identity
correctness of arbitrary enterprise policies
durable distributed authority state
safe compensation against arbitrary real payment systems
measured productivity improvement
The vendor and payment effects in the public workflow are synthetic and in-memory.
The project is a concrete control-plane prototype and competition implementation, not a claim that general agent safety is solved.
The build lesson
The most useful lesson from this deployment was architectural:
Make the control semantics portable before making the infrastructure impressive.
Because the Strands tool boundary and correction logic were already explicit and tested, the AgentCore adapter could stay thin.
That gave me a clean acceptance question:
"Does the same Authority Cut proof still hold when AgentCore Runtime is the execution environment?"
The answer was measurable.
Runtime READY.
Invocation HTTP 200.
Real Strands loop executed.
Human authority remained external.
Five safe actions survived correction.
Six reversible protected effects were rolled back.
The pending irreversible transmit was invalidated.
That is enough for the claim I wanted to make.
A historical AWS blocker I did not erase
Earlier in the project, I tested whether a pre-existing EvidenceBound GitHub OIDC deployment role could be reused by the new competition repository.
The role did not trust that repository identity.
The STS assumption failed.
I kept that result recorded as a real blocker for that specific OIDC path.
Later, the successful AgentCore deployment used an owner-authenticated AWS CloudShell path with a dedicated runtime role.
I do not describe the earlier OIDC path as fixed because it was not fixed.
This is a small documentation choice, but it reflects how I want to build infrastructure for autonomous systems: failed boundaries should not disappear from the evidence just because another route succeeded.
What AgentCore added to the project
The control mechanism itself was already implemented before the AgentCore deployment.
AgentCore did not create Authority Cut Sets or Reversible Correction Propagation.
What it added was stronger deployment evidence:
a real managed AWS runtime
a versioned Direct Code artifact
a dedicated execution role
a real control-plane creation call
a real data-plane invocation
a second environment executing the Strands proof
confirmation that the model tool boundary survived deployment
That is exactly the kind of infrastructure upgrade I wanted.
The AWS layer strengthened the proof without becoming the invention.
What is still deliberately unclaimed
The AgentCore acceptance does not prove:
foundation-model-backed execution
authenticated end-user principal identity
correctness of arbitrary enterprise policies
durable distributed authority state
safe compensation against arbitrary real payment systems
measured productivity improvement
The vendor and payment effects in the public workflow are synthetic and in-memory.
The project is a concrete control-plane prototype and competition implementation, not a claim that general agent safety is solved.
The build lesson
The most useful lesson from this deployment was architectural:
Make the control semantics portable before making the infrastructure impressive.
Because the Strands tool boundary and correction logic were already explicit and tested, the AgentCore adapter could stay thin.
That gave me a clean acceptance question:
"Does the same Authority Cut proof still hold when AgentCore Runtime is the execution environment?"
The answer was measurable.
Runtime READY.
Invocation HTTP 200.
Real Strands loop executed.
Human authority remained external.
Five safe actions survived correction.
Six reversible protected effects were rolled back.
The pending irreversible transmit was invalidated.
That is enough for the claim I wanted to make.
Authority Cut series
Source and evidence
Public repository:
https://github.com/moneyparking/evidencebound-authority-cut
AgentCore acceptance evidence:
https://github.com/moneyparking/evidencebound-authority-cut/blob/main/docs/agentcore-acceptance-2026-08-23.md
Live browser demo:
https://evidencebound-authority-cut.vercel.app
Demo video:
https://youtu.be/dY8W-AP4mms
Public repository:
https://github.com/moneyparking/evidencebound-authority-cut
AgentCore acceptance evidence:
https://github.com/moneyparking/evidencebound-authority-cut/blob/main/docs/agentcore-acceptance-2026-08-23.md
Live browser demo:
https://evidencebound-authority-cut.vercel.app
Demo video:
https://youtu.be/dY8W-AP4mms
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article