Conversational Support Agent
A tool-using support agent that answers questions against your own documentation and escalates when it cannot.
Demonstration content
This blueprint page exists to exercise the catalog, its filters and the page template. It does not describe a released blueprint, and the sections below are placeholders rather than real implementation guidance.
No source code, demo or external documentation links have been published for this blueprint yet.
Overview
A tool-using support agent that answers questions against your own documentation and escalates when it cannot.
This page shows the structure a blueprint detail page uses. The problem statement and component list below are real design context; the deployment and usage sections are placeholders.
Problem addressed
Support teams answer the same documented questions repeatedly, while the genuinely novel cases — the ones that need a human — wait behind them in the same queue.
Architecture
[1] Retrieval layer
[2] Agent loop
[3] Tool interface
[4] Inference backend
[5] Audit logA concrete architecture diagram will replace this sketch when the blueprint is published.
Key components
- Retrieval layer — Indexes your documentation and returns passages relevant to a question.
- Agent loop — Decides whether to answer, retrieve more context, or escalate.
- Tool interface — Exposes ticket lookup and escalation as validated tools.
- Inference backend — An
llm-inferencedeployment serving the chat model. - Audit log — Records every question, retrieval and escalation decision.
Prerequisites
- An inference endpoint. On MareNostrum 5, start one with
llm-inference api start— see the quickstart. - The base URL of that endpoint,
http://<host>:<port>, as printed byapi start. - A model ID listed by
llm-inference model listwithSUPPORTED=yes.
Deployment instructions
Not yet available
This is demonstration content. No deployable artifacts exist for this blueprint, so no deployment commands are given here — an invented command would be worse than an acknowledged gap.
When the blueprint is published, this section will contain the repository location and the steps to deploy it.
Configuration
The configuration surface will be documented here. It is expected to cover at least:
| Setting | Purpose |
|---|---|
<ENDPOINT_BASE_URL> |
Base URL of the inference endpoint, e.g. http://nid001:45123. |
<MODEL_ID> |
Identifier of the model to call. |
Usage
DraftWorked usage examples will be added with the published blueprint.
Security considerations
These apply to this blueprint’s design and are not placeholders — they hold regardless of implementation:
- Model output is untrusted input. Validate every tool call independently before acting on it. See Function calling.
- The inference endpoint has no authentication.
api startexposes a plain HTTP port inside the MN5 network; anything reachable from there can use your allocation. - Enforce authorization in your own code, on the end user’s identity — not on what the model requests.
- Treat prompt content as data subject to your retention and access rules; it is written to the shared filesystem.
The full guidance is in Security notes.
Observability
Per-request latency and success or failure are recorded for every request; where those land and how to inspect them is described in Logs and monitoring. Application-level outcome metrics specific to this blueprint will be listed here on publication.
Limitations
Warning
This page is demonstration content. It has no implementation behind it, no measured performance characteristics and no validated deployment path. Do not treat the architecture sketch above as a tested design.
Next steps
- Read the blueprint catalog for other blueprints.
- Get an inference endpoint running:
llm-inferencequickstart. - Understand the serving concepts involved: LLM Inference Handbook.