Guru
ProductivityConnect AI agents to Guru, the company knowledge base. Agents search and read verified cards before drafting answers, capture knowledge from other tools as new cards in the right collection, update runbooks programmatically, and archive stale content.
What This Integration Enables
Guru's core idea is verification: a card is not just written, it is vouched for by an owner and flagged when trust expires. That makes it the right substrate for AI-assisted support, and it sets the rule this connector is built around: agents should read from Guru before drafting anything, and write to Guru only through review. FlowRunner agents search and read cards with full HTML content and verification state, create cards in the right collection and boards, update card content programmatically, archive stale cards, and browse the collection structure that keeps knowledge findable. The blunt version of the thesis: an AI agent without a knowledge base guesses, and an unmaintained knowledge base is just a slower way of guessing. Wiring the two together, with humans owning verification, fixes both. - Ground AI-drafted answers in verified cards instead of model memory - Capture resolutions from tickets, forms, and chat threads as reviewed knowledge - Keep runbooks and policy cards current as the underlying processes change - Archive superseded content on a cleanup cadence, with an owner confirming each removal - Mirror content from other wikis so Guru stays the single place people actually check
Without FlowRunner
With FlowRunner
Use Case Scenarios
Support answers that cite the wiki, not the model
A question lands in [Slack](/integrations/slack). The agent runs Search Cards, pulls the best match's full content with Get Card, checks its verification state, and posts an answer sourced from the card with a link back to it. If the card is unverified or missing, the agent says so and tags the collection owner instead of improvising. Support quality stops depending on which teammate happens to be online, and every answer teaches people where the knowledge lives.
Closed tickets feed the knowledge base
When a [Zendesk](/integrations/zendesk) ticket closes with a novel resolution, the agent drafts a card: problem, environment, fix, formatted as HTML. Search Cards confirms it is not a duplicate, and the draft goes to the support lead for edit and approval before Create Card files it into the troubleshooting collection on the right board. Over a quarter, the knowledge base grows in exact proportion to what customers actually ask, which no documentation sprint has ever achieved.
Runbooks that track the process they describe
The operations team changes a deployment step. The agent pulls the affected runbook with Get Card, applies the change to the HTML body, and stages an Update Card call for the card owner's approval. On publish, the update resets the card to needing re-verification, so Guru's own trust mechanics kick in and the owner formally re-verifies. Meanwhile a monthly sweep flags cards untouched past their review window and routes them to owners: refresh it, or approve archiving it via Delete Card.
Human-in-Loop Highlight
Update Card replaces a card's entire body, and the cards worth automating against are exactly the ones other people trust blindly: the runbook a support rep follows step by step at 2 a.m., the policy card an agent quotes to a customer. A wrong edit does not fail loudly. It gets followed. Guru resets an updated card to needing re-verification, but between the write and the owner's re-check, wrong instructions are live and wearing the knowledge base's credibility. So FlowRunner agents never push body replacements to verified cards unattended: the change stages as a before-and-after diff, the card owner approves, and only then does Update Card execute, with re-verification following immediately instead of eventually. Delete Card gets the same treatment on any card with recent views, because an archived card that someone still relied on is a support outage in slow motion. Drafting is the agent's job. Vouching stays with the owner, which is the entire point of Guru.
Agent Capabilities
7 actionsCards
5- Search Cards Searches the knowledge base by keyword, returning matching cards with id, title, verification state, owner, collection, and a content snippet. The read that precedes every answer and every create.
- Get Card Retrieves a single card by id with full HTML content, verification state, owner, collection, boards, and dates. The grounding step for AI-drafted answers.
- Create Card Creates a card in a collection with a title and HTML body, optionally attached to boards. Returns the created card and its id. The publishing step behind knowledge-capture flows.
- Update Card Updates a card's title or HTML content by id, changing only the fields provided. Content updates replace the whole body and typically reset verification. The action this page's human gate governs.
- Delete Card Archives a card by id, moving it to the trash rather than destroying it immediately, restorable for a limited time. Used in cleanup workflows with owner confirmation.
Collections
1- List Collections Lists all collections the credentials can access, with id, name, type, color, and card count. The filing map for card creation and scoped searches.
Boards
1- List Boards Lists boards, optionally filtered to one collection, with id, title, and card count. Boards are the sections that group cards, and their ids feed Create Card.
Frequently Asked Questions
What can FlowRunner do with Guru?
FlowRunner agents can run Search Cards, Get Card, and Create Card in Guru, plus 4 more actions.
Does connecting Guru to FlowRunner require OAuth?
No. Guru connects to FlowRunner with basic authentication (a username and password), no OAuth flow required.
Can Guru trigger a FlowRunner workflow automatically?
Guru doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with Guru
$100 in credits. No card required. Connect in minutes.