Red HatEvan Shortiss, Ben WilcockExplainer
AI coding agents can generate services quickly, but they may miss organization-specific architecture, ownership, and compliance rules stored in an internal developer portal. A demo connects Claude Code to a Backstage-based Red Hat Developer Hub through Backstage CLI actions, allowing the agent to query domains, components, APIs, software templates, and TechDocs before proposing a design. In a simulated Parasol Insurance catalog with more than 500 entities across 14 domains, the agent finds an existing but unrelated reconciliation service and resolves a Claims–Billing messaging conflict by keeping IBM MQ at the payment boundary and publishing internal events to Kafka. It then uses catalog relationships and specifications to identify integrations and produces a Technology Decision Summary that cites the sources behind each choice, making the resulting decisions reviewable and traceable.
The demo uses a simulated Parasol Insurance catalog containing more than 500 entities across 14 business domains. It presents the developer portal as an organizational context layer for AI agents, with domain rules, system relationships, APIs, templates, and TechDocs available through Red Hat Developer Hub.
The RHDH Agentic project gives Claude Code a catalog-explore skill that executes Backstage CLI catalog and TechDocs actions against Red Hat Developer Hub; MCP is also supported. The agent progressively queries domains, systems, components, dependencies, API specifications, templates, and governance handbooks, then proposes a bridge between Billing's IBM MQ channel and Claims' Kafka topics and records the supporting sources in a Technology Decision Summary.
The catalog distinguishes the existing Billing and Payments payment-reconciliation-service from the Claims service needed for outbound claim settlements, preventing an incorrect reuse assumption.
Claims prefers Kafka for asynchronous events, while Billing requires IBM MQ for payment transaction messaging; the proposed bridge keeps IBM MQ at the cross-domain payment boundary and publishes internal reconciliation events to Kafka.
A Technology Decision Summary links architectural choices and cross-domain conflict resolutions to catalog entities and TechDocs, giving tech leads and auditors traceable evidence.
It follows Billing's requirement that payment transaction messaging use IBM MQ with guaranteed delivery, rather than defaulting to Kafka. The proposed bridge consumes settlement files through the Billing IBM MQ channel and publishes reconciliation events to Claims Kafka topics internally.
The agent checks catalog ownership, system membership, and dependencies instead of relying on the service name alone. It finds that the existing payment-reconciliation-service belongs to Billing and handles incoming premium payments, not outbound claim settlements.
The agent produces a Technology Decision Summary that cites the catalog source behind each choice and identifies cross-domain conflicts. Reviewers can verify the cited catalog entities and governance documentation, while auditors can trace compliance decisions to their source.
Summaries are generated from the original by a language model. Check the original before relying on it.
See the idea
Backstage can act as an engineering context boundary: catalog entities, templates, and TechDocs inform an agent before it proposes changes. See where validation and review fit.
Keep reading
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
One useful email. Unsubscribe anytime.
