Mintplex-Labs/anything-llm
1
0
Fork 0
mirror of https://github.com/Mintplex-Labs/anything-llm.git synced 2026-07-21 01:25:28 -04:00
Code Issues 328 Packages Projects Releases 10 Wiki Activity

[GH-ISSUE #5041] [FEAT]: Raw Input Mode for Agent Flows #3161

New Issue
Open
opened 2026-02-22 18:32:50 -05:00 by yindo · 0 comments
yindo commented 2026-02-22 18:32:50 -05:00
Owner
Copy Link
Copy Source

Originally created by @elevatingcreativity on GitHub (Feb 21, 2026).
Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/5041

What would you like to see?

Problem

When an agent flow is invoked via @agent FlowName , the current architecture routes
everything through the LLM twice:

  1. The LLM reads the user's full message and decides to call the agent flow tool, generating its own
    version of the input as a function argument
  2. After the flow executes, the LLM processes the result again before returning it to the user

This creates several serious problems when the input is a large block of text (e.g. a document being
passed for processing):

  • Token limits — the full document must fit within the LLM's context window twice (once as input, once
    as output when the LLM reconstructs it as a function argument). This frequently exceeds limits even for
    models with large context windows.
  • Data fidelity — the LLM may paraphrase, truncate, or subtly alter the input text when passing it as a
    function argument, rather than preserving it verbatim. For document processing this is unacceptable.
  • Cost and latency — large documents being echoed through an LLM call adds significant cost and delay
    with no benefit.

Proposed Solution

Add a Raw Input Mode toggle to the Agent Flow configuration (on the flow's info node). When enabled, the LLM still decides to invoke the flow as a tool, but the argument it generates is discarded server-side. Instead, the original user text is extracted directly from the message and injected as the first input variable before the flow executes.

This seems appropriate for flows that act as pure text processors — where the flow receives a document,
runs it through a pipeline of steps, and returns a result — with no need for the LLM to interpret or
reformat the input.

We have an initial implementation working across three files:

  • frontend/src/pages/Admin/AgentBuilder/nodes/FlowInfoNode/index.jsx — toggle UI on the flow info node
  • frontend/src/pages/Admin/AgentBuilder/index.jsx — persists the rawInput flag when saving/loading
    flows
  • server/utils/agentFlows/index.js — server-side bypass that extracts raw text from the user's original
    message, strips the @agent FlowName prefix, and injects it directly as the first variable argument

Proof-of-concept code is available at:
https://github.com/elevatingcreativity/anything-llm/tree/agent-flow-raw-input

I can do a PR if this seems acceptable as a solution.

Originally created by @elevatingcreativity on GitHub (Feb 21, 2026). Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/5041 ### What would you like to see? ### Problem When an agent flow is invoked via @agent FlowName <input text>, the current architecture routes everything through the LLM twice: 1. The LLM reads the user's full message and decides to call the agent flow tool, generating its own version of the input as a function argument 2. After the flow executes, the LLM processes the result again before returning it to the user This creates several serious problems when the input is a large block of text (e.g. a document being passed for processing): - Token limits — the full document must fit within the LLM's context window twice (once as input, once as output when the LLM reconstructs it as a function argument). This frequently exceeds limits even for models with large context windows. - Data fidelity — the LLM may paraphrase, truncate, or subtly alter the input text when passing it as a function argument, rather than preserving it verbatim. For document processing this is unacceptable. - Cost and latency — large documents being echoed through an LLM call adds significant cost and delay with no benefit. ### Proposed Solution Add a Raw Input Mode toggle to the Agent Flow configuration (on the flow's info node). When enabled, the LLM still decides to invoke the flow as a tool, but the argument it generates is discarded server-side. Instead, the original user text is extracted directly from the message and injected as the first input variable before the flow executes. This seems appropriate for flows that act as pure text processors — where the flow receives a document, runs it through a pipeline of steps, and returns a result — with no need for the LLM to interpret or reformat the input. We have an initial implementation working across three files: - frontend/src/pages/Admin/AgentBuilder/nodes/FlowInfoNode/index.jsx — toggle UI on the flow info node - frontend/src/pages/Admin/AgentBuilder/index.jsx — persists the rawInput flag when saving/loading flows - server/utils/agentFlows/index.js — server-side bypass that extracts raw text from the user's original message, strips the @agent FlowName prefix, and injects it directly as the first variable argument Proof-of-concept code is available at: https://github.com/elevatingcreativity/anything-llm/tree/agent-flow-raw-input I can do a PR if this seems acceptable as a solution.
yindo added the enhancementfeature request labels 2026-02-22 18:32:50 -05:00
yindo changed title from [FEAT]: Raw Input Mode for Agent Flows to [GH-ISSUE #5041] [FEAT]: Raw Input Mode for Agent Flows 2026-06-05 14:50:39 -04:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Desktop
Docker
Integration Request
Integration Request
OS: Linux
OS: Mobile
OS: Windows
UI/UX
blocked
bug
bug
core-team-only
documentation
duplicate
embed-widget
enhancement
feature request
github_actions
good first issue
investigating
needs info / can't replicate
possible bug
pull-request
Mirrored from GitHub Pull Request
 question
stage: specifications
wontfix
No Label enhancement feature request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Mintplex-Labs/anything-llm#3161
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?