Extending Context into Agents, Memory, and MCP
RAGFlow becomes more than a document question-answering surface when the selected context must drive a workflow. This chapter examines how its Agent canvas connects retrieval to branches, loops, memory, MCP, and external tools, so you can design a minimal evidence-first workflow rather than enable every available capability. The governing judgment is that grounded context may inform an action, but it does not by itself authorize the action.
The canvas turns context into a stateful workflow
A Chat assistant is mainly organized around knowledge-base questions and multi-turn conversation. RAGFlow’s Agent capability is for a different shape of problem: classify an input, retrieve information, call a business system, transform data, and return a result through several connected steps. The no-code canvas expresses that shape as components and connections. The connections are not merely visual decoration; they define which node runs next and which output becomes available to it.
A simple after-sales workflow makes the distinction concrete. The Begin component receives the customer’s question. A Categorize component can route installation questions differently from questions about an existing order. A Retrieval component can search product documentation. An Agent component can interpret the retrieved content and decide whether the request needs another capability. A Message component presents the result. If the customer asks for an order status, an HTTP or database component may query an external system instead of forcing the knowledge base to answer a question it cannot know.
The canvas runtime owns state and dependency resolution. Components exchange variables such as the current query, retrieved formalized content, chunk collections, or generated text. A later component can reference an earlier output, and the scheduler holds a node until its required inputs are available. Sequential paths run in order; Switch and Categorize choose an exit; Iteration repeats a sub-process. Exception paths can route a failure or supply a configured fallback. A component that is not connected to the execution path does not run, which is a useful reminder that a declared capability is not necessarily part of a particular request.
The boundary between data and control is important. A Retrieval component can be a fixed stage: the workflow always looks up product material before the Agent answers. It can also be offered as a tool under the Agent, allowing the model to decide when retrieval is needed. The fixed form makes the evidence path predictable. The tool form is more flexible for mixed tasks, but it gives the model another planning decision and makes the prompt, tool description, retry policy, and trace important to the outcome. For regular Q&A, RAGFlow’s documentation recommends preferring the simpler workflow when planning is not actually required.
An evidence-first design makes the boundary explicit in the Agent prompt. The Agent should be told which retrieved variable contains the context, what to do when it is insufficient, and what it must not invent. The model can reason over a retrieval result, but it should not treat a tool description, a generated keyword, or its own prior knowledge as a replacement for the source evidence. Citation can be enabled so the resulting response retains a link to the selected knowledge fragments.
Structured output adds a second interface. Instead of returning only prose, an Agent can be configured to emit a JSON-shaped result with named fields and types. A downstream Code, HTTP, SQL, or condition component can then consume those fields without parsing a paragraph. This is useful when the Agent must extract a product identifier, route a request, or prepare a bounded action. It also creates a contract to validate: malformed output, missing fields, and a plausible but unsupported value should be treated as workflow failures rather than silently passed to a side-effecting node.