Quarkus LangChain4j

Quarkus LangChain4j is an extension that integrates Large Language Models (LLMs) into Quarkus applications using a declarative, developer-friendly API. It is built on top of the LangChain4j library but provides an opinionated, enterprise-grade integration tailored for the Quarkus ecosystem.

Key Capabilities:

• Declarative AI Services: Use Java interfaces and annotations to call LLMs with minimal boilerplate.
• Optimized for Quarkus: Fast startup, native-image ready, and low footprint.
• Advanced AI Patterns: Support for tool calling (function calling), agentic patterns, and chat memory for multi-turn interactions.
• RAG Support: Easy integration with vector stores like Redis, Chroma, and Infinispan for Retrieval-Augmented Generation.
• Built-in Observability: Integrated logs, metrics, and tracing.
• Developer Experience: Includes Dev UI for visual introspection and Dev Services for automatic embedding stores and model serving.

This sample demonstrates dynamic Agent-to-Agent (A2A) discovery using Apicurio Registry as a centralized store for agent cards.

In this pattern, a 'Classifier' agent (using a local LLM) receives a request and determines which specialized agent should handle it. Instead of using hardcoded URLs or compile-time dependencies, the system discovers specialized agents (e.g., billing, technical, shipping) at runtime by querying the Apicurio Registry for artifacts of type AGENT_CARD. These agents are then accessed via the @RegistryAgent annotation, which acts as an A2A client.

Customer Request
       │
       ▼
┌──────────────┐     ┌───────────────────┐
│  Classifier  │────▶│ Apicurio Registry │
│  (local LLM) │     │  ┌─────────────┐  │
└──────────────┘     │  │billing-agent│  │
       │             │  │tech-agent   │  │
       ▼             │  │ship-agent   │  │
┌──────────────┐     │  └─────────────┘  │
│ @RegistryAgent│◀───│   AGENT_CARD      │
│  (A2A client) │     └───────────────────┘
└──────────────┘

Semantic compression is a strategy to manage long chat histories by using an LLM to summarize messages in place, rather than simply truncating or evicting them. This approach preserves critical context (names, dates, action items) while staying within the model's token limits.

Key Benefits

• Prevents Token-Limit Errors: Avoids failed requests caused by exceeding the model's context window.
• Reduces Cost and Latency: Shortens prompts, which lowers API costs and improves response times.

Implementation Strategy

In Quarkus LangChain4j, you implement semantic compression by providing a custom ChatMemoryStore CDI bean. This bean wraps an existing memory store, monitors the history length or token count against a threshold, and triggers a summarization model when the threshold is exceeded. The summary is then embedded into a system message to maintain continuity.

Warning: Semantic compression only applies to textual chat memories. Do not use this strategy for vision or other non-text data.

You can manage embeddings for different domains by configuring multiple named stores. Each store can have its own dimension, label, index name, and database.

Important Isolation Rules:

• All named stores share the same org.neo4j.driver.Driver and connect to the same Neo4j instance.
• To keep data isolated within a single database (Neo4j Community Edition), use a distinct label, index-name, and embedding-property per store.
• To use different databases, you must have Neo4j Enterprise Edition. On Community Edition, you must set database-name to neo4j.

Configuration Example: To configure a store named products:

quarkus.langchain4j.neo4j.products.database-name=neo4j
quarkus.langchain4j.neo4j.products.dimension=1536
quarkus.langchain4j.neo4j.products.label=Product
quarkus.langchain4j.neo4j.products.index-name=product_vector

Injection: Use the @EmbeddingStoreName qualifier to inject a specific named store:

@Inject
@EmbeddingStoreName("products")
EmbeddingStore<TextSegment> productsStore;

Disabling Stores:

• Disable the default store: quarkus.langchain4j.neo4j.default-store-enabled=false
• Skip a specific named store at build time: quarkus.langchain4j.neo4j.<store-name>.enabled=false

The Secure MCP implementation uses the Streamable HTTP transport protocol and relies on GitHub OAuth2 for identity.

Authentication Flow

1. Client Login: The MCP Client (a Quarkus application) initiates a GitHub OAuth2 authorization code flow.
2. Token Propagation: The client acquires a GitHub access token and propagates it as a Bearer token in HTTP requests to the MCP server.
3. Server Validation: The Quarkus MCP server validates the bearer token.

Authorization and Permissions

Access to MCP tools is restricted by permissions. Specifically, the MCP server endpoint for tools requires the read:name permission.

How permissions are granted:

• The MCP server augments the identity derived from the GitHub bearer token.
• It checks a database for a record matching the GitHub account name that possesses the read:name permission.
• If a match is found, the permission is added to the security identity.