AWS Partner Network (APN) Blog
How ASCENDING’s Jarvis Registry bridges agents and developer tools
By: Ryo Hang, Technical Cofounder – ASCENDING
By: Celeste Shao, AI Specialist – ASCENDING
By: Jason Zhang, CTO – Vegogarden
By: Lu Zou, Sr. Partner Solution Architect – AWS
 |
| Ascending |
 |
Your agents are deployed on Amazon Bedrock AgentCore. Now, people across your teams are wondering if they can use it with their preferred developer tool, whether that’s Claude Desktop, Visual Studio Code (VS Code), Cursor, or GitHub Copilot. That’s where the complexity starts, and you hit the last mile: making your agents reachable from an integrated development environment (IDE) safely, with the right identity, authorization, and discovery controls. This is the experience layer: the authentication, authorization, discovery, and developer UX infrastructure that sits between your deployed agents and the tools people actually work in.
In this post, we walk through the experience layer challenge, show the architecture you’d need to build yourself, and introduce an open source solution that handles it for you.
The experience layer for usability
The gap between “deployed” and “usable” comes down to a recurring set of integration problems:
- Identity – The agent and downstream tools need to trust who the caller is without prompting again, which means integrating with the organization’s identity provider (IdP).
- Authorization – After identity is established, the platform has to decide which agents, tools, and data each user can reach, often with policies that vary by team or environment.
- Token management – Every downstream tool brings its own OAuth lifecycle: token exchange, refresh, and re-auth when an agent calls Jira, GitHub, or internal APIs.
- Interactive re-auth. Tools sometimes need to pause mid-call to ask for input or fresh credentials, then resume cleanly inside the copilot.
- Discovery – The right agents and tools need to surface at the right moment, filtered by context, rather than overwhelming the client with the full catalog.
This gets especially complex when you multiply it by every IDE the business cares about and every agent your team ships. The experience layer quickly becomes a larger investment than the agents themselves.
The components of an experience layer
The following are the components of the experience layer:
- A protocol gateway – Supports Model Context Protocol (MCP) MCP and Agent2Agent (A2A) to clients on one side and translates to Amazon Bedrock AgentCore Runtime, Amazon Bedrock AgentCore Gateway, and downstream tools on the other. You’ll handle multiple MCP transports, such as stdio, streamable HTTP, or server-sent events (SSE), and A2A variants such as JSON-RPC, gRPC, or HTTP+JSON). Streaming introduces the most complexity: interleaved progress events, sessions resumed mid-call, and a spec that keeps moving.
- A registry with resource discovery – A catalog of which agents and tools exist, who owns them, and who can reach them. Beyond cataloging, it provides the ability to surface the right things to the right user at the right moment, filtered by identity, role, and conversation context. Without this, every client is configured by hand, and every governance question becomes a manual audit.
- An identity service – Integrates with your IdP (such as Okta, Microsoft Entra, Amazon Cognito, or Auth0) and issues tokens that Amazon Bedrock AgentCore Runtime trusts as a custom JSON Web Token (JWT) authorizer: asymmetric keys, a /.well-known/jwks.json endpoint, and a key rotation story that doesn’t require redeploying agents.
- The OAuth lifecycle, end to end – Every downstream tool has its own OAuth requirements: token exchange, refresh, scope changes, and secure storage. When a tool returns 401 mid-call, the gateway has to detect it, kick off the right flow through MCP elicitation (where the client supports it), and deep-link the user back to their actual VS Code window or Claude Desktop session, not a generic browser tab. Done right, re-auth feels instant. Done wrong, the user hunts for their IDE every time.
- End-to-end observability – A single audit trail joining the gateway, the agent runtime, and downstream tools: “user X called tool Y through agent Z and got result W.”
The following diagram shows the components and interconnections for a self-built experience layer.
Figure 1: Experience layer components
All of these are solvable individually but maintaining them together is a sustained engineering investment that grows with every new agent and copilot you add.
What ASCENDING built after the fifth time
ASCENDING is an AWS Partner that has spent nearly a decade helping customers build on AWS. Over the last 2 years, that work has focused on AI and automation: assistants, Retrieval Augmented Generation (RAG) systems, and autonomous agents deployed on Amazon Bedrock AgentCore.
After their fifth AgentCore integration, the ASCENDING team recognized a pattern: every customer needed the same experience layer, and every customer was building it from scratch. The work was similar enough to be recognizable each time, but different enough that no previous solution was directly reusable.
For Amazon Bedrock AgentCore, ASCENDING built an open source experience layer, the Jarvis Registry, which includes a protocol gateway, registry, resource discovery, identity service, OAuth orchestrator, in-session auth UX, deep-link return paths, and end-to-end observability. It’s packaged as a self-contained platform that runs inside the customer’s AWS environment and integrates with AgentCore Runtime as a first-class identity and routing target. With Jarvis Registry, customers can focus on building agents without worrying about the integration infrastructure needed to make them accessible from every IDE.
The following graphic shows the Amazon Bedrock AgentCore and Jarvis interaction layer.
Figure 2: Jarvis Registry interaction layer
What it looks like for users
Here’s what that looks like in practice. Vegogarden is a customer running two very different workloads on Amazon Bedrock AgentCore. The first is a distributed fleet of customer-support agents that look up product information and place orders on behalf of customers. The second is a cluster of data-analytics MCP servers that expose detailed sales, inventory, and operations data to internal users. Both workloads needed an experience layer, and the agents and MCP servers needed to be reachable from the tools their users actually used.With Jarvis sitting between the copilots and AgentCore, the same agents and MCP servers now serve two distinct workflows.
Business users in Claude Desktop. A regional manager asks the analytics agent to render a bar chart of last quarter’s revenue, broken down by region. Support specialists ask the support agent to summarize closed tickets for a given week, suggest responses for the email they’re writing, or surface similar past cases from the company’s historical database. No dashboards, no copy-pasting, no engineering tickets to “give me access.”
Engineers in VS Code. When something doesn’t work correctly, the on-call engineer calls the same agent from VS Code. Jarvis’s audit trail shows exactly which tools and APIs were called, and where the chain broke. Triage that used to require pulling logs from three separate systems now happens in a single conversation.
Department-scoped access. Each team only sees what they should. Sales can’t reach engineering tools, support can’t query payroll data, engineers don’t accidentally pull personally identifiable information (PII). You define these access rules one time in the registry, and Jarvis Registry enforces them uniformly across every IDE the business uses.
The impact on day-to-day work is harder to quantify but immediately noticeable. Business users began answering their own questions through the tools they already use, reducing the volume of one-time requests routed to engineering. On-call engineers saw fewer off-hours pages for issues that turned out to be business-logic questions rather than system failures. The agents Vegogarden’s team built reached the people they were built for.
Try it
In this post, we showed how Amazon Bedrock AgentCore handles production agent deployment and how the Jarvis Registry adds the experience layer that makes those agents accessible from the IDEs and copilots your team uses. Together, they provide a complete platform for building, deploying, and consuming agents across your organization.
The Jarvis Registry is available as open source. A two-minute demo shows a developer calling a production AgentCore agent from inside their IDE, encountering an upstream auth challenge, and resolving it in place—the experience layer at work. To deploy the Jarvis Registry in your own AWS environment, integrate it with your IdP, and extend it for your team’s use cases, reach out to the ASCENDING team.
ASCENDING – AWS Partner spotlight
ASCENDING is an AWS Partner focused on AI-driven solutions and cloud transformation. As an AWS Agentic AI launch partner, ASCENDING helps customers accelerate AI adoption with solutions such as Jarvis, enabling organizations to build and integrate production-ready AI agents more efficiently on AWS. We’ve also released several AI solutions as open source to support the broader community and help organizations innovate faster.