AWS Agent Registry hit general availability last month, and the timing lines up with something a lot of platform teams have been quietly panicking about: agent sprawl. If you’ve got twelve teams each spinning up their own Bedrock AgentCore Runtime deployments, wiring up MCP servers, and calling whatever tools they found convenient, you don’t have an AI strategy — you have shadow IT with better marketing. This article is about enterprise agent architecture patterns for actually running Agent Registry and AgentCore Runtime together at scale, across dozens or hundreds of AWS accounts, without turning your security team into a support desk.
We’ve already covered the mechanics of how the registry models agents, tools, and skills as governed resources, how approval workflows fire, and how semantic search indexes your catalog in a companion piece. This one skips that ground entirely. Instead we’re talking about the stuff that actually determines whether this scales past a pilot: account structure, access scoping, and version management.
Enterprise Agent Architecture Patterns Start With Account Structure
The single biggest mistake we see is treating Agent Registry like a per-team tool. It isn’t one. It’s a catalog, and catalogs work best when there’s exactly one of them (per environment tier, anyway). The pattern that holds up is a central registry hosted in a dedicated shared-services or governance account inside your AWS Organizations structure — the same account, ideally, where you already run things like your central logging bucket or your Service Catalog portfolios.
From there, resource sharing happens through AWS Resource Access Manager, letting member accounts in application OUs consume registry entries without duplicating them or punching holes in account boundaries. A registered agent record lives in the governance account; the teams building AgentCore Runtime deployments in their own accounts reference it, they don’t own copies of it. That’s the whole point of a registry — one source of truth, discoverable everywhere, owned nowhere except the team responsible for governance.
# Share an Agent Registry resource from the governance account
# to specific OUs via AWS RAM
aws ram create-resource-share \
--name "agent-registry-catalog-share" \
--resource-arns "arn:aws:agent-registry:us-east-1:111122223333:catalog/enterprise-catalog" \
--principals "arn:aws:organizations::111122223333:ou/o-abc1234567/ou-ab12-34567890" \
--allow-external-principals false \
--region us-east-1
Wire this into your landing zone the same way you’d share a VPC subnet or a Transit Gateway attachment — as a standard part of account vending. New account gets created, it lands in the right OU, it automatically has read access to the catalog. No ticket, no tribal knowledge required.
Least Privilege Isn’t Optional When Agents Can Act
Here’s the uncomfortable truth about registering a tool in a catalog: discoverability and access are two different problems, and a lot of teams accidentally solve them with the same IAM role. A registry entry that’s easy to find but backed by an overly broad execution role is worse than no registry at all, because now it’s easy to find and easy to misuse.
The pattern that works is scoping IAM per registered agent and per tool, not per team and definitely not per account. Every AgentCore Runtime agent gets its own execution role, and that role’s policy references the specific resource ARNs the tool actually touches — not a wildcard, not “the S3 buckets in this account.” If an agent’s job is to read from one DynamoDB table and call one Lambda function, its policy says exactly that.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "InvokeOneRegisteredTool",
"Effect": "Allow",
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-east-1:222233334444:function:order-status-tool"
},
{
"Sid": "ReadOneTable",
"Effect": "Allow",
"Action": ["dynamodb:GetItem", "dynamodb:Query"],
"Resource": "arn:aws:dynamodb:us-east-1:222233334444:table/orders",
"Condition": {
"StringEquals": { "dynamodb:LeadingKeys": "${aws:PrincipalTag/tenant}" }
}
}
]
}
Follow IAM least-privilege guidance to the letter here, and add resource-based policies on the tool side too — a Lambda function backing a registered tool should have a resource policy that only trusts the specific AgentCore Runtime execution roles you expect to call it, not “any principal in this account.” That’s a belt-and-suspenders setup: the agent’s identity policy says what it’s allowed to touch, and the tool’s resource policy says who’s allowed to touch it. A registry listing that looks trustworthy doesn’t mean the underlying role is — check both.
Guardrails belong at the AgentCore Runtime layer too, not just IAM. Session-level guardrails and tool-invocation limits on Bedrock AgentCore Runtime stop an agent from chaining tool calls into something its author never intended, even if every individual permission was scoped correctly. IAM stops the blast radius; guardrails stop the agent from finding creative ways to reach the edge of it.
Versioning Agents Without Breaking Every Consumer at Once
This is where most homegrown catalogs fall apart, and it’s exactly where Agent Registry’s structure earns its keep, if you use it deliberately. Treat every registry record like a package with a real semantic version — major.minor.patch — and mean it. A patch bump for a prompt tweak, a minor bump for a new optional tool, a major bump for anything that changes the agent’s input/output contract or removes a capability a consumer might depend on.
The registry record is the metadata; AgentCore Runtime versioning and aliasing is what actually lets you ship the new version without yanking the rug out from under existing consumers. Runtime versions are immutable snapshots, and aliases point at a version — so you roll a new agent version into an alias, watch it, and only then move the alias that production traffic actually points to. Consumers who pinned a registry record to a specific alias never notice the change happen mid-flight. Consumers who pinned to a version see nothing until they explicitly bump.
# Create a new immutable version of an AgentCore Runtime agent
aws bedrock-agentcore create-agent-runtime-version \
--agent-runtime-id agentruntime-8f3k2 \
--description "v2.3.0 - adds refund-lookup tool"
# Point a canary alias at the new version for a subset of traffic
aws bedrock-agentcore update-agent-runtime-endpoint \
--agent-runtime-id agentruntime-8f3k2 \
--endpoint-name canary \
--agent-runtime-version 7
# Only after validation, move the production alias
aws bedrock-agentcore update-agent-runtime-endpoint \
--agent-runtime-id agentruntime-8f3k2 \
--endpoint-name production \
--agent-runtime-version 7
Deprecation should be a state in the registry record, not a deletion. Mark the old version deprecated with a sunset date, let the approval workflow require sign-off before anyone new can bind to it, and keep it invokable until every consumer has migrated or the sunset date passes. Rollback is just moving the alias back — which is why aliasing beats hard-coding version numbers into every downstream agent’s configuration. If v2.3.0 turns out to hallucinate refund amounts, you move one pointer, not fifty configs.
Putting It Together
None of this is exotic — it’s the same governance instincts you already apply to VPCs, IAM roles, and CI/CD pipelines, pointed at a newer kind of workload. A shared-services account hosting the catalog, RAM handling the cross-account plumbing, IAM roles scoped down to the tool an agent actually needs, and AgentCore Runtime versioning doing the heavy lifting on safe rollouts. As covered in the AWS machine learning blog on managing agents at scale and this month’s Weekly Roundup, the registry itself is table stakes now. Agent sprawl doesn’t get solved by buying a registry. It gets solved by treating agents like the production infrastructure they are.
At Enkompass (enkompass.net), this is our home turf. We design AWS architectures that survive contact with production — and the 3 AM page that comes with it. We’ve stood up exactly this pattern for clients: a governance account fronting an Agent Registry catalog shared via RAM across a dozen application accounts, each agent locked to a scoped IAM role it can’t quietly outgrow. If you’d rather have seasoned cloud people handle it instead of learning the hard way at 2 AM, let’s talk. Reach out through our contact page or call us directly at +1-828-436-5667 — we’ll help you turn this from a someday-project into a done-deal.