Beyond the Chatbot: A Technical Agent with RAG, Scraping, and Vision

The problem is not merely finding an answer

When someone encounters a technical error, the required information is rarely concentrated in one place. Documentation explains expected behavior. Forums record real situations, limitations, and workarounds. A screenshot reveals details that may never appear in the written description.

A conventional chatbot receives the question and attempts to answer from the model's existing context. That may work for common questions, but it becomes less reliable when the answer depends on a specific version, an error message, a visual configuration, or a poorly documented edge case.

This project took a different approach: build an agent that investigates before it answers.

Three sources with three different roles

The agent works with three primary forms of evidence:

• technical documentation, used as the reference for features, parameters, and expected behavior;
• forum discussions, useful for finding real failures, limitations, and practical workarounds;
• images, especially screenshots of errors, settings, and interfaces.

These sources do not carry equal authority. Official documentation is the first reference for contracts and intended behavior. Forum material extends the investigation when the documentation does not cover a problem or when real usage differs from theory. An image provides evidence about the user's specific case.

Keeping those roles separate reduces a common retrieval risk: treating every matching passage as equally authoritative.

Preparing the knowledge base

Documents move through an ingestion pipeline, are divided into smaller chunks, and converted into embeddings. Those vectors are stored in PostgreSQL with PGVector alongside metadata describing the source.

Metadata makes it possible to search only the appropriate collection. A question about expected behavior can start with technical documents. An investigation into an unusual error can retrieve reports collected from the forum.

Semantic retrieval does not require the exact words used in the question. It finds passages that are close in meaning and gives the agent a small set of relevant contexts instead of sending the entire knowledge base to the model.

Turning practical experience into searchable knowledge

Technical forums are valuable, but they also contain considerable noise. The scraper therefore focuses on discussions marked as solved.

Using Playwright, it navigates topic listings, detects new discussions, opens each one, and extracts useful elements: the title, original question, accepted solution, category, tags, date, and source URL. Previously collected topics are skipped, making the process incremental.

Collected material is not treated as unquestionable truth. It first passes through the ingestion pipeline and receives its own source metadata. It then becomes a complementary source the agent can consult when the problem calls for practical evidence.

This boundary matters: scraping updates the knowledge base; it does not automatically make every community answer authoritative.

Images become context, not a verdict

When a question includes an image, a vision model examines the visual content first. It can identify error messages, fields, interface states, and other useful signals.

The visual analysis is converted into a textual description and combined with the original question. From that point, the agent continues through the same investigation flow: interpreting the problem, selecting tools, and searching the appropriate sources.

This design keeps responsibilities clear. The vision model describes what it can observe. The reasoning agent connects those observations to documentation and similar cases. A single visual interpretation is never treated as a definitive diagnosis.

A graph controls the investigation

LangGraph organizes the workflow. A conversation begins at the agent node, which may answer directly or request a tool. When retrieval is required, the graph executes the tool and returns its result to the agent for another reasoning step.

Before the flow ends, a critique step checks whether the response actually addresses the question and remains consistent with the available evidence. If it finds a deficiency, the graph allows one controlled retry instead of an indefinite loop.

The graph can also use checkpoint persistence. Conversation state can survive between interactions without depending solely on the memory of the process running the model.

The path of a technical question

A typical request follows this sequence:

1. the system receives a question and, optionally, an image;
2. the vision model converts visual signals into descriptive context;
3. the agent identifies the intention and decides whether retrieval is necessary;
4. documentation is searched to establish expected behavior;
5. forum knowledge is searched when practical cases or workarounds are needed;
6. retrieved passages return with their respective origins;
7. the agent synthesizes a problem-oriented response;
8. a final critique checks clarity and adherence to the evidence.

The value does not come from one tool in isolation. It comes from the way each source participates in the investigation.

Reliability requires explicit boundaries

RAG reduces unsupported answers, but it does not eliminate them. Documentation may be stale, an accepted forum answer may not apply to the current version, and a screenshot may be incomplete.

The system must therefore preserve passage origins, distinguish official material from community content, and communicate uncertainty when evidence is insufficient. It also needs to refresh the index when sources change and limit the amount of context sent to the model.

Scraping introduces another concern: forum structure can change. Selectors, pagination, and access rules require monitoring, and a collection failure must not be mistaken for a lack of knowledge.

The same principle applies to image analysis: visual interpretation should help form hypotheses and locate evidence, not conceal uncertainty behind an overly confident answer.

What this architecture solves

Less generic answers. The agent retrieves material related to the problem before preparing its guidance.

A better balance between theory and practice. Documentation and community experience serve complementary roles.

Less friction when explaining errors. A screenshot can provide signals that would be difficult to transcribe.

Updatable knowledge. New documents and solved discussions can be ingested without rebuilding the agent.

An inspectable flow. The selected tools and retrieved contexts help explain where an answer came from.

Reusable specialization. The same architecture can support different technologies by replacing its sources, instructions, and retrieval criteria.

The main lesson

A good technical agent is not one that immediately answers every question. It knows when investigation is required, selects the appropriate source, and makes clear what supports its conclusion.

Documentation provides the contract. Forums reveal operational reality. Images bring the system closer to the observed problem. When those three perspectives are organized through a controlled workflow, AI moves beyond conversation and becomes a technical investigation layer.