> For the complete documentation index, see [llms.txt](https://docs.rewst.help/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rewst.help/rewst-documentation/documentation/rewst-agent/fabric-in-rewst.md). # Fabric in Rewst ## What is Fabric? Normally, to use an integration connected to Rewst, you build a workflow. Fabric is the shortcut around that. It lets AI look at your installed integrations, see the full menu of things they can do, and call one directly — right now, in conversation, with no workflow, no saving, no building. Two halves make Fabric work: * Discover: "What can this integration actually do?" Fabric reads the integration's own definition and hands back the list of available operations. * Execute: "Now, go do that one." Fabric picks up the right credential, calls the vendor, and brings the answer back. If workflows are recipes you write down and cook later, Fabric is having someone in the kitchen who can just grab an ingredient when you ask. ## How it's used in Rewst #### Through Rewst's AI assistant When you ask the in-app agent something like "how many open tickets does this customer have," it's using Fabric behind the scenes. You can see it happening — the agent displays "Checking available Fabric operations" and "Running Fabric operation" as it works. #### Through an outside AI tool If you've connected something like Claude or Copilot to Rewst via an MCP token or connected app, that tool gets Fabric access too. It can then read from and act on your integrations from within that other chat window. #### As an ingredient in workflow building When an AI helps you build a workflow and needs real values to fill a dropdown — actual company names, actual ticket boards from your PSA — it pulls those live through Fabric rather than guessing. ### What it could be used for Fabric can do anything your integrations can already do, but conversationally and immediately instead of via a built workflow. * Quick lookups you'd never bother automating — "what's this user's license status," "pull that ticket" * Ad-hoc investigation across several systems at once, without building anything * Exploring a new integration to learn what it's capable of before committing to a workflow * One-off fixes where writing a whole workflow costs more than the task is worth * Letting non-builders get answers out of systems they'd otherwise need someone else to query ## Limitations to Fabric * Fabric is deliberately restricted. Rewst caps how much Fabric can pull in one go: * 100 records per call by default * 500 maximum * A 2 MB ceiling on response size * Big requests come back in pages, and the AI has to keep asking for the next one. If a result is too large, it gets refused outright, and the AI has to narrow the request. This is intentional; it stops one question from dragging your entire ticket history into a chat window. * Note that Fabric calls are not normal workflow runs. A Fabric call shows up in the [Runs](/rewst-documentation/documentation/automations/runs.md) menu, but it isn't a real workflow execution, and some of the usual run-inspection tools simply don't apply to it. Troubleshooting a failed Fabric call is a different and thinner experience than debugging a failed workflow. * There's no orchestration. Fabric does one thing per call: no branching, no loops, no error handling, no scheduling, no "if this then that." The moment you need any of that, you need a workflow. Fabric doesn't replace workflows — it complements them. * The integration has to already be installed and authorized. Fabric can only reach what you've genuinely connected with working credentials. It can't conjure access. * Not everything is equally supported. For some operations, Fabric will forward a filter to the vendor without knowing whether that vendor honors it. Results can occasionally be unpredictable at the edges. * Rewst has a permission system for Fabric. You can restrict which integrations and which operations an AI is allowed to touch, require approval for sensitive actions, and review requests in an approval queue. Note that enforcement defaults to off. Out of the box, it's permissive. If you care about scoping what AI can do in your environment, that's a deliberate configuration step, not something you inherit. ## Where to find Fabric in the platform There's no Fabric menu item. Instead, it's surfaced in several different places in the platfom: 1. The Rewst AI chat - This is the main way that Fabric is used 2. Runs - Filter the Runs list by the Fabric type to see past calls\ \ ![](https://3039672601-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fh0G0em3PH6aDfPoI5XpN%2Fuploads%2FlkgMk4SaKYSmXX7Bwp7m%2FScreenshot%202026-09-18%20at%2011.08.37%E2%80%AFAM.png?alt=media\&token=df31e32d-f37c-4dc5-bc51-ae480b09b1e8) 3. Settings > AI Access - This is where the MCP tokens and connected apps live in Rewst, and how outside AI tools get Fabric access 4. Settings > Roles - Fabric permissions are part of the role definitions, and this is where you'd scope who and what can use it\ \ ![](https://3039672601-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fh0G0em3PH6aDfPoI5XpN%2Fuploads%2FKkTWwpv825YJEGlzMlDV%2FScreenshot%202026-09-18%20at%2011.08.01%E2%80%AFAM.png?alt=media\&token=6f0f9e99-8a6c-45f0-9c08-670869484b31) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.rewst.help/rewst-documentation/documentation/rewst-agent/fabric-in-rewst.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.