AI Architecture Reference · AWS Bedrock · Multi-Agent
6R-ARF Bedrock Prompt Architecture
How the 6R Application Rationalization Framework's AI agents are prompted, how they pass context between each other, and how model instructions map to 6R outputs. The same agent swarm that powered the 36-app healthcare engagement and the Digital Twin Simulator.
6R-ARF uses Amazon Bedrock's native multi-agent framework. Five agents run in a coordinated pipeline — each with a specific instruction set, tool access, and output contract. No custom orchestration code. Bedrock handles conversation state, action group routing, and guardrails.
System Prompts
Agent Instruction Design
Each agent carries a specific system prompt that constrains its scope, defines its tools, and specifies its output format. This is what makes the recommendations defensible — every agent has a single job and a structured output contract.
🤖 Orchestrator — System Prompt
You are the 6R-ARF Orchestrator. For each application in the backlog:
1. Retrieve the application profile from the CMDB tool
2. Invoke the Telemetry, Dependency, and Procurement agents in parallel
3. Wait for all three to complete
4. Invoke the Provisioning agent with dependency results
5. Pass all outputs to the Synthesizer
6. Store the Synthesizer output to DynamoDB
// Timeout: 30s per action group // On failure: mark dimension unavailable, reduce confidence
📊 Telemetry Agent — System Prompt
You analyze server utilization for a single application.
Use get_application_profile() to retrieve CPU/RAM metrics.
Use get_dependencies() to identify network traffic patterns.
You map application dependencies and assess migration risk.
Use get_dependencies(hop_depth=2) for upstream/downstream.
Use get_blast_radius() to quantify impact of migration.
Use detect_circular_dependencies() to flag blockers.
You identify SaaS alternatives and contract intelligence.
Use search_contracts(vendor_name) for renewal dates and costs.
Use search_market_intel(app_name) for SaaS migration paths.
You calculate right-sizing ROI using CMDB and telemetry.
Receives dependency analysis as input context.
Use get_application_profile() for current VM specs.
You produce the final 6R recommendation from all agent outputs.
Apply the 6R decision framework in priority order:
RETAIN if life-safety or latency-critical
RETIRE if redundant and dependencies confirmed zero
REPURCHASE if SaaS alternative confirmed available
REFACTOR if internally developed and serverless viable
REPLATFORM if database-heavy and managed DB viable
REHOST as default for virtual workloads
Each agent call is a structured data handoff. The Orchestrator passes application context down. Specialists return structured JSON. The Synthesizer correlates all outputs into a single recommendation. This is the data flow that powers every dashboard.
Three principles drove every prompt decision: single responsibility, structured output, and explicit uncertainty.
Single Responsibility
Each agent has one job. The Telemetry Agent never touches contracts. The Procurement Agent never touches network flows. This prevents hallucination cross-contamination and makes each output independently auditable.
Structured Output Contracts
Every agent returns typed JSON with defined fields. The Synthesizer validates all inputs before producing a recommendation. If a field is missing, the confidence score drops proportionally — the system never silently ignores missing data.
Explicit Uncertainty
The Synthesizer is instructed to populate missing_intelligence_list with exactly what data would improve the recommendation. This turns every low-confidence output into an actionable data collection roadmap — not just a warning.
MCP Tool Isolation
Agents never write SQL or API queries. They call named MCP tools with typed parameters. The MCP servers enforce read-only access to Neptune and OpenSearch. This means agents cannot accidentally modify production data.
Parallel Execution
Telemetry and Procurement run in parallel — they have no data dependency on each other. Dependency must complete before Provisioning (blast radius informs right-sizing). This cuts total analysis time by ~40% vs sequential execution.
Bedrock Guardrails
Amazon Bedrock's built-in guardrails prevent agents from producing recommendations that violate HIPAA constraints. PHI-handling applications without a valid BAA are automatically flagged — the model cannot override this gate.
Simulation Layer
Digital Twin Extension
The Digital Twin adds a sixth simulation layer on top of the standard agent swarm. The same agents run, but now they have access to the full dependency graph and telemetry time-series — enabling wave rehearsal and blast radius simulation before any production change.