How to Pass Context to a Retool chatAgent Component

If you've tried to pass context from a Retool app into the chatAgent component — component state, query results, selected table rows — you've probably hit a wall. The component is designed to work with a linked Retool AI query, sendMessage() only accepts a string, and there's no built-in way to inject structured data from the rest of your app. This guide covers every working workaround available right now, explains exactly why the current architecture is limiting, and outlines the feature improvements Retool has confirmed are in the pipeline.

Why Is Passing Context to the Retool chatAgent So Hard?

The chatAgent component was built around a tight coupling to a Retool Agents query. When you configure the component, you link it to a specific agent query on page load. That query defines the agent, and the component only accepts user input as a plain string via the sendMessage() method. There is no native support for passing structured objects, arrays, or component state alongside a user message. This means that if you want the agent to know about, say, the rows selected in a nearby table component or results from a map proximity filter, you have to build that context injection yourself — entirely in JavaScript.

The Best Workaround: Stringify Context and Prepend It to sendMessage()

The most reliable short-term workaround confirmed by the Retool team is to manually grab component data, stringify it, and pass it into agentChat.sendMessage() with a natural-language explanation. Here's the pattern:

• Read the component value you want to pass as context (e.g. invoiceTable.selectedRow or gmap1.proximityItems)
• Stringify the data with JSON.stringify()
• Prepend a plain-English label so the LLM understands what the data represents
• Call agentChat1.sendMessage() with the combined string

For example: "[Context: Selected invoices]\n" + JSON.stringify(invoiceTable.selectedRows). It's not elegant, but it works for small-to-medium payloads and gives the agent enough signal to act on the data without needing to call tools to fetch it.

Advanced Workaround: Injecting Messages via an agentInput Variable

One community member built a more sophisticated solution using a custom agentInput variable and a JS query to intercept and augment the message flow before it reaches the agent. The approach works like this:

• Create a variable (e.g. agentInput) to hold the message array and action state (invoke, getLogs, stop)
• In a JS query, read agentChat1.messages to get the latest user message
• Inject a context message into the messages array before the user message: { role: "user", content: JSON.stringify(selectedData) }
• Follow it with the actual user message: { role: "user", content: "**[Context: Map, selected markers]**\n" + userMessage }
• Set agentInput.setValue({ messages, action: "invoke" }) and trigger the invokeAgent query manually
• On success, capture the agentRunId and switch to polling mode: agentInput.setValue({ messages, action: "getLogs", agentRunId })
• Poll until data.status === "COMPLETED", then push the assistant's response back into the message history

This works, but it requires the chatAgent component to NOT be linked to a Retool Agents query — which is currently not supported. The component requires that link, which is the core bottleneck. Retool has acknowledged this and flagged it as a priority fix.

The Static Workaround: Load Context into a Database First

For data that doesn't change frequently, the cleanest option is to write it to a database table and give your Retool agent a tool that can query that table. This removes the need to thread component state through the UI entirely and keeps context retrieval inside the agent's own execution flow. The tradeoff is latency and an extra write step, but for snapshot-style data (daily reports, staged records, cached API responses) it works reliably at scale.

What Retool Is Building to Fix This Properly

Based on the Retool team's responses in the community thread, here's what's confirmed or in progress:

• Support Variables and In-Memory Context Hub for Agents — a session-scoped data store that agents can read from, similar to how localStorage works for regular Retool apps. You'd write context to this hub via an event handler, and the agent would consume it automatically.
• Allow "Query to Trigger" to accept non-agent queries — removing the hard requirement that the linked query must be a Retool AI query, which would unlock the custom JS injection patterns described above.
• Component state subscription for agents — a feature request has been filed to let agents subscribe to the live state of specific components or entire pages, reducing the need to manually thread data.
• New chatAgent methods — including setAgentId() and setQueryTargetId() so agents can be reconfigured dynamically at runtime.
• sendMessage() accepting arrays — to allow passing multiple messages in a single call (one for context, one for the user message), matching how the underlying message array already works.

Context Engineering in Retool: What to Do Right Now

Until these features ship, the practical priority order is: (1) use the stringify-and-prepend pattern for small, selective context; (2) use a DB-backed tool for large or frequently reused datasets; (3) avoid subscribing the agent to entire page state — context windows fill fast and indiscriminate injection hurts response quality. Think carefully about what context the agent actually needs per interaction and pass only that. The concept of context engineering — deliberately curating what an LLM sees — applies just as much inside a Retool app as it does in any production AI system.

The chatAgent component is still maturing, but the trajectory is clear. In the meantime, the workarounds above will get you shipping. Watch the original community thread for updates as Retool rolls out fixes.