Coding Agents on Amazon Bedrock AgentCore Runtime

Run multiple coding agents (Claude Code, Claude Code validator, opencode) in parallel on Amazon Bedrock AgentCore Runtime, orchestrate them from one chat, and govern the fleet (identity, per-user cost, observability). Validation is agentic: the validator role authors an executable check for each specific deliverable and the engine runs it; its real exit code is the gate.

This repo is the full workshop payload. Clone it and follow the workshop content; every step is reproducible with the CLI, starting from this one clone.

This repository is the single source of truth for all demo and harness code. The matching Workshop Studio teaching content (guided lab pages and the CloudFormation template) is published on Workshop Studio; the CloudFormation bootstrap clones this repository directly into the box home, so the customer-reproducible path is exactly a git clone of this URL (which yields ~/sample-amazon-bedrock-agentcore-coding-agents) followed by the CLI steps the workshop teaches.

This repository is also a GitHub template. In Module 2 of the workshop you click Use this template -> Create a new repository to get your own isolated copy (no fork, no shared credentials): the S3 Files mount starts empty and the attendee types any request they like; the Module 2 pull request the orchestrator opens lands on that per-attendee repository through the GitHub App gateway.

Layout

• coding-agents/ the three coding-agent harnesses (container + setup.sh + deploy.py + connect.py) and shared infra/gateway
  • claude-code/ backend MCP-server builder (Claude Code, native Bedrock)
  • claude-code-validator/ acceptance-contract validator (Claude Code, native Bedrock; steered by an acceptance-contract CLAUDE.md that directs it to author an executable check whose exit code is the gate)
  • opencode/ frontend chatbot UI builder (opencode, native Bedrock)
  • kiro/ legacy restore path (hidden; kept restorable like codex/, not on any served roster)
• orchestrator/ the Strands orchestrator engine (routing, engine, executor, reviewer, github)
  • orchestrator/roles.py declares the served roster (WORKSHOP_ROLES-configurable); this is the single place role ids, kinds (builder/checker), and capabilities (backend/frontend/validator) live
• orchestrator-agent/ the deployable Strands agent bundle
• console/ the React + FastAPI console (Agents / Fleets / Governance)
• interactive-api/ metrics-api/ the Stage 1 interactive + Stage 3 metrics engines
• harness-skills/ agent skills used to configure the harnesses
• e2e/ the end-to-end workshop journey + integration suite

Tests

The full suite is collected from this repo root:

python3 -m pytest -q

pytest.ini declares the testpaths; the root conftest.py isolates GitHub / runtime credentials so no test can read a real token or open a real pull request.

When something is not working

Both are read-only, collect no credentials, and are safe to re-run:

python3 orchestrator/github.py doctor   # can the GitHub App reach YOUR repo?
python3 orchestrator/diagnose.py        # roles wired, gateway, recent verdicts
python3 orchestrator/diagnose.py <run_id>   # + that run's engine-log tail

Run doctor BEFORE deploying the coordinator. The mistakes that cost the most time (an App installed on a different repository, a wrong owner in GITHUB_REPO) all pass a plain gateway health check and then fail when a build tries to write, after the agents have already run.

Every finished run also persists its verdict, so run_status <run_id> still answers from a NEW coordinator session, and list_runs finds it when the run id is lost.

License

MIT-0. See LICENSE.