HIPAA Bedrock Agentic Orchestrator Architecture Diagram: MHK Controller-Agent Pattern

The September 30, 2026 case study How MHK built a HIPAA-eligible agentic AI solution on Amazon Bedrock describes the SmartProminence AI Orchestrator for medical, pharmacy, grievance, and appeals work. Amazon Bedrock is only the model call. MHK kept orchestration, retrieval, and validation.

What this HIPAA Amazon Bedrock agentic architecture diagram shows

The path is stateless. A REST API on the Agent Orchestration Core accepts the job. The core, Spring Boot on AWS Fargate, is the only component that touches the database. It drops a ControllerTaskMessage on the Controller Invoke Queue. The Workflow Engine Controller loads a version-pinned definition, turns dependencies into a DAG with Kahn’s algorithm, and pre-creates step rows in a WAITING state. An AgentTaskMessage on the Agent Invoke Queue carries a capability token for that step only. The agent binds inputs, optionally runs vision on a scan, assembles a prompt, calls Bedrock (the post names Claude), and post-processes the result. Prior case context sits in Amazon S3 under that client’s AWS KMS key.

The problem this architecture is solving

Each new AI feature used to mean its own cluster and compliance work. The opening says features that took 3+ months now ship in 2 weeks. Later, the same post says the old engineering cycle was 3 to 6 months and the new one is about 2 weeks. Do not merge those intervals. Case managers spent 5 to 10 minutes per incoming document across prior authorization, claims, appeals, pharmacy checks, and faxed records. The orchestrator’s answer is configuration: prompts, schemas, and a registered agent.

Main components and trust boundaries

The core exposes job submission, workflow management, an LLM proxy, and token management. Controllers and agents never open Amazon RDS themselves. The post lists Amazon RDS for MySQL 8.4, multi-AZ, holding definitions and execution state, with row-level encryption on top of storage encryption. S3 holds job artifacts, documents, and immutable workflow configurations. The post says objects are double-encrypted: S3 server-side encryption plus the client’s KMS key, so a misrouted job still cannot be decrypted without that key. It presents that misroute as something the token system helps prevent, not as a measured failure rate.

SQS, with dead-letter queues, is the bus. A controller token may read workflow and job data, dispatch tasks, and create step executions. An agent token may read its step input, write its result, call the LLM through the proxy, and upload artifacts. Tokens are minted per dispatch in KMS. Cognito supplies OAuth2 and JWT. The load balancer terminates TLS 1.3. Database subnets have no internet path. S3, SQS, KMS, Secrets Manager, CloudWatch, and ECR use VPC endpoints. CloudWatch on the diagram is marked no PHI, with token counts and content hashes. The same case study also says LLM inputs and outputs are logged with full audit trails, and later that bodies are not logged. Both lines stay, because the post does not reconcile them.

The post says Bedrock was chosen for one API across models, existing IAM, VPC, and encryption controls, plus content filtering and invocation logging. MHK still checks outputs in the agent: schema, a cross-check against source documents, a confidence threshold the post does not number, and a rule that text cite only that patient’s records.

Request or data path, step by step

A job enters the core. The controller resolves the DAG, evaluates Spring Expression Language against completed outputs, and skips steps that the expression rejects. The pharmacy example in the post: if classification says the case is not about prescription drugs, pharmacy verification at the next depth is skipped. Steps at the same depth run together. The controller polls until that depth finishes, then advances. Inside one step, the post says agents use Java virtual threads to handle parallel items, such as pages of one document.

The only blocking call named is Bedrock. The post says the rest is asynchronous and that the system can process hundreds of concurrent jobs without contention. Treat “hundreds” as their claim. A new agent is a registered prompt, schema, and model. Terraform then creates queues, IAM roles, and ECS task definitions. The post says new agents inherit MHK’s orchestrator-level HIPAA and SOC 2 attestation rather than a new certification. That inheritance is their description, not an AWS badge.

Each run returns a job ID stored on the case. The post says a case may see three or more executions, and that a structured read of a 30-page record can be reused from S3 under the client KMS key. The page count is their example.

The diagram: labeled boxes and failure or isolation edges

Drawn flow: Cognito and the TLS 1.3 load balancer, Orchestration Core, Controller Invoke Queue, then Workflow Engine Controller. The next boxes run right to left: Agent Invoke Queue, LLM agents on Fargate, Amazon Bedrock. The data row is RDS, then S3, then KMS as a peer, not S3 and RDS behind KMS. There is no client or upstream box. CloudWatch is the side box already drawn: metrics, token counts, and content hashes.

• Database wall: the case study says only the core reads the database. No arrow on this diagram touches RDS. The only solid edges are the six flow arrows. DLQ and SpEL skip have no edges either.
• Token scope: an agent token cannot read another step, workflow, or client. A foreign KMS key does not decrypt the object.
• Depth and skip: a failed task does not block sibling steps; the dead-letter queue catches it. SpEL can drop a whole branch.
• Validation reject: schema failure, a failed source cross-check, or a missed confidence threshold stops the output. The post does not publish the threshold value.
• Network: no path from the database subnet to the internet. Service calls stay on VPC endpoints.

What the source does not claim (preview, case study, or limits)

This is one customer write-up from September 30, 2026. “HIPAA-eligible” and the orchestrator-level HIPAA and SOC 2 attestation are the post’s words about MHK, not a badge for every Bedrock account. Reported results, not an independent audit: intake from 5–10 minutes to under 1 minute with a human still checking, director review described as a 30-second decision after evidence was gathered, 90 percent less manual review, and about 85 percent faster delivery. The “3+ months” and “3 to 6 months” lines stay side by side. Conversational interfaces and Marketplace are the case study’s forward look, and they are not on this diagram. The post does not place AgentCore or a token price in that future.

FAQ

Does the MHK case study say controllers and agents read the database directly?

No. The September 30, 2026 post says the Agent Orchestration Core on Fargate is the only component that accesses the database. Controllers and agents go through that core’s API. RDS for MySQL 8.4 stores workflow definitions and execution state.

What can an agent capability token do, according to the case study?

An agent-scoped token can read its step’s input, write its own result, call the LLM through the proxy, and upload artifacts. A controller-scoped token can read workflow and job data, dispatch agent tasks, and create step executions. Tokens are minted per dispatch with KMS, and each client has a separate KMS key for S3.

Are the 90 percent and two-week figures independent measurements?

No. They are outcomes the AWS case study attributes to MHK. It also says intake dropped from 5–10 minutes to under 1 minute with human verification, and it states the old build cycle both as 3+ months and as 3 to 6 months. Do not treat those as one audited number or as a Bedrock service limit.

Conclusion

Label the core, the two SQS queues, Fargate controller and agents, Bedrock as the model hop, and the per-client KMS boundary around S3 and RDS. Keep the 90 percent and sub-minute figures in a caption as the case study’s report, and do not merge the “3+ months” and “3 to 6 months” lines. The only source is the MHK architecture post. More diagrams are on the ByteDiagram blog.