# Actions Source: https://docs.meetsquad.ai/actions The concrete next steps Squad suggests off the back of an insight. What to do, in order. An action is a concrete next step Squad suggests off the back of an insight. Most are plain tasks ("message engineering for an estimate", "confirm the SSO scope"). Some carry a chat prompt so you can start working them with Squad in one click. Turning an action into a brief is optional. Actions Actions ## What an action carries | Field | What it holds | | - | - | | **Title** | The one-line task. | | **Description** | A short paragraph of what to do. | | **Why it matters** | Squad's rationale for suggesting it (shown only when present). | | **Priority** | **P0**, **P1**, or **P2**, highest first. | | **Effort** | **Low**, **Medium**, or **High**. | | **Category** | Operational, Product, Comms, Strategic, or Workspace. | | **Owner** | The workspace member on the hook, shown as an avatar. | | **Notes** | A free-text scratchpad you can edit on the detail page. | | **Linked** | Every insight the action addresses (`IN-4`, `IN-9`, …) and any brief it produced (`BR-7`). The first linked insight remains the primary reference. | Every action has an ID like `AC-12`. You'll see it on cards, in search, and at the top of the detail page. ## Where actions appear Actions show up in three places. Start, complete, or reprioritise one anywhere and every surface updates on its own: The **Prioritized Actions** widget lists your highest-priority open actions across the workspace. The full list, reached from **Actions** in the sidebar. Under **Squad recommends**, the actions relevant to that insight. The same `AC-` action can appear under several insights when it addresses the same need. ## The Actions page Tabs split the list into **All**, **Suggested**, **In progress**, **Done**, and **Dismissed**. Rows are sorted by priority (P0 → P1 → P2). Each row shows the `AC-` ID, title, the primary source insight (`IN-`) plus a `+N` count for additional linked insights, a priority chip, a status chip, and the owner's avatar. Use the search box (**Search actions or AC-…**) to filter by title or ID. You can act on a row without opening it: * Change **Priority** or **Status** inline from the chips. * Assign an **Owner** from the avatar cell. * The arrow button on the right is **Start with Squad** (or **Continue with Squad** once the action is in progress). It only appears while there's something to work. * The **⋯** menu holds the rest: **Mark done**, **Snooze 3 days**, **Dismiss**, **Generate PRD** / **Generate decision brief**, jump to the linked insight or brief, and **Copy** the `AC-` ID. Click anywhere else on a row to open the action's detail page. ## The action detail page Opening `AC-12` gives you the **Description**, **Why it matters**, and a **Notes** editor you can type into freely. A right-hand **Info** panel lets you change **Status**, **Priority**, **Effort**, **Category**, and **Owner**, and shows what the action is **Linked** to. Use the link picker to add more insights or attach a brief; removing one insight leaves the action linked to the others. With the [Linear integration](/integrations/linear) connected, the panel also carries a **Linear** row. Click **Link**, paste an issue URL or an identifier like `ENG-123`, or search your issues and pick one. The pill that appears shows the identifier, the state Linear last reported, and a click through to the ticket, with its own remove button to unlink. One issue links to one Squad action or brief, and the state shown is as of the last event Linear sent rather than a live read. Two buttons sit below the panel: * **Start with Squad** (or **Continue with Squad** if the action is already in progress). * **Create brief**, which opens a menu to **Generate PRD** or **Generate decision brief**. This is hidden once the action has already produced a brief. The `⋯` menu in the top corner mirrors the row menu. ## Statuses and the lifecycle An action moves through four states: Freshly proposed by Squad, waiting on you. You've started it (or set it yourself). Completed. It drops off the dashboard and the open lists, and the dashboard's **Actions completed** count ticks up. Set aside as not worth doing. The lifecycle is `Suggested → In progress → Done`, with **Dismissed** available at any point. Generating a brief is a command on the action, not a status. ## Starting, finishing, and dismissing * **Start with Squad** opens the chat, seeds it with the action's prompt (with the action referenced), and sends it. The action moves to **In progress**. Every action can be started. If it has no author-written prompt, Squad builds one from its title, description, and rationale. * **Mark done** completes the action. * **Snooze 3 days** hides it for three days. * **Dismiss** removes an action that isn't worth doing. On an insight, dismissed actions collapse under a **Show dismissed** toggle so you can still see what was passed over. ## Owners and assignment Every action can have one owner. Click the avatar (on a row) or the **Owner** field (on the detail page) to open the member list, then pick someone, or choose **Unassign** to clear it. Unassigned actions show a dashed placeholder avatar. The owner's face follows the action everywhere it appears. ## Turning an action into a brief When an action's real job is a written artefact (a spec, a recommendation), Squad can draft it. Choose **Generate PRD** (product requirements) or **Generate decision brief** (a build/defer/research recommendation) from the row menu, the detail page, or the **Squad recommends** list. Squad drafts from the action plus all of its linked insights, deduplicating their evidence and using the 15 strongest signals across the set. It drafts in the background: the action shows a **Building…** badge, then a green `BR-` badge linking to the finished draft. If drafting fails, you'll see a **Failed** badge. Each action produces at most one brief. Once it has, the generate options disappear and the menu offers **Open brief** instead. See [Briefs](/briefs) for what happens next. ## Squad recommends (on insights) On an insight's detail page, the **Squad recommends** panel lists the actions tied to that insight, sorted by priority, each with its `AC-` ID and priority chip. If an insight has no actions yet, you can trigger Squad to rank and propose some. The panel shows a working state while it thinks, then fills in as actions arrive. Dismissed suggestions hide behind a **Show dismissed** toggle. Before saving a recommendation, Squad checks open actions across the whole workspace. If a suggestion is semantically the same as an existing **Suggested** or **In progress** action, Squad links that existing `AC-` record to the current insight instead of creating or rewriting an action. Its title, description, rationale, owner, priority, notes, status, prompt, and snooze remain unchanged. Recently dismissed matches are suppressed for 30 days; completed actions do not block a fresh recommendation. Squad can prepare recommendations for several insights at once, but queues the final check and save per workspace so two insights cannot create the same action at the same time. ## Cookbook **From insight to done.** Open a high-scoring insight, read its **Squad recommends** list, and pick the action that matters. Hit **Start with Squad** to hand it to the chat with full context. Work it through, then come back and **Mark done**. The action leaves your open lists. **Clear the deck each morning.** Open the dashboard and scan **Prioritized Actions** top to bottom. Assign an **Owner** to the ones that belong to a teammate, **Start** the P0 you'll tackle first, and **Dismiss** anything that's no longer worth doing. **Draft a spec from an action.** On an action whose job is to write something up, choose **Generate PRD** (or **Generate decision brief**). Watch for the **Building…** badge, then click the green `BR-` badge when it turns up to open and edit the draft. From there it's a [brief](/briefs) with full version history. # Activity Source: https://docs.meetsquad.ai/activity Who did what in your workspace, human and agent, in one feed you can filter. Activity is the record of every change in your workspace, whoever made it. Goals created, insight statuses moved, documents rewritten, integrations synced, agent runs started and finished. Newest first. The Activity feed The Activity feed ## Getting there Activity has no sidebar entry. Reach it from one of the four places below. The **Recent activity** card. Hover it and **See all** appears in its top right. **All activity** sits at the bottom of the notification **Inbox** in the sidebar. **All activity** next to the **History** section on any goal, insight, or brief. These arrive pre-filtered to that entity type. `/{your-org}/{your-workspace}/activity` ## Reading a row Each row is one event, written as a sentence. The actor comes first in bold, then what they did, then the thing they did it to. Squad's own work is attributed to **Squad**. When a named agent made the change, the row ends with `via {agent name}`. Your teammates appear by name, or by email if their profile has no name set. The right of each row carries the actor's avatar (a photo or initials for a person, the Squad mark for an agent) and the timestamp in `DD Mon HH:MM` local time, for example `07 Feb 14:03`. Hover a row for the `⋯` menu. **Open** jumps to the entity, when the event resolves to one. **Copy event JSON** puts the raw event on your clipboard. Click a row and it expands in place. The **Changes** list names each field that moved, old value struck through and new value beside it. Signal events also show the signal text, and there's a link like **View goal →**. Some events read as plain statements rather than sentences, mostly around agent runs and the pipeline. **Scheduled run started**, **Generated report**, **Manual run**, **Data signals received but none have a similar peer yet, waiting for more evidence**. When nothing happened, the event says why. ## Filtering Filters live behind the funnel icon in the toolbar. Pick one and it appears as a removable chip below the toolbar. The icon turns purple while any filter is on. | Filter | Narrows to | | - | - | | **Actor** | Who made the change. **Squad** covers everything the product did on its own. Every member of your organisation is listed by name below that. | | **Entity** | What was changed: **Goals**, **Insights**, **Documents**, **Data Signals**, **Integrations**, or **Workspace**. | | **Action** | The kind of change: **Created**, **Updated**, **Deleted**, **Status**, **Assigned**, **Moved**, **Approval**, **Synced**, **Bulk Created**, **Processed**, **Merged**. | Selecting more than one actor widens the feed rather than narrowing it. Agent runs are recorded against the workspace, so **Workspace** under **Entity** is where you find them. ### Filtering by URL Two filters can be set in the address bar. That's how the pre-filtered links from goal, insight and brief pages work. `?entityType=goal` shows goal events only. The values are the singular entity names `goal`, `insight`, `document`, `signal`, `integration`, `workspace`. `?actorType=type:agent` shows Squad's work only. The prefix matters. For a person, use `?actorType=user:`. Take one param per request. A second copy of the same param is ignored. Filters you set with the funnel icon stay in the page rather than the URL, so build a filtered link by hand if you want to share one. Runs you start yourself are recorded as your action, not Squad's, even though an agent did the work. Filtering by **Squad** hides them. **Workspace** under **Entity** catches every run regardless of who started it. ## Loading and freshness The feed loads thirty events at a time and pulls more as you scroll. When you reach the end it says **No more activity**. It refreshes itself roughly every ten seconds, so a page left open stays current. An empty workspace shows **No activity yet** with **Activity will appear as your workspace evolves**. With a filter on and nothing matching, it shows **No activity matches your filters**. ## Cookbook Open the goal, click **All activity** next to **History**, and read the feed top down. Expand any row to see the exact fields that moved and their previous values. Open Activity, filter **Entity** to **Workspace**, and scan the agent run entries. Runs that found nothing say so explicitly, which is usually the answer to "why did I get no report". Filter **Action** to **Assigned**, then **Actor** to the person you suspect. The row names both the old and new owner when you expand it. Filter **Entity** to **Integrations** and look for **Synced** events. No recent sync means the connection needs attention on [Integrations](/integrations). # Run history Source: https://docs.meetsquad.ai/agent-runs Every time an agent ran, what it changed, and what it produced. How to read a run row and what its status actually means. **Run History** sits at the bottom of every agent's detail page. It lists the agent's runs, newest first, up to the 50 most recent. Before the first run it tells you runs appear once the agent is scheduled or run manually. Each run is one collapsed row. Click it to expand. ## Statuses Six statuses, each with its own badge. The run exists and is queued. Nothing has started. In flight, with a spinner. Finished and did its work. The run did its work, but something downstream failed. A Slack delivery that couldn't post is the usual cause. The output exists. The last mile didn't. A success. The agent ran, looked, and found nothing worth acting on, so it produced nothing. The label reads like a problem. It isn't one. A daily competitor watcher will show plenty of these, and that's the right outcome for a quiet day. If you want a report even on those days, turn on **Report when nothing changed** in the agent's report settings. The run itself broke. The error is in the expanded row. ## The collapsed row Left to right, a row carries the status badge, what started the run (a scheduled run, a manual run, or an event run), and a line of facts underneath. * Whether content changed: changed, no content change, or sources unavailable. Sources unavailable means the run proceeded but every source it tried failed to load, which is different from genuinely finding nothing new. * How many signals the run created. * How many documents it touched. * **Report**, when the run produced one. * The event and entity that fired it, on event-driven runs. * A per-source tally, on runs with sources: how many were read and how many failed. On the right sits the duration and when it ran, as both a relative time and a date. Runs that produced a report also get an **Open report** button on the row when the window is wide enough. ## The expanded row Expanding a run gives you, in order. In a red panel, if the run recorded one. Shown when the run wrote a report. The report's title and its summary, rendered, plus the token count and model that produced it, and an **Open report** button. A list of the documents and insights this run created or updated, each labelled created or updated and linking to the thing itself. A compact table of what the agent did during the run. Click any line to open its detail. A run with nothing recorded says so. The counts on the collapsed row are authoritative. The **Documents and insights** list and the **Audit trail** are best effort. Both are built from the activity loaded for this agent, which arrives a page at a time. A long run can list fewer entities than the same row's count claims, and its audit trail can be short of everything that happened. When the two disagree, believe the counts. A run reports its total duration and nothing finer. There are no per-tool-call timings, and the audit trail records what the agent did, not how long each step took. ## Where reports go Every report an agent writes is saved to the system **Agent Reports** folder, whether or not you set up delivery. It's a normal document from there, searchable, editable and versioned. Delivery adds copies. Three channels ship. **Notifications**, which reaches everyone subscribed to that agent, a **Slack** channel once Slack is connected, and **Email** to selected org members. Knowledge and insights aren't delivery channels. The **Gain knowledge** and **Discover insights** outputs on the agent already handle those. A run with a notification delivery and nobody subscribed records that delivery as **skipped**, with the reason, rather than failing the run. Open a report from the run row, from the **Latest Report** card in the agent sidebar, or from the Agent Reports folder in your [knowledge base](/knowledge-documents). ## Reading a problem Expand the newest run and read the message. Fix the cause, then **Resume** from the agent header. Agents in error don't restart themselves, which stops a broken source being hammered. The pages or channels the agent reads are failing. Check the per-source tally on the row, then check those entries in [Tools and access](/agent-tools-access). A URL that moved needs replacing. A Slack channel the bot was removed from needs the bot back. That's what **Partial** means. The work is done and the report is in Agent Reports. Check the report's delivery status, fix the channel, and redeliver from the report. The machine running the agent went away mid-run. Squad notices the abandoned run and closes it out, which is why the message describes the run rather than your agent. Nothing is wrong with your configuration. Run it again. Some of the work may already have landed. Check Agent Reports and the agent's knowledge documents before re-running, so you know whether you are repeating work or redoing it. The run never got a turn. Squad runs one agent at a time per workspace, so a burst of agents scheduled on the same tick queues up behind each other, and this run waited past the point where it was still worth starting. Stagger the start times of agents that share a schedule. An agent that runs daily rarely needs the same minute as every other daily agent. The agent is paused, in error, or already running. One run at a time per agent, always. # Agent templates Source: https://docs.meetsquad.ai/agent-templates Ready-made agents written by Squad, including integration-backed templates with guided setup. The **By Squad** tab on the Agents page holds agents Squad already wrote, with full instructions, triggers, access, and outputs. Start from one when you want the standing job without writing the brief. Templates that use an integration collect their connection-specific choices before creating the agent. The same gallery also offers a [workflow](/workflows) for Jira Service Management, Fellow, GitHub, and the app store review sources. Those are ingestion rather than agents, so they have no instructions and no schedule, and their cards read **As it happens** where a template's reads Daily or Weekly. This page is about the agent templates. Everything on the tab is on offer whether or not you have connected the tool behind it. Click **Set up** on a card whose provider is missing and the modal names the connection it needs and offers **Connect** on the spot. Where signing in is the whole story, you come back to the same card with the modal still open. Jira is the exception. Access to the site is not enough on its own, so connecting ends on the Jira settings page where you choose which spaces Squad watches. The modal says so before you start. The By Squad template gallery The By Squad template gallery The gallery uses the same toolbar as the agents list. Card grid by default, a toggle for compact rows, plus search, filter, and sort. Filter by **Trigger**, **Cadence**, or **Integration**. Filter **Cadence** to **As it happens** for the workflows alone, or to **Daily** or **Weekly** for the agents. ## Templates `competitor-tracker`. Watches your competitors and reports meaningful changes to pricing, product, and positioning each day. It keeps one index document of every competitor you track plus a profile per competitor, and records material changes with dates. Daily. `social-pulse`. A daily read on what people are saying about your product and your space across social channels. It keeps one durable record of recurring themes, sentiment shifts, and the communities worth watching. Passing chatter stays in the daily report. Daily. `market-research`. Researches your market daily and reports the trends, players, funding, and regulatory shifts that matter, with takeaways. It maintains a market map of segments, key players, and open questions. Daily. `distribution-opportunities`. Hunts for channels, partnerships, and communities that could put your product in front of more of the right people. It keeps a playbook of every opportunity with reach, effort, the concrete first step, and current status. Daily. `strategy-consultant`. A weekly strategic review of your goals, feedback, and market position, with candid recommendations. It maintains a working perspective file of durable themes, live hypotheses with evidence for and against, open questions, and a log of past advice and what happened to it. Weekly. `build-vs-demand`. Compares what shipped against what customers are asking for, and flags where delivery is running ahead of demand or where real demand is going unbuilt. It reads Squad's own knowledge, insights, and goals, so it works best once your delivery record and customer feedback already flow in. It keeps a ledger of each demand theme, its evidence strength, delivery status, related goal, and how the gap is trending. Weekly. `weekly-shipped-work`. Reviews the 50 most recently updated Linear issues, identifies completed work, maintains a shipped-work knowledge index, and reports what shipped each week. Requires Linear. Read-only. `stalled-work-watcher`. Reviews the recently updated Linear issue window for explicit blockers and possible progress risks, then produces a concise risk report. It names gaps where the available issue data cannot confirm ownership or inactivity. Requires Linear. Read-only. `release-readiness-brief`. Summarizes completed work, remaining issues, blockers, and delivery confidence from recent Linear activity. It makes the 50-issue window and lack of project or date filtering explicit. Requires Linear. Read-only. `recurring-bug-detector`. Finds likely bug themes in recent Linear issues and maintains a product-quality watchlist of recurring risks. Requires Linear. Read-only. `customer-channel-digest`. Reads selected Slack channels each week, clusters requests, pain points, praise, objections, and open questions, then creates signals and a digest. Requires at least one channel the Squad bot can read. Read-only in Slack. `escalation-radar`. Reads selected Slack channels daily for urgent customer language, repeated follow-ups, and unresolved questions. It creates signals from direct customer evidence and a ranked escalation report. Requires at least one channel the Squad bot can read. Read-only in Slack. `sales-objection-tracker`. Reads selected sales or prospect Slack channels weekly, extracts common objections and missing proof points, and creates Squad signals. Requires at least one channel the Squad bot can read. Read-only in Slack. `prd-evidence-guard`. Watches one shared Notion PRD and compares each change with Squad insights, goals, and knowledge. Requires a Notion page. Read-only. `research-freshness-monitor`. Watches a shared Notion research page and identifies findings or assumptions that may need re-validation. It maintains a research freshness ledger. Requires a Notion page. Read-only. `support-request-triage`. Runs when a request is created in selected Jira Service Management spaces, assesses its theme and urgency, and creates signals plus a Squad-side report. Requires at least one monitored space. Read-only in Jira. `incident-theme-tracker`. Runs for new requests in selected Jira Service Management spaces, groups them into recurring incident themes, and tracks recent urgency and volume in an index. Requires at least one monitored space. Read-only in Jira. `morning-briefing`. Reports every morning on what moved in the last 24 hours, covering new signals, new insights, and actions completed. It cites the item behind every claim and says so plainly when the night was quiet. No sources or connections needed. Daily. `weekly-briefing`. Reports every week on the trailing seven days, grouped into themes, with the trend against previous weeks and a watch list of what is forming but not yet worth acting on. No sources or connections needed. Weekly. Both briefings already run in your workspace. Squad creates them when the workspace is created, so use these cards to rebuild one you deleted or to run a second copy on a different brief. ## What each one produces Every template generates a report when it runs. Scheduled templates also report on a quiet day or week, giving you a written "nothing moved" rather than silence. Event-backed templates run only when their configured Notion page or Jira request event arrives. Templates that maintain a working knowledge document do so through their instructions and explicit knowledge access. **Competitor tracker**, **Social pulse**, and **Market research** have **Discover insights** on, so what they read becomes signals that cluster into [insights](/insights). **Distribution opportunities**, **Strategy consultant**, and **Build vs demand review** don't extract signals. Their value is the report, and each keeps a working knowledge document (a playbook, a perspective file, a ledger) it maintains through its instructions and knowledge access. **Customer-channel digest**, **Escalation radar**, **Sales-objection tracker**, **Support request triage**, and **Incident theme tracker** also discover insights. **Weekly shipped work**, **Recurring bug detector**, **Research freshness monitor**, and **Incident theme tracker** can create or update their working indexes. **Stalled-work watcher** and **Release readiness brief** read Linear alongside Squad context and produce their reports; **PRD guardrails** reads its configured Notion page alongside Squad context. No template ships with a delivery channel. Add Slack or email afterwards, or up front through Configure for templates that offer it. ## Two ways to start Every template card carries a cog and one button. The cog is the long way round, the button is the short one. Opens the New agent form prefilled with the template's name, description, instructions, schedule, and outputs, plus the standard access defaults. Change anything, then create. Take this path to see and set what the agent can reach before it runs. On a template with nothing to choose, the button reads **Create**. It makes the agent immediately from the template as written, queues its first run, and drops you back on the Agents tab with the new agent already running. Template names are fixed, so creating the same one twice appends a number (`Social pulse 2`) rather than failing. On an integration-backed template the button reads **Set up** instead, because there is something to choose first. It asks only for the values the template needs: Slack channels, a Notion page, Jira spaces, or no additional scope for Linear. The agent is created only after every required choice is present. If the provider is not connected, the modal connects it for you and picks up where you left off, unless there is a further choice to make on the provider's own settings page. If you started connecting it and stopped, it says so and links you to the half-finished connection instead. The cog on an integration-backed template opens the regular builder with the template instructions and outputs already filled in. A setup checklist links to the required integration and names the trigger and scope that still need configuring, so you can adjust the standing brief before creating the agent. On the five research templates, one-click **Create** writes no tools and access levels. Open an agent made this way and every row in **Tools and access** reads as off or None, and the connections list is empty. It still runs. There's a built-in fallback covering the web, your knowledge base, insights, and goals, and the page won't tell you that. Set any level on that page and the fallback stops applying, so only what you set counts. **Build vs demand review** is the exception among the setup-free templates. It writes its own access and keeps the web off. Use **Configure** if you want the access written down from the start. ## After you create one A template agent is an ordinary agent. Rename it, rewrite its instructions, change its schedule, add triggers, tighten or widen its access, and switch outputs on and off. Nothing about it stays tied to the template. Open [Tools and access](/agent-tools-access) first and set the levels you actually want, especially if you used the one-click path. # Tools and access Source: https://docs.meetsquad.ai/agent-tools-access One list that decides what an agent can reach and what it can do there. The levels you pick are enforced, not advice. **Tools and access** is a single list, one row per target, one level per row. It appears in the New agent form and again on the agent's detail page. Two kinds of row share the list. **Capabilities** are built into Squad, covering the open web, your knowledge base, insights, and goals. **Connections** are places outside Squad, plus web pages you name directly. ## Levels are enforced The level on a row decides which tools the agent is handed for the run. A tool the row does not grant is never built, so it is not on the agent's list at all. An agent whose knowledge-base row is set to **Can view** has no tool that can change a document. There's nothing to call, so instructions telling it to "update the roadmap doc" produce a run where it reads the doc and reports that it couldn't write. Widen the row and the tool appears on the next run. Connections work the same way. An agent with no Notion row can't read a Notion page even when the workspace is connected and another agent reads it fine. ## Capabilities A straight **On** or **Off** switch. On, the agent can search the web and open public pages while working its brief. Off, it works only from what you gave it. Graded, and each level contains the one before it. * **Can view**: search, open, and follow documents and folders. * **Can groom**: everything above, plus editing existing documents where the brief warrants it. * **Can create**: everything above, plus writing new documents and folders. * **None**: no access to the knowledge base at all. Pick the narrowest level that does the job. An agent that only needs context for a report belongs on **Can view**. One whose job is keeping a document current needs **Can groom**. Give it **Can create** when you want new documents appearing on their own. **Read only** or **None**. An agent can list your [insights](/insights) and your goals to ground its work. Neither capability lets an agent change them. ## Connections **Web pages** is always in the list and needs nothing connected. Add a URL, optionally with a label, and the agent fetches that page on every run and tells you what meaningfully changed since last time. Changelogs, pricing pages, docs, status pages, and competitor blogs are the usual candidates. The only level is **Read**. A page that fails to load shows up in the run's history as a source that couldn't be read, rather than silently disappearing. Everything else is a provider. **Add connection** lists the providers that offer agent tools. Ones you've already connected can be added straight away. Ones you haven't show a **Connect** button, which takes you to [Integrations](/integrations). Adding a connection and scoping it are two separate steps. Adding it puts a row in the list with a level, defaulting to the most restrictive real level available. Scoping it means naming the specific pages or channels underneath, which you do from the row. A connection with no scopes under it still grants the provider's tools at the level you chose. **Notion**'s only level is **Can view**. An agent can open the pages you scope to it. **Slack** has two. An agent can hold at most ten connection scopes. That includes every URL, every Slack channel, and every Notion page across all its connections. It limits how wide one run's reading can fan out, not how many places you can integrate. ## Slack: reading versus capturing Slack's two levels differ in where the messages end up. **Read only** lets the agent open a channel and use what it finds for this run. Nothing is stored. Choose it when the agent needs the context but the channel shouldn't become part of your data. **Capture messages as signals** reads the channel and also saves the messages into Squad as signals, where they join everything else in the pipeline and can cluster into insights. That's a write into your workspace, not a read, and it keeps happening on every run. Choose it when you want the channel to become an ongoing input to your evidence. New Slack connections start on **Read only**. Move to capturing deliberately. ## Turning a row off The two kinds of row behave differently. Setting a **connection** to **None** removes it. The row disappears from the list and its scopes go with it. To bring it back, add the connection again and rescope it. Setting a **capability** to **None** leaves the row in the list, visibly off. The agent gets no tool for it, and you can see that you turned it off rather than never considered it. ## Saving In the New agent form, tools and access are saved with the agent when you click **Create agent**. On the detail page, edits are staged. Change a level, add a connection, or add a URL and nothing is written yet. A save button appears at the bottom of the section once something is dirty, and only pressing it commits the whole set. Leave the detail page without pressing save and your changes are dropped. A new agent form starts with web access **On**, the knowledge base on **Can create**, and insights and goals on **Read only**. Tighten anything you don't want before creating. ## What isn't here Some things you might expect to grant are missing because the underlying tool doesn't exist. There's no way to give an agent write access to Notion, no permission that lets an agent send mail, and no scoped outbound posting to Slack. They're absent from the menus rather than present and inert. Reports still reach Slack and email. That runs through the report's delivery settings, which are configured under the agent's report output, not here. See [Agents](/agents). # Agent triggers Source: https://docs.meetsquad.ai/agent-triggers How to make an agent run, whether on a schedule, a workspace event, or an event from a connected integration. A trigger is what makes an agent run. Three kinds ship. A recurring schedule, a workspace event, and an event from a connected integration. An agent can carry several at once. A schedule on one of six cadences, from hourly to annually. Five events from things happening inside Squad. Thirteen events across seven connected providers. **Add trigger** opens a two-pane dialog. The left column groups what's available under **Recurring**, **Workspace**, and one group per connected integration that offers triggers. The right pane configures whatever you picked. Each trigger you add lands as a summary row with an X to remove it. A schedule is optional. An agent can run purely on events, purely on a clock, or on both. An agent can't run on nothing. Removing or pausing its last active trigger is refused. ## Schedule One option, **On a schedule**, under **Recurring**. Pick a frequency and, optionally, when it starts. Six cadences. **Hourly**, **Daily**, **Weekly**, **Monthly**, **Quarterly**, **Annually**. Monthly and longer cadences clamp the anchor day, so a schedule anchored on the 31st still fires in February. **Starts** takes a date and a time. Set it and the first run happens then, repeating on the cadence from there. Leave it unset and the agent starts within the hour, then repeats. An agent gets at most one schedule. Once it has one, the **On a schedule** option in the dialog is greyed out. Change the frequency with **Edit schedule** on the row you already have. ## Workspace events Fires when a document is added to the [knowledge base](/knowledge-documents). Takes an optional scope, so you can watch a folder, watch a single document, or leave it open and watch everything. The document that changed is handed to the agent as context for that run. Fires when a document in the [knowledge base](/knowledge-documents) is edited. Takes the same optional scope as **Knowledge created**, so a folder, a single document, or everything. The document that changed is handed to the agent as context for that run. Fires when a competitor document is added. Takes no scope. Fires when a competitor document changes. Takes no scope. Fires when a new [insight](/insights) surfaces from your signals. It takes an optional **Minimum score** between 0 and 1, so the agent only wakes for insights at or above the bar you set. Leave it blank to fire for all of them. Values outside the range are clamped, so a typed `2` becomes 1 rather than a trigger that never fires. ## Integration events Thirteen events across seven providers. A provider's group only appears in the dialog once that integration is connected, and only if it declares agent triggers. Connect one first from [Integrations](/integrations). | Provider | Events | | - | - | | [Notion](/integrations/notion) | Page updated | | [Gong](/integrations/gong) | Call recorded | | [Linear](/integrations/linear) | Issue created, Issue updated, Comment added | | [GitHub](/integrations/github) | Issue opened, Pull request merged | | [PostHog](/integrations/posthog) | Event captured | | [Jira](/integrations/jira) | Request created, Comment added, Request updated, Request resolved | | [Fellow](/integrations/fellow) | Note generated | GitHub's **Pull request merged** fires on a merge into any branch, not only the default one, so an agent watching a release branch or a long-lived feature branch still runs. Where a provider supports it, the right pane lets you narrow the trigger to a specific scope, for example a single Notion page rather than every page in the sync. The thing that fired the trigger is passed to the agent as context, the same way a workspace event is. Slack declares no agent triggers. A Slack message never starts an agent run. A workspace whose only connected integration is Slack sees no integration group in the trigger dialog at all. That's expected. Slack still works as a place an agent can read from and as a delivery channel for reports. See [Tools and access](/agent-tools-access). Agents can't trigger other agents. No chaining, no "when agent A finishes, run agent B", and no way to build one. If you need two stages, write them as one agent with instructions covering both, or give the second agent a trigger on something the first one produces, such as **Knowledge created** scoped to the folder the first agent writes to. ## Editing triggers later The **Triggers** section on an agent's detail page carries the same builder. Add or remove triggers there at any time, and pause one to stop it firing without losing its configuration. A schedule row has a pencil, **Edit schedule**. It opens the frequency and start controls on the current values, so you can move a daily agent to weekly or shift its start time without touching anything else. This works even when the schedule is the agent's only trigger, because changing a schedule never leaves the agent with nothing to run on. Re-timing a schedule that has been running a while keeps its time of day and moves the next run to the next slot on the new cadence, so saving the change doesn't fire the agent on the spot. Event triggers have no editor. To change what one watches, add the replacement and then remove the old one. Removing the last active trigger is refused, so add first. When you want an agent to stop entirely, pause the agent rather than stripping its triggers. # Agents Source: https://docs.meetsquad.ai/agents A standing job that runs on a schedule or an event, works your brief, and produces signals, knowledge, or a written report. Agents Agents An agent is a standing job. It runs on a schedule or when something happens, works the brief you wrote for it, and produces signals, knowledge, or a written report. Set it up once and it keeps going without you. The Agents page The Agents page Open **Agents** in the sidebar. Two tabs sit at the top. **Agents** holds everything running in your workspace, and **By Squad** is a gallery of [ready-made agents](/agent-templates) and [workflows](/workflows) you can start from. **New agent** in the top right opens the builder. Ready-made agents written by Squad. Built-in templates support one-click creation; integration-backed templates guide you through connection and scope setup first. Ingestion without an agent. Switch one on and everything a connected tool sends lands in your feedback. What makes an agent run: a schedule, a workspace event, or an event from a connected integration. One list that decides what an agent can reach and what it can do there. Every time an agent ran, what it changed, and what it produced. ## What you start with Every workspace comes with two briefings already running. **Morning briefing** reports each day on what moved in the last 24 hours, and **Weekly briefing** covers the trailing seven days with the trends and the watch list a planning session needs. Both read your signals, insights, actions, and goals, and neither needs a source or a connected tool. The first morning briefing lands a day after the workspace is created, the first weekly one a week after. They are ordinary agents, so you can edit the brief, change the cadence, add a Slack delivery, pause them, or delete them. Both appear under **Agent reports** in everyone's notification settings from day one, so anyone can follow them without touching the agent. ### Knowledge curator Every workspace also runs the **Knowledge curator**, an agent that keeps your knowledge base clean so Squad answers from one up-to-date version of each fact. Each night Squad checks your knowledge base for its [Context Health](/dashboard#counters-and-context-health) score. When that check finds something to tidy, the curator runs straight after it. It looks for two things. The first is pairs of documents that say nearly the same thing. It keeps the better one, adds any facts only the other had, and moves the other to [Trash](/knowledge-documents#trash). The second is folders holding more than 50 documents, which it sorts into up to three themed subfolders. It makes at most 10 merges and 3 folder regroups a day, however many times it runs. It leaves report documents and system folders alone, along with any document another agent has written to in the last 30 days, since that agent may rely on finding it. Each run lists what it merged and moved in **Run History**, and a merged document shows **Merged into** its survivor in Trash. Restore it within 30 days and the curator will not merge that pair again. On a night with nothing to tidy it doesn't run at all, and its detail page shows **Runs: After the nightly Context Health check** in place of a next run time. The curator is managed by Squad. Its detail page has **Run now** and **Pause**, and no **Edit** or **Delete**. Pause it if your team prefers to look after the knowledge base by hand. ## The agents list The list opens as a grid of cards, one per agent. The toolbar toggles to compact rows and carries search, filters, and sort. Filter by **Status** (Active, Paused, Error) or by **Cadence** (Hourly, Daily, Weekly, Monthly, Quarterly, Annually). Your choice of view, filters, and sort stays in the URL, so a filtered list is shareable. Each card and row shows the agent's name with a second line naming the page it watches or the opening of its brief, then its cadence, when it last ran, and its status. The overflow menu holds **Run now**, **Pause** or **Resume**, and **Delete**. Right-clicking a row opens the same menu. Click anywhere else to open the agent. Any [workflows](/workflows) you have switched on sit in this list too, under a cadence of **As it happens**. A workflow has no brief and no run history, so it carries no **Run now**. ## Statuses An agent is in one of three states. Scheduled and event triggers fire normally. Nothing fires. The agent keeps its configuration and history. Hit **Resume** to bring it back. The last run broke badly enough to stop the agent. It won't recover on its own, which stops a dead source being retried forever. Open the agent, expand the most recent run, read the error, fix the cause, then **Resume**. ## Building an agent **New agent** opens one scrolling form. Fill it top to bottom and click **Create agent**. The New agent form The New agent form The name (unique in your workspace) and an optional description. The description is a note for your future self and is never fed to the agent. Decide when the agent runs. A schedule, a workspace event, an integration event, or a mix. See [Triggers](/agent-triggers) for every option. The standing brief the agent reads on every run, written in plain English. Say what to look at, what counts as worth flagging, and what a good result looks like. The agent decides each run what to reach for within the access you gave it. What the agent may touch, covering your knowledge base, insights, goals, the open web, and any connections you add. Levels are enforced, not suggested. See [Tools and access](/agent-tools-access). What the agent produces. ## The three outputs Three independent switches. Turn on any combination. Extracts product signals from what the agent read this run and pushes them into the pipeline, where they cluster into [insights](/insights) alongside everything else. Lets the agent update or create documents in your [knowledge base](/knowledge-documents) from what it found. Produces a written brief answering a question you set. Turning it on opens the report settings underneath it. At least one output must be on. With all three off, the form refuses to submit and tells you why. Signals and knowledge route themselves. A report is the only output with delivery options. ## Report settings The **Report question** is what every report from this agent answers. Squad drafts one from your instructions the first time you turn reports on, and redrafts it when you edit the instructions and click away. **Regenerate** rewrites it on demand. Edit it freely. **Report title** is optional and accepts `{{date}}` and `{{agent.name}}` as placeholders. **Report when nothing changed** is off by default, so a quiet run produces no report. Turn it on for standing digests that should ship every period regardless. Every report is saved to the system **Agent Reports** folder, editable and searchable even with no delivery configured. It also reaches everyone subscribed to the agent, always, with no setup. **Delivery** adds copies somewhere else, and there is one channel: **Slack**, available once Slack is connected. Knowledge and insights aren't delivery channels. The **Gain knowledge** and **Discover insights** outputs already handle those. Who hears about a report is decided in **Settings**, on the Notifications tab, not on the agent. Every agent that writes reports has a row there, and each person picks in-app, email or both for themselves. That means the list never goes stale when someone changes team, and nobody has to maintain it. See [Notifications](/notifications). ## The agent detail page Opening an agent gives you the whole thing on one page. The header carries the name, description, and the lifecycle controls. **Run now**, **Edit**, **Pause** or **Resume**, and an overflow menu with **Delete**. Deleting stops future runs and removes the agent. Reports it already wrote stay in your knowledge base. Below that, every part of the configuration is editable in place. **Instructions**, **Triggers**, **Tools and access**, **Report** (shown only when reports are on), and **Run History**. The sidebar holds an **Info** panel with **Status**, **Next run**, **Last run**, and **Created**, a **Latest Report** card linking to the newest report, and an **Output** panel summarising what this agent produces. ## Run now **Run now** needs an active, idle agent. On the detail page the button stays visible and goes disabled with a tooltip saying why. The agent is paused (resume it first), it has errored (review the latest run first), or a run is already in progress. One run at a time per agent is a hard rule. In the list menus, **Run now** appears for active agents and greys out while a run is in flight. See [Run history](/agent-runs) for what a run records and how to read it. ## Recipes Point the instructions at the pricing page, add a weekly schedule, add the page under Web pages in Tools and access, and turn on **Generate report**. Accept the drafted question and add a Slack delivery to your competitive channel. Describe what to capture, add a daily schedule, give the agent the sources it needs, and turn on **Gain knowledge** only. No report, no delivery. Add a workspace trigger for **Insight created** with a minimum score and turn on **Generate report**. Whoever needs to act subscribes to the agent in their own notification settings. No schedule required. Add a monthly schedule and turn on **Generate report** with **Report when nothing changed** on, so the digest always ships. Anyone who wants it subscribes to the agent in their own notification settings. Your workspace already has both. If you deleted one, rebuild it from the **Morning briefing** or **Weekly briefing** template. Both are ordinary report agents. The instructions tell Squad to survey the period's signals, insights and actions, and the report question asks what moved and what to watch. Add a Slack delivery if the team should read it in a channel; anyone who wants it individually subscribes under **Agent reports** in their notification settings. No sources needed, because the period comes from your own workspace. # Briefs Source: https://docs.meetsquad.ai/briefs PRDs and decision briefs Squad drafts from your evidence, with a live trail back to the quotes behind every claim. A brief is the document at the end of the chain. You point Squad at an insight, pick a type, and it drafts a first pass that cites the evidence it used. You edit it, review it, and make the call. Every brief carries a `BR-` reference, a status, and a live evidence trail back to the signals, insights, goals, and documents it draws on. Briefs Briefs For where briefs sit in the chain, see [The evidence pipeline](/pipeline). ## The two types A product requirements draft covering problem, users, requirements and scope. Use it when you have decided what to build and need a spec you can refine and circulate. Use it when the call is still open. It lays out the cited case for and against, records how many signals support versus counter the idea, and leads with **Build**, **Defer**, or **Research**. It's the format behind the dashboard's **Briefs to review**. You pick the type when you generate. A PRD can't become a decision brief afterwards. Decision briefs carry a **Decision** badge everywhere they appear, next to their recommendation. ## Generating one Every route runs the same drafting pass. Squad reads the source evidence, drafts the body in the background, and cites what it used. Click **Create brief**. **Start from a template** creates an editable document straight away from one of four structures: **Decision Brief**, **PRD**, **Leadership Memo**, or **One Pager**. Under **Or generate with Squad**, search for the insight the document should be built from, choose PRD or Decision brief, and click **Generate**. Squad drops you on the new page while it drafts. On any action, choose **Generate PRD** or **Generate decision brief**. This is the common route, because the action already knows which insight it came from. See [Actions](/actions). Starting an action opens a chat seeded with its context. Squad can research and write there, filing the result in your knowledge base. Ask the bot in a thread to write the discussion up, or click **Create brief** when Squad offers the button under one of its replies. The thread becomes the brief, and Squad replies with its number and a link while it drafts. A channel thread gets one brief however many times you ask. See [Slack](/integrations/slack). While it's **building**, the body shows a live drafting status over a blurred editor. Work elsewhere and come back, or press **Cancel and start blank** to write it yourself. If drafting **fails**, the body explains why (Squad could not verify the citations, or drafting timed out) and offers **Retry** or **Start blank**. A brief created from an insight, action, or prompt that still has an empty body shows a **Draft** panel in the sidebar. Use **Generate with Squad** there, or start typing. ## The lifecycle Five statuses, shown as a badge you can click to change (except while building): Squad is drafting. The body is locked. The body is editable. This is where you rework Squad's first pass. Submitted for someone to look at. This is the state the dashboard's **Briefs to review** panel watches for. Settled and read-only until you move it back to draft. On a decision brief this same state reads **Decided**. Drafting didn't produce a usable body. Change status from the **Status** row in the sidebar, the badge in the library, or the action menu. Only drafts are editable. Squad rejects edits in any other status, so the editor stays read-only until you move a document back to **Draft**. ## Deciding a decision brief A decision brief is finished when you make the call, not when the body is written. On a brief, the terminal state reads **Mark decided** rather than "Mark as finalised". It opens a dialog where you confirm or change the recommendation (**Build**, **Defer**, or **Research**) and commit. The brief moves to **Decided** and its badge locks to your final call. Until then the recommendation shows as **Pending**. Decide from the status badge, the action menu, or straight from the dashboard's **Calls to make**. The row leaves that list once the call is made. The **Info** panel shows the evidence balance the draft was built on ("N for, N against") and the confidence at drafting time. ## Tracking the build The **Info** panel carries a **Linear** row once the [Linear integration](/integrations/linear) is connected. Click **Link**, paste an issue URL or an identifier like `ENG-123`, or search your issues and pick one. The row then shows a pill with the identifier, the state Linear last reported, and a click through to the ticket. The pill's own remove button unlinks it. One issue links to one Squad brief or action. Squad says so if the one you picked is already taken, and the state on the badge is as of the last event Linear sent rather than a live read. ## Evidence and citations The sidebar **Evidence** panel groups everything the document draws on into **Goals**, **Insights**, **Signals**, and **Documents**. Each entry is a chip that opens that entity, so you can go from a claim in the brief to the `SI-` quote behind it in one click. The trail is derived from the body itself. Reference an entity in the text and Squad links it as evidence. Remove the reference and the link goes with it. The panel updates live as you edit. A body that references nothing shows "No evidence linked yet." ## Showing the evidence A brief can carry visuals, not just prose. Squad adds them while it drafts when the shape of a trend, the size of a number or the order of events is the point being made. You can add your own in any brief that's in **Draft**. Type `/` on an empty line and pick from the **Visuals** group: | Visual | Use it when | | - | - | | **Chart** | The shape of a trend is the argument. Line, area, bar, stacked bar or radar | | **Stat tiles** | The magnitude is the argument. Up to four headline numbers in a row | | **Data table** | The comparison across rows is the argument. Cells can be text, numbers, status chips, signed changes, or a link to a signal or insight | | **Card grid** | Options, personas or workstreams read better side by side | | **Callout** | There's one risk or finding a skim-reader must not miss | | **Meter** | The distance to a threshold is the argument. A bar or a score dial, with an optional target marker | | **Timeline** | The sequence is the argument | Charts, stat tiles and meters are built from your workspace's own numbers. Pick the data (**Signal volume by source**, **Activity trend**, or **Context Health history**), pick a window, pick the series, and Squad fills the visual from what the query returned. There's no free-text number field, so a chart in a brief always traces back to something the workspace actually recorded. The same rule binds the drafting agent, and harder. A visual it draws must name the data it came from, and every point has to match a row that data returned. If it doesn't, the draft fails and Squad rewrites it rather than shipping a chart nobody can check. A brief with nothing worth showing gets prose and no visuals, which is a correct answer. Squad will add at most six. Set a visual's width to **half** or **third** and consecutive ones sit side by side, so a brief can open like a dashboard and still read like a document. A visual is a snapshot, taken when the brief was written. It doesn't refresh. That's deliberate: a brief argues a case as of its evidence date, and a chart that moved afterwards would quietly change the argument you signed off. Visuals behave like any other block. Click the handle to drag one, or select and delete it. To change one, delete it and insert a new one. A card, table cell, callout or timeline entry can link a signal, insight, goal or document, and those links show up in the **Evidence** panel exactly like a reference in the prose. **Copy as markdown** and **Download .md** include visuals as fenced code blocks, so nothing is lost when a brief leaves Squad. If a visual can't be drawn, the brief shows a bordered "This block can't be displayed" card with the raw content behind a toggle, rather than an empty chart that would read as a real measurement of zero. ## Reviewing and editing Open a brief from the library or from any linked reference. In **Draft**, the body is a full editor. Edit the title inline, rework the draft, add or remove references. **History** shows every change and a badge marks who last touched it, you or Squad. Use the action menu to **Copy as markdown** or **Download .md** to take it outside Squad, or **Push to Linear** to turn the brief into an issue with a sub-issue per action it produced. All three appear once there's a body to export. **Delete** removes the brief. ## The library The Briefs page lists everything in the workspace, most recently updated first. It opens as a card grid, with a list view available. Both show the `BR-` reference, the title (or "Drafting…" while building), a clickable status badge, and when it last changed. Decision briefs also show their **Decision** badge and current recommendation. To see the evidence a brief came from, open it and read the **Evidence** panel. Search with **Search briefs or BR-…** and use the **Status** filter to pull up everything **In review**, or every **Decided** brief. Search and filters look inside folders and return the briefs themselves, so nothing hides behind a folder that doesn't match. Documents created or updated anywhere appear here without a refresh. ## Folders Once a workspace has thirty briefs, "most recently updated" stops being an organising principle. Folders fix that. Click **New folder** and Squad creates one where you are and drops you straight into naming it. Folders nest as deep as you want. In the card grid, folders gather above the briefs as filled tiles, each with the number of briefs it holds. Brief cards stay white and bordered. One glance tells you which is which. Click a folder to open it. In the card grid it opens in place, with a breadcrumb trail under the toolbar to step back up. In list view it expands inline instead. Either way you stay on the Briefs page with the same header, search box, and view toggle. Drag a brief onto a folder to file it there. Drag it onto the empty area to move it back to the level you're viewing. Folders move the same way, and Squad blocks a move that would put a folder inside itself. Right-click a folder, or use the `⋯` button on its card, for **New folder**, **Rename**, and **Delete**. Deleting a folder deletes every brief inside it, so the confirmation says so. Open a brief and its breadcrumbs name the folders it sits in, each one a link back to that folder's contents. The back arrow returns you to the folder rather than the top of the library. Two smaller behaviours worth knowing. **Create brief** files the new brief in the folder you have open, so generating from inside **Q3 pricing** lands it there rather than at the top level. And folders here are separate from the ones in [Knowledge](/knowledge-documents): a folder you make on this page holds briefs and shows up on this page only. ## Cookbook **Turn a strong insight into a shareable PRD.** Click **Create brief**, search for the insight, choose **PRD**, and generate. Wait for it to leave **Building**, then tighten the requirements while it's in **Draft**. Check the **Evidence** panel to confirm the claims trace to real signals. Move it to **In review**, or copy it as markdown into your spec tool. **Make a Build, Defer, or Research call.** On the action, choose **Generate decision brief**. Once drafted, read the cited case and check the "for, against" balance in **Info**. Edit anything you disagree with while it's in **Draft**, move it to **In review** so it lands in **Briefs to review**, then click the status badge and **Mark decided**. **Recover a draft that didn't generate.** Open a brief in **Failed**. The body explains what went wrong. Click **Retry** if the source still looks right, or **Start blank** to write it yourself. Either way it keeps its `BR-` reference and its place in the library. # Chat assistant Source: https://docs.meetsquad.ai/chat-assistant Ask Squad to do the work. The assistant runs real operations against your workspace, and what it changes is changed for everyone. Ask the assistant to create a goal and a goal is created. It runs the operation and reports back what it did. Nothing to copy out of a reply and redo by hand. Chat assistant Chat assistant ## Opening the panel The panel starts minimised, as an **Ask your Squad** button in the bottom right corner. Click it to open. On a phone the same button sits in the pill at the bottom of the screen. Five modes, and whichever you pick is remembered between sessions. | Mode | Behaviour | | - | - | | Minimised | The **Ask your Squad** button, out of the way | | Floating | A panel you drag by its header and resize from the corner | | Docked left | Pinned to the left edge, width draggable | | Docked right | Pinned to the right edge, width draggable | | Fullscreen | The whole window | Switch between them from the `···` menu in the panel header. The expand icon toggles fullscreen and back to docked right. The minus minimises. The pencil starts a new conversation. Docked right is what you get the first time you open the panel, and it opens by itself on a brand new workspace so [setup](/quickstart) can start without you finding it. On desktop, changing mode or minimising mid-reply does not interrupt it. The reply carries on in the new layout, or is waiting for you when you reopen the panel. ## What it does to your workspace The assistant carries a tool for nearly every operation the app exposes. It reads and writes the same records the UI does, scoped to the workspace you're in. Create, read, update, delete, list. See [Goals](/goals). Create, read, list, update, start, complete, snooze, dismiss, and link an action to the insight it came from. See [Actions](/actions). Create, read, list, and link an insight to a goal. See [Insights](/insights). List, read, dismiss, create one by hand, find related signals, and ingest external feedback as new signals. See [Data signals](/signals). List, read, and write a theme label onto a cluster. See [Signal clusters](/signal-clusters). Create, read, update, delete and tag documents, append blocks to an existing one, list the available templates, create and rearrange folders, search the knowledge base by meaning, and find documents related to one you name. It checks for a near-duplicate before it writes anything new. See [Knowledge and documents](/knowledge-documents). Read and update the workspace record itself, which is how the setup conversation saves your product name and description. See [Workspace settings](/workspace-settings). Search the web, read a page, and start a background research run that keeps writing documents after the conversation moves on. Search and read the built-in expert product-management guides, check whether your product already covers a capability, and search or resume your past conversations. Every active integration contributes its own read and write tools, so with Slack connected the assistant can read and post in Slack from the chat. See [Integrations](/integrations). Briefs are the exception. The assistant does not draft them from chat. Generate a PRD or a decision brief from an [action](/actions) or an [insight](/insights), and the drafting runs in the background. ## Sub-agents For work too large for a single reply, the assistant hands off to one of three sub-agents and streams their progress into the conversation as their tools run. Searches the web, reads pages, checks the expert guides, and writes documents from substantial findings Goal alignment, gap analysis, and prioritisation recommendations grounded in your goals and documents Cross-references several of your documents into one summary with citations ## Changes are real and shared Everything the assistant does is a workspace mutation, not a draft. A goal it creates appears on the Goals page for every member of the workspace, live, without a refresh. An action it completes disappears from your dashboard and from theirs. Each change is recorded in [Activity](/activity) with Squad as the actor. The **Squad** line on the dashboard's **Recent activity** chart is that record plotted over fourteen days. Deletions go through the same route. Ask the assistant to delete a goal and it is deleted for everyone. A document it deletes goes to [Trash](/knowledge-documents#trash) for 30 days. Name the thing you want removed precisely. ## Writing to it The input reads **Ask, Search or Chat... (@ to mention)**. **Mentions.** Type `@` to pull a specific record into the conversation. The picker searches your documents, folders, goals and insights. A mentioned record is loaded into context, so "summarise @Q3 pricing research against @Reduce churn" needs no further explanation. **Attachments.** The paperclip takes JPEG, PNG and WebP images up to 7 MB each, and PDFs up to 10 MB. Five files per message, 50 MB in total. Once a conversation holds more than that, the assistant reads the most recent attachments and sees only the filename of the rest, so attach a file again on a later message if you need it read. **Dictation.** The microphone transcribes speech into the input. **Integrations.** The blocks icon lists your connected providers with a switch each. Turn one off and the assistant loses that provider's tools for the rest of the conversation. An empty conversation offers four starting points. **Deep Research**, **Analyze Patterns**, **Strategic Review** and **Knowledge Synthesis**. Clicking one fills the input so you can edit it before sending. After a reply lands, follow-up suggestions appear above the input as chips. ## Conversations Every conversation is saved and titled from its content. Open the title dropdown in the panel header for the full history and click one to resume it, with the whole thread intact. Reload the page and the panel returns to the conversation you were on. If a reply was mid-stream, it reattaches and finishes. That memory is per tab, so a second tab opens on a blank conversation, and so does a reload whose conversation has been deleted in the meantime. Your workspace context, meaning the product name, mission, top goals, knowledge base structure and connected integrations, is loaded into every conversation. You never have to re-explain your product. ## Getting more out of it Be specific. "Rank the top five insights by how well they support our retention goal, then tell me which action to start" gets a better answer than "what should we do?" Point at records with `@` rather than describing them. Ask for follow-through, since the assistant can create the goal and the action itself. Then check the result on the page it changed. # Command reference Source: https://docs.meetsquad.ai/cli/commands Every Squad CLI command, grouped by area, with its arguments and flags. Thirty-three commands across thirteen areas. They all assume you've run `squad auth login` and `squad workspace select`. See [Squad CLI](/cli/overview) for setup. `squad --help` also lists `squad research list` and `squad research create`. They call operations this platform doesn't serve and return an error, so they're left out below. ## Display IDs Most commands take a short display ID instead of a UUID. UUIDs work everywhere a display ID does. | Prefix | Entity | Prefix | Entity | | - | - | - | - | | `SI-` | Signal | `GL-` | Goal | | `IN-` | Insight | `BR-` | Brief | | `AC-` | Action | `DC-` | Document | | `CL-` | Cluster | | | ## The commands | Command | What it does | | - | - | | `squad auth login` | Browser OAuth 2.1 PKCE flow, then auto-selects a workspace when only one is reachable | | `squad auth logout` | Clears the stored session and workspace selection | | `squad auth status` | Reports whether a session exists, its expiry, and whether it has expired | | Command | What it does | | - | - | | `squad workspace list` | Every organisation and workspace you can access | | `squad workspace select ` | Sets the active workspace for later commands | | `squad workspace overview` | Mission, top goals, recent signal activity, chain health, open work counts | | `squad workspace update` | Edits the current workspace | | `squad workspace members` | People in the organisation with their user IDs | `squad workspace update` takes `--name`, `--description`, `--mission-statement` and `--logo-url`. Use `squad workspace members` to find the user ID you need for `squad action update --assignee`. Raw feedback. See [Signals](/signals) for what they are and where they come from. | Command | What it does | | - | - | | `squad signal list` | Browse signals with filters | | `squad signal similar ` | Signals semantically close to a given one | | `squad signal ingest` | Push feedback into the evidence chain | | `squad signal dismiss ` | Permanently delete a signal | `squad signal list` flags: `--source`, `--type`, `--sentiment`, `--cluster `, `--since `, `--until `, `--include-dismissed`, `--limit`, `--offset`. `squad signal similar` takes `--limit` (default 5, max 20). `squad signal ingest` takes either a single item or a file: ```bash Single item theme={null} squad signal ingest \ --content "Export to CSV times out on accounts over 50k rows" \ --source zendesk \ --source-url https://support.example.com/tickets/4821 \ --author "Priya N" \ --strength 0.8 ``` ```bash From a file theme={null} squad signal ingest --file ./feedback.json ``` `--file` points at a JSON array of 1 to 50 signal objects. Other flags: `--title`, `--occurred-at `. Content is deduplicated server-side, then clustered and distilled asynchronously. `squad signal dismiss` deletes the signal. It cannot be recovered. `--reason` records why in the command output. Recurring themes across signals. See [Signal clusters](/signal-clusters). | Command | What it does | | - | - | | `squad cluster list` | Clusters with sizes and labels | | `squad cluster get ` | Label, stats, member signals and linked insights | `squad cluster list` flags: `--type`, `--include-unlabeled`, `--limit`, `--offset`. | Command | What it does | | - | - | | `squad insight list` | Insights ranked by combined score | | `squad insight update ` | Set category or status, link or unlink a goal | `squad insight list` flags: `--goal `, `--category`, `--min-score`, `--status`, `--limit`, `--offset`. `squad insight update` flags: `--category`, `--status`, `--link-goal`, `--unlink-goal`. Titles and descriptions come from the pipeline and are not editable. | Command | What it does | | - | - | | `squad action list` | Ranked actions, filtered | | `squad action context ` | The action, its insight, the evidence and the goals it serves | | `squad action status ` | Move it through its lifecycle | | `squad action update ` | Edit metadata, assign, or link it | `squad action list` flags: `--statuses `, `--assignee `, `--insight `, `--priority `, `--include-snoozed`, `--limit`, `--offset`. `squad action status` takes `start`, `complete`, `dismiss` or `snooze`, plus `--note` to append a line to the action's notes. ```bash theme={null} squad action status AC-12 complete --note "shipped in PR #482" ``` `squad action update` flags: `--priority`, `--effort `, `--category `, `--notes` (replaces the field), `--assignee `, `--link-insight`, `--link-brief`. Run `squad action context` before writing code against an action. One call returns the customer quotes and source links behind the work. | Command | What it does | | - | - | | `squad goal list` | Goals ordered by importance | | `squad goal create` | Create a strategic goal | | `squad goal update ` | Edit title, description or importance | `squad goal list` flags: `--min-importance`, `--limit`, `--offset`. `squad goal create` requires `--title` and `--description`, and accepts `--importance` (1 to 5, default 3). `squad goal update` flags: `--title`, `--description`, `--importance`. See [Knowledge documents](/knowledge-documents). | Command | What it does | | - | - | | `squad document list` | Documents with paths and tags | | `squad document create` | Create a document from markdown | | `squad document update ` | Replace body or title, manage tags | `squad document list` flags: `--tag`, `--limit`, `--offset`. `squad document create` requires `--title` and `--markdown`, and accepts `--directory` and `--tags` (comma separated). A near-identical title returns the existing document rather than creating a duplicate. `squad document update` flags: `--markdown`, `--title`, `--add-tags`, `--remove-tags`. Briefs. See [Briefs](/briefs). | Command | What it does | | - | - | | `squad brief list` | Briefs with status and recommendation | | `squad brief generate` | Start AI generation of a brief | | `squad brief status ` | Move a brief through review | `squad brief list` flags: `--status `, `--type `, `--source-insight`, `--limit`, `--offset`. `squad brief generate` takes `--action `, `--insight ` or `--retry `, plus `--type `. Generation is asynchronous, so poll the returned `BR-` ID with `squad get`. ```bash theme={null} squad brief generate --action AC-12 --type decision squad get BR-7 ``` `squad brief status` accepts `draft`, `in_review` or `finalised`. The `building` and `failed` states belong to generation and cannot be set by hand. | Command | What it does | | - | - | | `squad integration list` | Connected feedback sources and their sync health | Connect and configure sources in the app. See [Integrations](/integrations). | Command | What it does | | - | - | | `squad activity` | Workspace change feed, newest first | | `squad search ` | Keyword search across the workspace | | `squad get ` | Fetch any entity by display ID or UUID | `squad activity` flags: `--entity-types `, `--actor-type `, `--agent-id`, `--limit`, `--after `. See [Activity](/activity). `squad search` flags: `--types `, `--limit`. Matching is on title and content, so pick real keywords. `squad get` accepts `--include evidence` on insights to pull the supporting signals with their source links. Documents come back as markdown. ```bash theme={null} squad get IN-42 --include evidence ``` # Squad CLI Source: https://docs.meetsquad.ai/cli/overview Install the Squad CLI, log in with OAuth, pick a workspace, and work the evidence chain from your terminal. Squad CLI Squad CLI The Squad CLI puts signals, insights, actions, goals and decision briefs behind a `squad` binary. It speaks to the same API the web app uses, scoped to one workspace. Output is JSON by default, so pipe it into `jq` or hand it to a coding agent. ## Set up ```bash theme={null} npm install -g @squadai/cli ``` Node.js 22 or newer. The binary installs as `squad`. Check it worked: ```bash theme={null} squad --version ``` ```bash theme={null} squad auth login ``` This opens your browser and runs an OAuth 2.1 authorization code flow with PKCE. The CLI registers itself as a public client against a loopback redirect, so nothing needs pre-configuring. Requested scopes are `read:workspace`, `write:workspace`, `openid` and `email`. The opaque token from that flow never talks to the API. The CLI exchanges it for a short-lived service JWT scoped to one organisation, then re-exchanges on its own when the JWT nears expiry. Check where you stand: ```bash theme={null} squad auth status ``` It reports whether a session exists, when it expires, and whether it has already expired. `squad auth logout` clears the stored session and the workspace selection. Every command runs against one workspace. Login tries to pick one for you. If your identity reaches exactly one workspace, login selects it and says so. With more than one, login lists what it found and asks you to choose. ```bash theme={null} squad workspace list squad workspace select ``` `squad workspace list` prints the organisations and workspaces you can access, with the current selection marked. Pass the IDs from that output to `select`. The choice persists on disk, so you do this once per machine (or when you switch). Commands fail fast with `No workspace selected` until you have run `squad workspace select`. That holds even when you supply a token yourself. ```bash theme={null} squad workspace overview ``` One call returns the mission statement, top goals, signal activity for the last seven days, evidence-chain health and open work counts. Start sessions here. ## Version compatibility The `0.4.x` line targets the current Squad platform, the one behind [app.meetsquad.ai](https://app.meetsquad.ai). The `0.3.x` line targets the previous Squad product and speaks a different API. If your workspace is still on the older product, pin to the older line: ```bash theme={null} npm install -g @squadai/cli@0.3.x ``` Don't mix them. A `0.3.x` binary pointed at the current platform fails on every call. ## Configuration files State lives in `~/.config/squad/`, or `$XDG_CONFIG_HOME/squad/` when that variable is set. The directory is created with `0700` and files with `0600`. | File | Holds | | - | - | | `auth.json` | The OAuth session (access token, refresh token, expiry) and cached service JWTs | | `client.json` | The OAuth client ID registered during login | | `workspace.json` | The selected organisation and workspace | Treat `auth.json` as a credential. Deleting the directory is equivalent to `squad auth logout`. ## Global flags | Flag | Effect | | - | - | | `--format ` | Output format for list commands. Default `json`. | | `--token ` | Use a service JWT instead of the stored session. | | `--version` | Print the installed version. | | `--help` | Print help for any command or subcommand. | Commands that return a single record always print JSON. ## Headless and CI use Set `SQUAD_TOKEN` to a service JWT to skip the browser flow. `--token` takes precedence over it. A workspace selection must already exist in the config directory, so run `squad workspace select` once on the machine (or ship a `workspace.json`) before automating. ## Where to go next Thirty-three commands across thirteen areas, with their arguments and flags. The same capabilities inside an AI assistant rather than a shell. # Cookbook Source: https://docs.meetsquad.ai/cookbook End-to-end recipes that stitch several Squad features together, from raw feedback to a shipped decision. Cookbook Cookbook Each per-feature page has its own focused cookbook. These recipes are the ones that cross the whole product. They assume you've connected at least one source. If not, start with the [Quickstart](/quickstart) and [Integrations](/integrations). The full chain, start to finish. A repeatable loop built around the dashboard. Find the theme behind a jump in pain-point feedback. Goal, evidence, actions, owners. Configure a trigger, get a report each run. Follow a claim down to the original quote. POST feedback from a helpdesk, survey tool, or app. Reconstruct how something got to where it is. ## From raw feedback to a shipped decision Connect a source (see [Integrations](/integrations)) or pipe data in over the ingestion API. Feedback starts arriving as **signals** under **Insights → Data Signals** ([Data signals](/signals)). Related signals become **clusters**, themes like "slow search" or "requests for SSO" ([Signal clusters](/signal-clusters)). When a theme is strong enough, Squad synthesises it into a scored **insight** (`IN-…`). Open it to read its strength and momentum and the signals behind it. Link it to a **goal** it supports ([Goals](/goals)). Squad recommends **actions** off the insight ([Actions](/actions)). Prioritise them, assign an owner, and **Start** the ones with a chat prompt to hand them to the assistant. Generate a **brief** ([Briefs](/briefs)). A PRD specs the work. A decision brief makes the call. Either one cites the evidence automatically. Review the brief on the [Dashboard](/dashboard) under **Briefs to review**, choose **Build**, **Defer**, or **Research**, and **Mark decided**. ## Your weekly triage routine Open the [Dashboard](/dashboard). The caption above the greeting tells you when the daily brief was written. Start, mark done, or dismiss each. What is done drops off automatically. Decision briefs waiting on a call, and PRDs sitting in draft or review. Anything surprising in the last day. Once you have changed the picture, so the next brief reflects it. ## Investigate a spike in complaints Open **Insights** and switch to the **Signal Clusters** tab ([Signal clusters](/signal-clusters)). Filter by **Type → pain point** and sort by **Data Signals** descending. Open the largest cluster and read the **Members** quotes, the real feedback. If it's already an insight, follow the linked `IN-…` and decide whether it needs a goal or an action behind it. If not, ask the [assistant](/chat-assistant) to draft one. ## Turn a quarterly goal into tracked work Create it on the [Goals](/goals) page. Open its **Insights** tab and link them. This is the evidence for why the goal exists. From those insights, accept the **actions** Squad recommends and give them owners ([Actions](/actions)). As work lands, the goal's linked insights and actions keep it honest. You can always trace the goal down to the feedback driving it ([Relationships](/relationships)). ## Let an agent watch something for you Go to **Agents → New** and configure what to watch (a URL, a Slack channel, a Notion space, or a workspace event) plus how often it runs ([Agents](/agents)). Give it instructions and, if you want a written brief each run, a report question and where to deliver it. Each run produces a **report** and folds new findings into your signals, clusters, and insights, the same pipeline everything else uses. ## Trace any decision back to its evidence Nothing in Squad is an unsourced claim. A goal, insight, action, or brief. A goal's **Insights** tab → an insight's supporting signals → a signal's original quote and source. Anywhere a reference chip like `SI-12`, `IN-4`, `AC-7`, or `BR-3` appears, click it to jump straight to that entity. See [Relationships](/relationships), or ask the [assistant](/chat-assistant) "what's the evidence behind this?". ## Bring your own data over the API Issuance is not self-service today. Write to [support@meetsquad.ai](mailto:support@meetsquad.ai) and say which organisation the key is for. From your own system (helpdesk, survey tool, app), POST feedback to `/api/v1/signals` with a sensible title and any `metadata` you want to keep. Everything arriving this way is recorded against the `api` source. Ingested signals join the pipeline exactly like integration data. Clustered, scored, and surfaced as insights, with no further work from you. No screen in the app mints an API key and no CLI command does either. Step one is the only way to get one. ## See who changed what When something looks different from yesterday, open the [Activity](/activity) feed. It records every create, update, and decision across the workspace, by teammates and by Squad itself. Use it to reconstruct how a goal, insight, or brief got to where it is. # Dashboard Source: https://docs.meetsquad.ai/dashboard Your daily home. What each widget shows, what drives it, and which ones stay empty on a young workspace. The dashboard is your workspace home page. It holds a greeting, two counters, a health score, the actions to work through, an activity chart, the briefs waiting on you, your connected providers, and the freshest evidence. Dashboard Dashboard Most widgets are driven entirely by workspace data and show an empty state until that data exists. Each section below says what fills it. ## The greeting and daily brief A time-of-day greeting leads with your first name, either "Good morning", "Good afternoon", "Good evening", or "Up late" before 5am. Above it, a caption records when your daily brief was written ("Daily brief generated at 08:14") with a **Re-brief** button beside it. The brief is produced once a day and cached, so the page loads instantly. Press **Re-brief** after a triage session to regenerate it against the current state of the workspace. The button spins while it works. If no brief can be produced, the caption disappears and you get the plain greeting. Nothing else on the page is affected. ## Counters and context health Two counters sit next to a workspace health card. **Data Signals ingested** counts the active [signals](/signals) in the workspace. **New signals** counts the ones that arrived in the last 24 hours, so it reads zero on any day nothing came in. Both link through to the Signals page. If the numbers can't load, the pills show an error rather than a misleading zero. **Context health** scores the workspace from 0 to 100 and labels it Starved, Lean, Healthy, Bloated or Flooded. Five components make up the score, listed under the info icon in the corner. | Component | What it measures | | - | - | | Coverage | How many kinds of product context Squad has access to | | Freshness | How recently signals, documents and sources were updated | | Headroom | How far the knowledge base is from what agents can read at once | | Uniqueness | How free the knowledge base is of near-duplicate documents | | Utilization | How much of the gathered context is actually being read | Press **Improve** for the full breakdown plus a list of recommendations, each with a button that acts on it. Connect an integration, add goals, check an agent, review documents, compact the knowledge base. A brand new workspace is treated as a cold start and reads "A fresh workspace starts empty. Connect a source or two to get going." ## Prioritized actions The widget lists open [actions](/actions) from across the workspace, both suggested and in progress, sorted by priority (P0, then P1, then P2), then by due date, then by recency, capped at eight. Its subhead reads "What actions to do, in order". Actions whose underlying insight has gone stale or been archived drop out. Due dates show where an action has one, and most don't. An action without a due date still appears in the list, with a blank date cell. Work a row without leaving the page. **Start with Squad** hands the action to the chat with its full context and moves it to in progress, at which point the button becomes **Continue with Squad**. Ticking a row marks it done, with a short strikethrough before it leaves the list so you can undo a mis-click. Priority and owner are editable inline. The row menu holds **Snooze 3 days**, **Dismiss**, **Generate PRD** and **Generate decision brief**. Clicking the row opens the action. With nothing open the widget reads "You're all caught up. New priorities will appear here." **See all** goes to [Actions](/actions). ## Recent activity A 14-day chart plots two lines, **Squad** (what the agents did) against **You & team** (what people did). Read it for how much of the work is running on its own. A workspace with no changes in the last fourteen days shows "No activity in the last 14 days" instead. You get the same message when everything was loaded further back than that. **See all** goes to [Activity](/activity). ## Briefs to review [Briefs](/briefs) in draft or in review, up to ten, in either type. Each row carries its `BR-` reference, the title, when it was last updated, a status you can change from the row, and a menu. Click the title to open it. The list updates live as documents change anywhere in the workspace. With nothing waiting it reads "Nothing waiting on review." **See all** goes to [Briefs](/briefs). ## Integrations A grid of provider icons, connected ones first, up to twelve with a `+n` tile for the rest. A green tick marks a connected provider, an amber badge marks one that still needs setup. The subhead counts how many are connected. Click any icon to open that provider. **See all** goes to [Integrations](/integrations). This widget never sits empty, because it lists every provider Squad supports rather than only the ones you've connected. ## New evidence The ten freshest active [signals](/signals), each shown as a quote with its source. Click a quote to open the signal. With nothing yet it reads "No new signals yet." **See all** goes to [Data signals](/signals). ## Getting around from here The sidebar and the command palette (**Cmd/Ctrl+K**) reach the rest of the workspace. The sidebar, the command palette and reference chips Handing the work to Squad instead of doing it yourself # Getting around Source: https://docs.meetsquad.ai/getting-around The sidebar, the command palette, reference chips, and how to reach Activity, which has no sidebar entry. Nine destinations sit in the sidebar and everything else is a keystroke away. One page, Activity, has no sidebar entry at all. Getting around Getting around ## The sidebar The workspace switcher sits at the top, showing the current workspace with your organisation underneath. Below it are three quick actions. **Home**, **Search** (which opens the command palette), and your notification **Inbox**. The main list follows, in this order. * **Agents.** Agents that watch your sources and write up what they find. * **Goals.** The objectives you're working toward. * **Insights.** The scored findings drawn from your evidence. * **Actions.** Suggested and in-progress next steps. * **Briefs.** PRDs and decision briefs. Three more are pinned to the bottom. * **Knowledge.** Documents, folders and version history. * **Integrations.** The services you've connected. * **Settings.** Workspace name, logo, and preferences. See [Workspace settings](/workspace-settings). Your account sits below those. Click your avatar for the organisation switcher, the theme picker (Light, Dark, System) and log out. The current page is highlighted. **Insights** stays highlighted while you're on a signals page, since signals and insights are two views of the same chain. Press **Cmd/Ctrl+E** to collapse the sidebar to icons and again to expand it, or hover the panel and click the chevron near its right edge. **Home** is the [Dashboard](/dashboard). ## The page with no sidebar entry You reach it through a link or the URL bar. The record of who changed what. Reach it from **See all** on the dashboard's **Recent activity** widget, from **All activity** at the foot of your notification inbox, or from **All activity** next to the **History** section on an insight, goal or brief detail page (those arrive pre-filtered to that entity type). See [Activity](/activity). ## The command palette Press **Cmd/Ctrl+K**, or click **Search** in the sidebar. Start typing a command or a search term. The palette opens on **General**. **Copy URL** puts a link to the current page on your clipboard, and **Switch Theme** leads to Light, Dark and System. Next comes **Navigation**, the same nine destinations as the sidebar. Below that sit your **Documents** and **Folders**, matched on both title and path. Type more than a word or two and three live search groups appear. **Insights**, **Goals** and **Data Signals**, each result showing its title and reference (`IN-12`, `GL-4`, `SI-88`). A **Workspaces** group at the bottom switches workspace, with the current one marked **Current**. Selecting any result takes you there and closes the palette. Escape dismisses it. ## Reference chips Entities link to each other through reference chips, small clickable tags carrying an ID. Click one to open the item. They show up in the daily brief, inside briefs, on action rows, in goals and in agent messages. Each type has its own prefix, so you can read a reference without context. | Prefix | Entity | | - | - | | `IN-` | Insight | | `GL-` | Goal | | `AC-` | Action | | `BR-` | Brief | | `SI-` | Data signal | | `CL-` | Signal cluster | | `DC-` | Document | Folders carry no prefix, so you reach those by name. ## Switching workspace and organisation Click the workspace switcher at the top of the sidebar for a list of every workspace in the organisation, each with its description, the current one ticked. **Create workspace** at the bottom starts a new one, which begins with its own [setup conversation](/quickstart). The **Workspaces** group in the command palette does the same job in fewer keystrokes. Goals, insights, actions, briefs, knowledge, integrations and settings all belong to one workspace and never leak between them. Organisations are one level up. Switch between them from the account menu at the bottom of the sidebar. Squad sends you to that organisation's default workspace. ## On mobile A pill floats at the bottom of the screen instead of the sidebar, carrying two buttons. A menu, and **Ask your Squad** for the chat panel. The menu opens a grid of **Home**, **Search**, **Inbox** and **Knowledge**. A divider follows, then the full list of Agents, Goals, Insights, Actions, Briefs, Knowledge, Integrations and Settings. Search there is the same command palette you get on desktop. ## When the connection drops Squad keeps open pages live over a single connection, so a teammate's change appears in front of you without a refresh. Close your laptop, change networks, or wait out a VPN reconnect and that connection goes away for a while. When it returns, Squad confirms the network is genuinely carrying traffic before it reloads anything. A connection can report itself back seconds before requests actually succeed, and firing every query into that gap is how a page ends up quietly out of date. If that takes more than a moment, a message reads **Some data may be out of date**. There is nothing to click. Squad keeps checking on its own, spacing the attempts further apart the longer an outage runs, and the message disappears the moment your data is current again. Switch to another tab and it stops checking until you come back, so a laptop left open overnight is not sitting there retrying. You do not need to reload the page, and reloading will not make it faster. # Goals Source: https://docs.meetsquad.ai/goals What your team is working toward, and how Squad uses it to decide what matters. A goal is what your team is trying to achieve, written down where Squad can read it. "Cut enterprise churn below 8%". "Ship SSO by Q3". Goals give Squad the frame it needs to tell an interesting finding from a relevant one. Goals Goals For where goals sit in the chain, see [The evidence pipeline](/pipeline). ## What a goal does Squad reads your goals in two places. Squad decides which goals it supports and writes those links itself. You'll find them already attached on the insight's **Goals** panel. Squad sees your goals and their importance, and ranks what it hands back by relevance to them. An insight that supports a 5-importance goal is treated as more urgent than an equally-evidenced one that supports nothing. A goal never changes an insight's score. Insight scores come from evidence alone (volume, source diversity, recency). Raising a goal from importance 3 to 5 won't move a single number on the Insights page. It changes how Squad weighs relevance when choosing and ordering work. ## Creating a goal Squad creates an untitled goal and opens it immediately with the title selected, so you can type straight over it. Title, description, and importance are all edited in place. There's no save button. **Importance** is five squares, 1 to 5. Set it by clicking the square you want. Use the range honestly. If everything is a 5, importance tells Squad nothing. ## The Goals list The Goals page opens as a card grid. Switch to the list view from the toolbar if you prefer rows. Each goal shows its `GL-` reference, title, importance, and the date it was created. Search and filters work the same as everywhere else in Squad, and the state is held in the URL. Right-click a card or row for **Open**, **Copy ID**, **Copy URL**, **Copy content as JSON**, and **Delete**. ## Inside a goal **Insights.** The top five insights linked to this goal, as a table. **Manage** (or **Add insight** when there are none) opens the full list in a dialog where you can search for insights and attach them, or remove ones that don't belong. Removing a link leaves both the goal and the insight intact. See [Relationships](/relationships). **Info.** Importance, the number of linked insights, and the creation date. **Referenced by.** Any brief or knowledge document whose body cites this goal. **History.** Every change to the goal, and who or what made it. ## How many goals to keep Enough to cover what the team is actually working on, few enough that the importance scale means something. Five to ten active goals with honest importance values give Squad a usable signal. Thirty goals all set to 5 give it none. ## Cookbook **Set up a quarter.** Create one goal per quarterly objective. Write the description as the outcome you want, not the feature you plan to build. Set importance so the top two are 5 and the rest sit lower. Then open your highest-scoring insights and check which goals Squad attached. **Find the strategy gap.** Open a goal with zero linked insights. Either your evidence says nothing about it (which is a signal in itself) or the goal needs rewriting to be specific enough to match. **Build the case for a goal.** Open the goal, read its linked insights top to bottom, and use the strongest one to generate a [brief](/briefs). The document will cite the evidence back to individual customer quotes. # Welcome Source: https://docs.meetsquad.ai/index Squad reads the feedback your customers already give you, works out what it adds up to, and tells you what to build next. Squad Squad Squad is your AI product manager. It reads support threads, sales calls, app store reviews, issues and chat, then hands you the next step with the evidence still attached. ## The chain One chain runs through the whole product. Every screen shows one stage of it. Connected sources hand Squad raw text. Squad breaks each piece into the specific claims it contains, one per **data signal**, and keeps the customer's own words. Signals that mean the same thing group themselves into **clusters**. Clusters get synthesised into **insights**, each scored on how well evidenced it is and whether the theme is still growing. A strong insight produces a short ranked list of **actions**. An action that needs a written argument becomes a **brief**, either a PRD or a decision brief. **Goals** steer which of that work Squad puts in front of you. Extraction, clustering, scoring and action proposal run without you. Creating goals, prioritising actions, generating a brief and making the final call are yours. [The evidence pipeline](/pipeline) walks the chain stage by stage, with the thresholds and the scoring maths. ## Get started Setting up a workspace, from the opening conversation to your first insight The sidebar, the command palette, reference chips, switching workspace Your daily home, widget by widget, and what drives each one The agent that runs real operations against your workspace ## The evidence pipeline Every stage, with the thresholds and the scoring Individual claims, each with its verbatim quote and source Themes formed from signals that mean the same thing Scored findings, and how strength and momentum combine The objectives that steer what Squad recommends PRDs and decision briefs, backed by cited evidence Concrete next steps, in priority order How entities link, and how to trace a decision back to a customer sentence ## Knowledge Your document library, folders, and version history Who changed what, and when ## Agents Agents that watch your sources and write up what they find Prebuilt agents you can start from Schedules and events that set an agent running What an agent is allowed to read and write Run history, output, and what to do when one fails ## Bringing data in Connecting third-party sources Channels, threads, and posting back Watching pages and reading them from an agent Call recordings and transcripts ## Your workspace Name, logo, and how organisations and workspaces relate What Squad tells you about, and how ## Recipes Walkthroughs that stitch several features together, from raw feedback to a shipped decision, live in the [Cookbook](/cookbook). # Insights Source: https://docs.meetsquad.ai/insights What your evidence adds up to, scored so you can tell a real pattern from a loud one. An insight is Squad's conclusion about a group of evidence. It reads "export is unusable above 10k rows and it is costing you enterprise renewals", rather than "twelve people mentioned export speed". Every insight carries an `IN-` reference, a score, the signals behind it, and the goals it bears on. Insights Insights For how insights get created, see [The evidence pipeline](/pipeline). ## The list hides positive insights by default The **Hide positive** toggle at the top of the Insights list is on when you first arrive. It filters out everything categorised as a positive signal, so the list is shorter than the number of insights the workspace actually holds. Turn the toggle off to see them. You're usually here to find what's broken. When the filter leaves the list looking empty, the empty state says "Positive insights are hidden." ## The Insights list Sorted by score, highest first. Each row shows the `IN-` reference and title, the score bar, the number of linked goals, the number of supporting signals, and the creation date. Hover the score bar to see the split between **Strength** and **Momentum**. Search with **Search insights or IN-…**. Filter by **Score**, **Goals**, or **Data Signals**, each with presets and a "greater than or equal to" default. Sort and filter state lives in the URL. Right-click a row for **Open**, **Copy ID**, **Copy URL**, **Copy content as JSON**, and **Delete**. **Import Insights** in the top right brings in insights you already hold elsewhere. You can also drag files onto the page to have Squad read them. ## How the score works The score is a number between 0 and 1 with two components. It combines the volume of supporting signals, statistical confidence in that volume, how many distinct customers those signals came from, and how many different kinds of source corroborate it. Evidence concentrated in one loud customer scores lower than the same volume spread across many. A young insight is pulled toward the workspace baseline rather than crushed to zero. Recent signals count for more than old ones, a burst of arrivals lifts it, and the last four weeks of arrivals are read as accelerating, steady, or decelerating. The combined number weights strength at 60% and momentum at 40%. Scores move when new evidence reaches the insight. They don't decay on their own, so an insight that stopped receiving signals keeps its last score. Read the score alongside the date and the signal count. ## Category and status **Category** is yours to change from the detail page. The options are Pain Point, Feature Request, Positive Signal, Trend, and Risk. Recategorising an insight as Positive Signal hides it from the default list view. **Status** is read-only, a freshness indicator Squad manages. Four values. * **Active** * **Stale** * **Archived** * **Resolved** An insight goes stale when nothing new arrives for a while. The window depends on how fast your workspace normally moves. ## Inside an insight The page opens with the title and description. **Representative data signals.** Up to three quote cards showing the actual customer words behind the conclusion. **View all** opens the full table when there are more. **Squad recommends.** The purple panel on the right holding the ranked actions for this insight. If there are none yet, you can ask Squad to propose some from here. See [Actions](/actions). **Info.** Category, status, the score breakdown, and counts of linked goals and supporting signals. **Goals.** The goals this insight bears on, with **Link goals** (or **Manage links** once there are some) to change them. See [Relationships](/relationships). **Referenced by.** Any brief or knowledge document whose body cites this insight. **History.** Every change to the insight, with a link through to full workspace activity. ## Reading a score honestly Momentum with thin evidence. Worth watching, not worth a roadmap slot. A case you can take into a planning meeting. Open the supporting signals before you commit. The score tells you how much evidence there is. Only the quotes tell you whether it's the evidence you thought it was. ## Cookbook **Find this quarter's real problems.** Leave **Hide positive** on, sort by score descending, and filter **Data Signals** to 5 or more. That's your shortlist. Open the top three and read the supporting quotes. **Check whether an insight connects to strategy.** Filter **Goals** to 0. Anything scoring well with no goal attached is either a gap in your goals or an insight nobody has connected yet. Link it from the insight's **Goals** panel. **Turn an insight into work.** Open a high-scoring insight, read **Squad recommends**, pick the action that matters, and start it. If the action's job is a written artefact, generate a [brief](/briefs) from it. # Integrations Source: https://docs.meetsquad.ai/integrations The providers Squad connects to, what each one can trigger, read and write, and how to connect them. Integrations Integrations Connecting a provider gives Squad up to three things. Events it can start an agent on, tools an agent can call while it runs, and content that becomes [signals](/signals). Not every provider gives all three. Jira Service Management, Fellow, Gong and GitHub also offer a [workflow](/workflows), which brings their content in on its own with no agent involved. The Integrations page The Integrations page Open **Integrations** in the workspace nav. Providers you've connected sit under **Connected**, the rest under **Discover**. A connection belongs to one workspace, so two workspaces in the same organisation can connect different tools. ## Every provider Capture feedback from Slack, read channel history from an agent, and get Squad's output posted back into a channel. Watch a Notion page for changes, and let an agent read the page it was triggered from. Turn recorded calls into signals on their own, and start an agent when one lands. Turn customer requests into signals on their own, and reply to them from an agent flow. Start an agent when an issue or comment changes, read your issues, and file new ones from a flow. Turn issues into signals, read a repository into your knowledge base and keep it current, and run an agent when an issue opens or a pull request merges. Query your product analytics from an agent, and run one when PostHog forwards an event. Turn AI meeting notes and transcripts into signals as Fellow finishes each one. App Store, Play Store, Google and Trustpilot reviews, imported daily as signals. ## Categories The filter in the top right offers six categories. Analytics, communication, database, developer tools, productivity and review sources. No provider uses productivity, so filtering by it always shows an empty grid. | Provider | Category | How you connect | | - | - | - | | [Linear](/integrations/linear) | Developer tools | OAuth | | [PostHog](/integrations/posthog) | Analytics | API key form | | [GitHub](/integrations/github) | Developer tools | GitHub App install | | [App Store, Play Store, Google, Trustpilot](/integrations/review-sources) | Review sources | Nothing to authorise | | [Gong](/integrations/gong) | Communication | OAuth, then a webhook key | | [Slack](/integrations/slack) | Communication | OAuth | | [Notion](/integrations/notion) | Database | OAuth | | [Jira Service Management](/integrations/jira) | Developer tools | OAuth | | [Fellow](/integrations/fellow) | Communication | API key form | ## The three ways to connect A new workspace starts with every provider under **Discover** and nothing connected. Each card carries a **Connect** button. The Integrations page before anything is connected, every provider under Discover The Integrations page before anything is connected, every provider under Discover How **Connect** behaves depends on the provider. Linear, Gong, Slack, Notion and Jira Service Management send you to the provider's consent screen. Approve there, and you land back on the integration's detail page in Squad with a green **Connected** badge. GitHub's card works the same way but takes you to a GitHub App install screen rather than an OAuth consent screen. That's where you choose the account and the repositories Squad may see. PostHog and Fellow open a dialog instead of redirecting. Each form asks for what that provider needs. PostHog wants a region, project ID and personal API key. Fellow wants your workspace subdomain and an API key. Both carry the setup steps and a link to the provider's own docs. PostHog's connect dialog, asking for a region, project ID and API key PostHog's connect dialog, asking for a region, project ID and API key The four review sources run on Squad's credentials. Clicking **Connect** takes you straight to the detail page, where you add the app, business or domain you want tracked. The integration only exists once you add your first source. ## Setup required A provider can be connected and still not working. When OAuth finishes but a step on the provider's side is outstanding, the integration sits in **Setup required**. That's an amber badge on the detail page, an amber border on the card, and a **Finish setup** button in place of **Manage**. Gong is the provider that lands there today. Its OAuth grant doesn't give Squad a way to verify inbound webhooks, so the connection waits until you paste the verification public key from your Gong webhook rule. See [Gong](/integrations/gong). ## How triggers and tools reach your agents An [agent](/agents) that starts from an integration event picks the trigger in the agent builder. The picker only lists providers that are connected and declare at least one trigger. Slack declares no agent triggers by design, so it never appears in that picker. Neither do the review sources, which declare no triggers and no agent tools, so no agent can be started by a new review. See [Slack](/integrations/slack) and [Review sources](/integrations/review-sources). A triggered agent gets the trigger provider's read tools without being granted them, so it can read the thing that started it. Gong is the one provider where that amounts to nothing, because it contributes no agent tools at all: its transcripts come in through the [Gong calls workflow](/workflows) instead. Everything else comes from that connection's row in the agent builder, set to **None**, **Read only** or **Read & write**. A few providers name their own levels, like Notion's **Can view**. Write tools only ever come from an explicit **Read & write**, so a triggered agent never writes by accident. See [Agent tools and access](/agent-tools-access). The [chat assistant](/chat-assistant) is different. It gets the read and write tools of every active integration with no configuration, because you're in the loop for every message. ## Connection health and disconnecting The detail page header shows the status. **Connected** in green, **Setup required** in amber, **Disconnected** in red when the connection failed or was revoked. Below it sit the connected account and the date you connected. If a connection predates Squad's webhook routing, the detail page shows an amber banner. Its triggers never fire until you reconnect. **Disconnect** lives in the Danger Zone at the bottom of the detail page. It drops the provider's triggers and tools, and tears down any webhook Squad registered for you. Gong is the exception. You created its rule inside Gong, so turn it off in the Gong admin as well. # Fellow Source: https://docs.meetsquad.ai/integrations/fellow Turn AI meeting notes and transcripts into signals as Fellow finishes each one. Customers say the most useful things in meetings nobody writes up. Fellow records those meetings and writes the notes. Connect it, switch on the meeting notes [workflow](/workflows), and every transcript you scope it to becomes [signals](/signals) as Fellow finishes it. Fellow integration settings Fellow integration settings ## Connect Fellow uses an API key rather than a redirect. You need a paid Fellow plan with the Developer API switched on by an admin in your workspace security settings. Create a key under User Settings, then Developer tools. Clicking **Connect** opens a form with two fields. Your workspace subdomain (the part before `.fellow.app` in your Fellow URL) and the API key. Squad registers a webhook in Fellow so new notes reach the right workspace. Disconnecting removes it again. ## Triggers One trigger, **Note generated**. It fires when Fellow finishes generating AI notes from a recording, not when a meeting is scheduled or a recording starts. ## Tools | Tool | What it does | | - | - | | **Get note** | Returns a note's AI notes, attendees and metadata, defaulting to the note that triggered the run. | | **List notes** | Returns recent notes, most recent first, filterable by title and capped at 50. | Neither brings a meeting into your feedback. That is the [Fellow meeting notes workflow](/workflows), which captures every note in scope whether or not an agent asks for it. Fellow has none. Squad reads notes and never writes back. ## Getting meetings into your feedback Switch on the **Fellow meeting notes** [workflow](/workflows) from the **By Squad** tab on the Agents page. Scope it by words in the meeting title, because the trigger fires for every meeting the connected user attends and an empty scope pulls in one-to-ones and interviews alongside the customer calls. Fellow writes the AI notes before the transcript is ready. A note whose transcript has not landed is not captured: the attempt is recorded as **Failed** and retried a few times, rather than staging a title with nothing under it. A transcript slower than that stays as a failed row, which is the visible outcome and the one you can act on. Meetings recorded before you switched the workflow on are not backfilled. ## A worked example Switch the workflow on with `discovery`, `customer` and `renewal` as its title terms, so the calls that matter arrive on their own. Then build an agent triggered on **Note generated** for the judgement. It reads the note's attendees, works out which account the call belongs to, and writes the account team a summary. Point its output at a [Slack](/integrations/slack) channel and they get it while the call is still fresh. ## Limits Requires a paid Fellow plan with the Developer API enabled. Scoping is by words in the meeting title, which is what the event carries, so a customer call named after the customer alone will not match a term like "discovery". Read-only, so Squad can't tick off action items or edit a note. # GitHub Source: https://docs.meetsquad.ai/integrations/github Turn issues into signals, read a repository into your knowledge base and keep it current, and run an agent when an issue opens or a pull request merges. Your customers file issues and your product is already written down, in code. Squad reads new issues as feedback on their own, reads a repository into your knowledge base so it knows what you have built, and an [agent](/agents) can start when an issue opens or a pull request merges, read either one, and write back an issue or a comment. GitHub integration settings GitHub integration settings ## Connect GitHub connects through a GitHub App install, not an OAuth consent screen. Click **Connect** on the GitHub card. GitHub's **install app** screen opens. That screen asks which account or organisation to install Squad on, and which repositories it may access (all of them, or a list you choose). That repository choice is the whole of Squad's access. To change it later, manage the Squad installation in your GitHub settings rather than reconnecting in Squad. ## Disconnect Click **Manage** on the GitHub card, scroll to **Danger Zone** at the bottom of the page, and click **Disconnect**. Triggers stop, agents lose the GitHub tools, and the card drops out of **Connected** back into **Discover**. Disconnecting also uninstalls the Squad app from your GitHub account. The installation disappears from your GitHub settings and Squad's access to those repositories ends immediately. Connecting again means going through the install screen and the repository choice from scratch. The reverse direction works too. Uninstalling the Squad app from GitHub disconnects the integration here, with the same drop back into **Discover**, a plain **Connect** button and no other warning. Click it to install again. If **Connect** fails with an error before GitHub's install screen opens, Squad's own GitHub credentials are misconfigured. Contact support. ## Getting issues into your feedback Switch on the **GitHub issues** [workflow](/workflows) from the **By Squad** tab on the Agents page. An issue in the repositories you scope it to is captured with its comment thread, turned into [signals](/signals), and logged whether it captured, skipped or failed. No agent is involved. Capture happens when an issue is opened and when it is reopened. So a three-year-old issue joins the moment someone reopens it, comment thread and all. Comments alone do not bring one in. Leave the repository list empty for every repository the install covers. Bot-authored issues are always skipped, because Dependabot and Renovate open issues continuously and none of them is a person reporting a problem. An empty repository list covers every repository the install can see, private ones included. GitHub's install screen offers **All repositories**, which also picks up any repository created later, so check what the install covers before leaving the scope empty. Pull requests bring in nothing. They are things an agent reads and writes on demand. ## Reading a repository into your knowledge base Switch on the **Repo scan** [workflow](/workflows) and pick one repository. Squad reads it and writes up what the product does, as [knowledge documents](/knowledge-documents) filed alongside everything else you know: a document per capability, plus a product overview, a glossary and what the product integrates with. The documents are written in product language rather than engineering language. Squad records which file and commit each part was written from, which is what lets it spot the parts a later change has made wrong. It scans once, when you install it. One repository per scan, so a workspace with three repositories runs three, each named and paused on its own. After that it keeps up. When a pull request merges into the repository's default branch, Squad compares what changed against the files your documents were written from and flags the parts that are now suspect. Rewriting them happens overnight, or now if you click **Refresh**. Only the flagged parts are touched, so a merge that changed nothing any document cited costs nothing and lands in the history as a skip. The workflow page carries a **Freshness** row. It reads **Up to date**, or names how many documents may be out of date, and **Refresh** appears in the header when there is something to do. Rename the repository on GitHub and none of this breaks. Freshness is tracked by GitHub's own repository id rather than by `owner/repo`, so the scan follows the rename instead of reporting everything as current from then on. Delete one of those files and the next refresh clears the citation rather than leaving it flagged. Your paragraph stays. The document stops being counted as out of date, instead of sitting there asking for work nobody can do. A merge into a branch other than the default one leaves the documents alone, because code that has not shipped should not change what the documents say your product does. The **Pull request merged** trigger is a separate thing and fires on merges into any branch, so an agent watching a release branch still runs. This is the thing to switch on before drafting a [brief](/briefs). A brief that recommends building something you already ship is the expensive mistake here, and it happens when the only thing Squad knows about your product is what customers complain about. Generated code, vendored dependencies, build output, lockfiles and test trees are skipped. A repository that is entirely generated has nothing to scan and the workflow says so rather than inventing a product from it. ## Triggers * **Issue opened.** An issue is opened in an installed repository. * **Pull request merged.** A pull request is merged in an installed repository, into any branch. A merge into a release branch or a feature branch starts an agent just as a merge into `main` does. Both fire across every repository in the installation. Closed issues, opened pull requests and review comments are not triggers. ## Tools | Tool | What it does | | - | - | | **Get issue** | Takes a reference in the form `owner/repo#number` and returns the number, title, state, body, author and URL. | | **Get pull request** | Takes a reference in the form `owner/repo#number` and returns the number, title, state, body and URL. | In a triggered run each one defaults to the issue or pull request that started the run. Neither brings an issue into your feedback. That is the [GitHub issues workflow](/workflows), which captures every issue in scope whether or not an agent asks for it. | Tool | What it does | | - | - | | **Create issue** | Opens a real issue in a repository you name as `owner/repo`, with a title and an optional markdown body. | | **Comment on issue/PR** | Posts a markdown comment on an issue or pull request, defaulting to whichever one triggered the run. | Both act on your repositories. Each connection is set to **None**, **Read only** or **Read & write**, and a triggered agent needs **Read & write** to use these two. Chat is the exception, since it gets write access to every connected integration. ## A worked example Build an agent triggered on **Issue opened**. It reads the issue, checks the description against recent [signals](/signals) to see whether customers have hit the same thing, and comments with how many customers, how recently, and which insight it belongs to. Engineering gets the demand context on the issue itself, before anyone picks it up. ## Limits Squad reads issues, pull requests, and repository files during a scan or a refresh. Agents read issues and pull requests only: there is no tool that reads code on demand, so what Squad knows about your codebase is what the last scan or refresh wrote down. The two triggers are the only GitHub events available to an agent. Repository access is set in the GitHub install, not in Squad. The issues workflow starts from the moment you switch it on and nothing before that is backfilled in bulk. An older issue still comes in when someone reopens it. Discussions and releases have no workflow. A repo scan corrects what changed. It does not notice what is new. Staleness is worked out from the files your documents were already written from, so a capability added in a package that did not exist when the scan ran has nothing pointing at it and no merge will flag it. Use **Scan the whole repository again**, in the workflow's overflow menu, after a release that added a substantial new area. That one asks you to confirm before it starts, because a full re-read costs what the first scan cost and the page looks identical while it works. While a scan or a refresh is running, both actions are disabled, so a second click cannot queue a second run. # Gong Source: https://docs.meetsquad.ai/integrations/gong Turn recorded calls into signals, automatically, the moment Gong finishes one. Customers say things on sales calls they never put in a ticket. Connect Gong, switch on the **Gong calls** [workflow](/workflows), and every call your Gong rule matches arrives as [signals](/signals) with the transcript attached as evidence. No agent, no prompt, no decision about whether to fetch it. Gong integration settings Gong integration settings ## Connect Gong takes two steps, and the first one on its own does nothing. Click **Connect** on the Gong card and approve Squad in Gong. Squad asks for read access to calls and transcripts. The connection now sits at **Setup required** in amber, with a **Finish setup** button on the card. The detail page has a webhook URL. Use the copy button beside it, and paste it into your Gong automation rule unchanged. The path has to match exactly, and a rule pointing anywhere else delivers nothing at all rather than failing visibly. Set the authentication method to **Signed-JWT**. Gong also offers "URL includes key", which sends no signature, and Squad rejects any delivery that arrives without one. Gong shows a public key when you save the rule. Paste it into **Verification public key** in Squad and save. The status flips to **Connected** once the key is stored. Then switch on the **Gong calls** workflow from the **By Squad** tab under Agents. Connecting Gong on its own brings nothing in. ## Bringing calls in The **Gong calls** workflow asks for a name and nothing else. Every other workflow has a scope picker; this one has no use for one, because the scope already lives in your Gong automation rule. That rule decides which calls are ever sent (a team, a call type, a deal stage), and Squad takes what arrives. Each call is fetched with its speaker names and formatted as a labelled transcript, so extraction reads dialogue rather than a wall of unattributed text. What a customer said on the call becomes signals linked back to that call, and the workflow's history lists every call it took with a link into Gong. Two kinds of delivery are dropped and never reach your workspace. Test payloads from Gong's rule editor are acknowledged and ignored. Private calls are skipped, whether Gong marks the payload private or the call's own metadata does. Both are checked twice. Gong sends its webhook when the recording lands, which is sometimes before transcription has finished. A call that arrives without a transcript yet is retried rather than dropped, so it lands once Gong has the words. If it never does, the attempt shows as **Failed** on the workflow's history instead of vanishing. Squad holds itself to three Gong API requests a minute per connection, which is Gong's own limit. A busy afternoon queues rather than losing calls, so a run of back-to-back calls arrives a little behind rather than partly. ## Triggers One trigger, **Call recorded**, available to [agents](/agents) you build. It fires for every call your Gong rule matches. An agent on this trigger is told a call was recorded and given its ID. It cannot read the call. Gong contributes no agent tools, and the transcript reaches your workspace through the workflow rather than through anything the agent can call. Use the trigger to act on the fact of a call. Use the workflow to get what was said. ## Tools Gong contributes no agent tools, read or write. Squad reads calls through the workflow and never writes to Gong. ## Nothing is arriving Every way this fails is quiet, because a delivery Squad never receives leaves nothing behind to look at. Three things to check, in this order. **Is the workflow switched on?** Connecting Gong does not ingest anything by itself. Look for **Gong calls** in the Agents list. If it isn't there, nothing you do in Gong will help. **Does the rule's URL match the one on the Gong detail page?** Character for character. Copy it again with the button and paste it over what the rule has. A rule pointing at a path Squad doesn't serve gets an error back from a page Gong never shows you. **Is the rule's authentication method Signed-JWT?** On "URL includes key" the delivery arrives with no signature and Squad refuses it, which looks identical to nothing arriving. Once a call has come through, the workflow's history is the better place to look. A row there means the delivery reached Squad, and it tells you what happened next. ## Limits Your Gong rule sets the scope of what Squad sees, and there is no per-call filter inside Squad. Private calls never come through. Switching the workflow on does not backfill: calls recorded before that moment stay in Gong. Disconnecting in Squad doesn't turn off the rule in Gong, so disable it in the Gong admin as well. Replacing the verification key means re-copying it from Gong. Use **Replace key** on the detail page. # Jira Service Management Source: https://docs.meetsquad.ai/integrations/jira Turn customer requests into signals on their own, and reply to them from an agent flow. Jira Service Management is where your customers' problems arrive in their own words. Connect it and every new service desk request becomes [signals](/signals) on its own, while an [agent](/agents) can start when a request lands and reply to the customer in their own ticket. One workflow, four triggers, five read tools and two write tools. Jira Service Management integration settings Jira Service Management integration settings ## Connect Your site needs at least one service desk before you connect. Without one, connecting fails and tells you to create one first. Click **Connect** and approve Squad on Atlassian's consent screen. Squad resolves your Atlassian site, registers a webhook, and returns you to the detail page. It starts scoped to every service desk project on that site. If the grant covers more than one Atlassian site, pick one under **Select Atlassian site**. Tick the projects you want under **Choose spaces to monitor**, then **Save Selection**. Squad re-registers the webhook against exactly those, and needs at least one. Atlassian expires these webhooks after 30 days. Squad extends them as expiry approaches and deletes them when you disconnect. If every space you picked becomes unreachable, the connection shows **Setup required**. After three failed maintenance runs it shows **Disconnected**. Either way, reopen settings and save a valid selection. ## Triggers Four, all fed by that webhook: * **Request created.** A new customer request arrives. * **Comment added.** Someone comments on a request. * **Request updated.** A request changes (status, priority, assignee, fields). * **Request resolved.** A request's status moves to done. The spaces list badges each project **Service Desk** or **Jira Software**. You can monitor either, and these four fire for both. ## Tools | Tool | What it does | | - | - | | **Get request** | The full request. Defaults to the one that triggered the run. | | **Get request comments** | The comment thread, defaulting to the triggering request. | | **Search requests** | Recent requests, optionally scoped to one service desk. | | **List service desks** | The service desks (projects) on your site. | | **List request types** | The request types for a service desk, needed before creating a request. | None of these bring a request into your feedback. That is the [Jira requests workflow](/workflows), which captures every new request whether or not an agent asks for it. | Tool | What it does | | - | - | | **Create request** | Opens a real customer request in your service desk. | | **Comment on request** | Posts a comment on a request. It defaults to a public reply, which your customer sees. | Creating a request needs a service desk ID and a request type ID, which the two list tools provide. Set a comment to an internal note and only your agents see it. Both change your Jira instance. Each connection is set to **None**, **Read only** or **Read & write**, and a triggered agent needs **Read & write** to use these two. Chat is the exception. It gets write access to every connected integration, so you can post a public customer reply from chat without granting an agent anything. ## Getting requests into your feedback Switch on the **Jira requests** [workflow](/workflows) from the **By Squad** tab on the Agents page. Every new request in the service desks you scope it to is captured with its comment thread, turned into signals, and logged whether it captured, skipped or failed. Service desks only. The workflow reads through the Service Management API, so it offers your service desks and not the Jira Software projects the connection may also monitor. Requests raised before you switched the workflow on are not backfilled. ## A worked example Switch on the workflow so the requests arrive, then build an agent triggered on **Request created** for the part that needs judgement. It reads the request and its comments, checks them against your open [goals](/goals), and posts an internal note naming the theme when it matches something you are already tracking. When it doesn't, it leaves the request alone. ## Limits The tools read and write Service Management requests only, even on a Jira Software project you monitor. One Atlassian site per connection. Squad starts on the first site in your grant and you can switch in settings, though switching clears your space selection. Public replies go to the customer, so hand out **Read & write** carefully. # Linear Source: https://docs.meetsquad.ai/integrations/linear Mention Squad on an issue for the customer evidence, ask it for a PRD, assign one to have it written up, and start agents when issues change. Squad works inside Linear four ways. Mention it on an issue and it answers with the customer evidence behind the work. Ask it for a PRD and it writes one. Assign it an issue and it writes that evidence into the ticket. Link a brief or an action to an issue and Squad tracks where that work has got to. Separately, an [agent](/agents) you build can react to issue activity, read what your team is shipping, and file issues off the back of what it finds. Linear integration settings Linear integration settings ## Connect Click **Connect** on the Linear card and approve Squad in Linear. A Linear workspace admin has to do this, and the approval includes permission for Squad to be mentioned and assigned. You come back to the detail page as **Connected**. Squad records which Linear organisation the connection belongs to, so incoming events reach the right workspace, and Squad appears under **Agents** when you type `@` in a Linear comment. ## Mention Squad on an issue Type `@Squad` in a comment and ask. Squad reads the issue, searches your signals, insights and goals, and answers in the thread. It shows each step as it works, so you can see which tools ran and what they returned rather than watching a spinner. Questions it is built for: * What evidence do we have for this? * Who is asking for this? * Which goal does this serve? * Has anyone raised this before? Reply in the same thread to follow up. Squad remembers the conversation, so "which accounts?" works after "who is asking for this?" without repeating yourself. Signals are cited by their display id and linked, so you can open any claim and check it. If Squad has no evidence on a topic, it says so and says what would help. It will not pad an answer to look useful, because a confident wrong answer on a roadmap call is worse than an admitted gap. To stop it, type `stop`, `leave it` or `never mind`. It steps back straight away. Answering a question changes nothing, in Linear or in Squad. The two exceptions are deliberate and you have to ask for them: a PRD, covered next, and assigning the issue. Filing issues and posting comments are the agent tools below, which you turn on per connection. ### Where it works Linear allows agents on **issues and comments** only. Mentioning Squad on a project, a document or an initiative does nothing, because those surfaces are reserved for Linear's own agent. ## Ask for a PRD Say `@Squad write a PRD for this` and it goes looking for the signals behind the issue, then drafts a [brief](/briefs) from them. You get the link back in the same thread, and the issue picks up an attachment row pointing at it. Drafting takes a couple of minutes. The session stays open while it runs and tells you when it lands, so you don't have to go and check. What comes back is a draft in Squad, with a display id like `BR-12`. Edit it there. On the Linear issue nothing changes except the attachment row: no rewritten description, no status move, no comment. **It won't write a PRD it cannot support.** A brief has to cite real signals, so if nothing in your evidence backs this issue, Squad says what it searched and what would let it write the thing. That reads as a question rather than an answer, and the session waits for you. Replying with more context, or pointing it at an account or a theme, is usually enough. If a draft fails or runs long, Squad says so and links you to it. The document is in Squad either way, and you can retry it from there. ## Assign an issue to Squad Assigning is a handover rather than a question. Squad moves the issue to your team's first in-progress state, gathers the evidence, and writes it into the description: the problem in the customer's terms, who is asking, the strongest quotes, and the open questions a builder would need answered. You stay the owner. Linear records Squad as the delegate, so the issue still shows as yours. **Your text is never overwritten.** Squad appends under a `Context from Squad` heading, below whatever you wrote. Assign the same issue again and it replaces its own section, not yours. The strongest evidence is attached to the issue as links, the way a Slack or Notion link appears. Signals or insights, at most five so the issue stays readable, and every other citation stays inline in the text. It writes only what it can support. If the evidence is thin it says so, and if Squad holds nothing relevant it writes that rather than padding the ticket with plausible fiction. It won't propose a solution, a design or an estimate: it establishes why the work matters, not how to do it. ## Link work to an issue The three above all start in Linear. This one starts in Squad, and it's how a brief or an action gets tied to the ticket that delivers it. Open a [brief](/briefs) or an [action](/actions) and find the **Linear** row in the **Info** panel. Click **Link**, then either paste an issue URL or an identifier like `ENG-123`, or search your Linear issues and pick one. Squad checks the issue exists before it saves anything, so a typo tells you so instead of leaving a link pointing nowhere. Once linked, the row shows a pill: the identifier, the state Linear last reported, and a click straight through to the issue. The pill carries its own remove button when you want to unlink. An issue can only be linked to one Squad brief or action at a time. Try to link one that's already taken and Squad names it and tells you to unlink it there first. The state on the badge is what Linear last told us, not a live read. It updates when Linear sends an event, so a status changed seconds ago may not have arrived yet. Click through to the issue when the exact state matters. ## Push a brief into Linear The other direction from linking. Open a brief, choose **Push to Linear** from the `⋯` menu, pick a team, and Squad creates an issue carrying the brief, plus a sub-issue for each action the brief produced. Every issue gets an attachment row pointing back at Squad, and the Linear row on the brief fills in with what was created. Pick the team once. Squad remembers it for the next push. The brief's citations survive the trip. `SI-` links are rewritten to full URLs on the way out, so they open in Squad rather than dying on a Linear page. **Pushing twice is refused, not merged.** If a brief already has issues in Linear, Squad says so and names them. Unlink it first if you want a fresh set. Updating the existing issues in place would overwrite whatever your team has done to them since. Issues Squad creates do not fire the **Issue created** trigger. The loop guard drops events Squad itself authored, which is what stops an agent reacting to its own work. An agent watching for new issues will not see a push. ## When a Linear issue is done Move a linked issue to a done state and the Squad action closes on its own. In progress starts it, cancelled dismisses it, and moving it backwards reopens it. Squad reads Linear's state *type* rather than the column name, so renaming "Done" to "Shipped" changes nothing. Triage, backlog and todo deliberately map to nothing: they all mean "not being worked on", which is not a Squad status, and guessing would move work you never touched. Sync runs one way. Linear owns whether the work is delivered, so completing an action in Squad does not close the Linear issue, and a status Squad shows can be overwritten the next time Linear reports something different. ## What it brings in Nothing from Linear becomes a signal. There's no capture step for issues or comments, and Linear content never enters the evidence pipeline. Beyond mentions, triggers and tools are the surface. An agent sees an issue only when it asks for one with a tool. ## Triggers * **Issue created.** A new issue lands. * **Issue updated.** An issue changes (status, assignee, content). * **Comment added.** Someone comments on an issue. All three fire for the whole connected Linear organisation. There's no per-team scoping, so filter in the agent's own instructions if you only care about one team. ## Tools | Tool | What it does | | - | - | | **List issues** | Returns recent issues, most recently updated first, up to 50. | | **Get issue** | Takes an ID or an identifier like `ENG-123`. | | **Get comment** | Reads a single comment and defaults to the comment that triggered the run. | | **List teams** | Returns each team's ID, name and key, which you need before creating anything. | | Tool | What it does | | - | - | | **Create issue** | Files a real issue in one of your Linear teams. | | **Comment on issue** | Posts a markdown comment on an existing issue. | Get the team ID from **List teams** first, then pass a title and an optional markdown description. Both change your tracker. Each connection is set to **None**, **Read only** or **Read & write**, and a triggered agent needs **Read & write** to use these two. Chat is the exception, since it gets write access to every connected integration. ## A worked example You want the loudest customer themes to reach engineering without a weekly copy-paste. Build an agent triggered on something upstream, a [Gong](/integrations/gong) call or a [Jira](/integrations/jira) request, and turn on Linear's write tools. When the run finds a problem worth building, it calls **List teams**, then **Create issue** in the right team with the evidence in the description. The other direction works too. An agent triggered on **Comment added** can read the comment, check what the customer originally asked for, and reply with the context engineering is missing. ## Limits Squad works on issues and comments only. A mention answers and changes nothing unless you ask for a PRD, which creates a draft in Squad and one attachment row. An assignment writes to the issue description and moves its status, and nothing else. A push creates issues and nothing more: Squad never edits an issue it pushed after the fact. A PRD needs at least one supporting signal. Squad will not write one from the ticket text alone, however detailed the ticket is. For agents you build: Linear can't be attached as a source, so an agent only sees issues it explicitly reads with a tool. Nothing from Linear becomes a signal. Issue lists cap at 50 per call. Creating an issue needs a team ID, which means one extra tool call. # Notion Source: https://docs.meetsquad.ai/integrations/notion Watch a Notion page for changes, and let an agent read the page it was triggered from. Notion is where the PRD, the research note and the decision log live. Connecting it lets an [agent](/agents) start work when one of those pages changes, and read the page while it runs. Squad never writes to Notion. Notion integration settings Notion integration settings ## Connect Click **Connect** on the Notion card. Notion's install screen opens. That screen asks which pages to share with Squad. Pick carefully, because that choice is the whole of Squad's access. Approve, and you land back on the Notion detail page as **Connected**. To share more pages later, run the connect flow again and add them. ## Triggers Notion declares one trigger, **Page updated**. It fires when a page Squad can see changes. Unlike most triggers, this one is scoped to a single page. When you add it in the agent builder, a search box lets you pick which page to watch. The agent then runs only for edits to that page, not every page Squad can see. ## Pages as sources A Notion page can also be attached to an agent as a source. Sources are read into the agent's brief on every run, so the page's current content is in front of the agent even when something else triggered it. Use this for a spec or a strategy doc the agent should always work against. Notion databases aren't available as sources. Only pages are. ## Tools | Tool | What it does | | - | - | | **Read page** | Returns a page's title and body. | With no argument it reads the page that triggered the run. Pass a page ID to read a different one. Notion has none. Squad reads pages and does nothing else to your Notion workspace. ## Signals Nothing from Notion becomes a signal, and nothing imports into [knowledge documents](/knowledge-documents). Notion content reaches Squad through the trigger, the source and the read tool, and nowhere else. ## A worked example Your team keeps a live PRD in Notion. Build an agent triggered on **Page updated**, pointed at that page. On each edit it reads the page, compares the requirements against recent [signals](/signals), and writes a short note on which parts of the spec the evidence no longer supports. That note lands in Squad, or in a Slack channel if you gave the agent [Slack](/integrations/slack) delivery. ## Limits Squad sees only the pages you shared during the install. Databases can't be watched or used as sources. There's no write path, so an agent can't append to a page or tick a checkbox. The trigger reacts to page changes. Comments and property-only edits aren't separate triggers. # PostHog Source: https://docs.meetsquad.ai/integrations/posthog Query your product analytics from an agent, and run one when PostHog forwards an event. Qualitative feedback tells you what customers say. PostHog tells you what they do. Connecting it lets an [agent](/agents) run SQL against your product analytics mid-run, so a recommendation can cite behaviour as well as quotes. PostHog integration settings PostHog integration settings ## Connect PostHog uses an API key rather than a redirect. Click **Connect** on the PostHog card. A form opens. * **Region.** US or EU, matching where your PostHog project lives. * **Project ID.** From PostHog under Settings, then Project. * **API key.** A personal API key, created in PostHog under Settings, then Personal API keys. Submit and the card turns green. One connection covers one PostHog project. ## What it brings in Nothing from PostHog becomes a signal. It's a query surface for agents, not a source of customer voice. ## Triggers One trigger, **Event captured**. It fires when PostHog forwards an event to Squad from a webhook destination you set up on your side. PostHog's destination filters decide which events get forwarded, so you define what this trigger reacts to. The PostHog detail page in Squad shows the webhook endpoint to paste into that destination, with a copy button. Filter tightly in PostHog. A destination pointed at a high-volume event will start an agent run every time it fires. The destination also has to send the shared secret header Squad checks, `x-squidge-webhook-secret`. The app shows the URL but not the secret value, so ask support for it when you configure the destination. ## Tools | Tool | What it does | | - | - | | **Run HogQL query** | Runs a SQL-style query against the connected project and returns the columns and rows, capped at the first 100 rows. | | **List insights** | Returns the saved insights (charts and dashboards) in the project, 25 by default and up to 100. | Run HogQL query does the real work. Events, trends, funnels and retention are all expressed as SQL. PostHog has none. Squad queries your analytics and never writes to them. ## A worked example You have an insight claiming customers abandon onboarding at the workspace-invite step. Ask an agent with PostHog read tools to check it. It writes a HogQL query counting how many users reach each onboarding step over the last 30 days. The rows either confirm the drop-off or show the complaint is louder than the behaviour, and that answer goes into the [brief](/briefs) as a number rather than a hunch. ## Limits Queries return the first 100 rows, so aggregate in the query rather than pulling raw events. One project per connection. The trigger fires for whatever your PostHog destination forwards, which makes filtering in PostHog the only volume control you have. # Review sources Source: https://docs.meetsquad.ai/integrations/review-sources App Store, Play Store, Google and Trustpilot reviews, imported daily as signals. No login, no triggers, no agent tools. Four providers import public reviews into Squad. **App Store Reviews**, **Play Store Reviews**, **Google Reviews** and **Trustpilot Reviews**. Reviews arrive as [signals](/signals) and feed the same pipeline as everything else. That's the whole of what they do. Review source settings Review source settings ## They can't trigger an agent None of the four declares a trigger or an agent tool. An [agent](/agents) can never be started by a new review, and no agent flow can read reviews directly. Reviews reach you through the pipeline instead. Extraction, clustering, then the insights that come out the far end. If you want an agent to react to review content, trigger it on something else and let it work from the signals the reviews produced. ## Connect There's nothing to authorise. These run on Squad's own credentials, so clicking **Connect** takes you straight to the detail page, where the header reads **Not configured** until you add your first source. Adding it is what creates the integration. What you add depends on the provider. Pick a country (the storefront), then search for your app by name. Pick a country, then search for your app by name. Pick a country, then search for your business and choose it from the Google Maps suggestions. Country controls which Google locale Squad queries. Paste your review page URL, in the form `https://www.trustpilot.com/review/yourdomain.com`. Each provider is its own card on the Integrations page with its own detail page. You can track several apps, businesses or domains per provider, and the same app in more than one country. ## What arrives, and when Squad imports your most recent reviews as soon as you add a source, then syncs daily. Each sync pulls up to 150 reviews on the Play Store and 100 on the other three. Every tracked source shows its state on the detail page. It reads **Awaiting first sync…** before the first import, then **Last synced N reviews on ``**. A source can be **Paused**, which stops the daily sync without deleting it, or **Removed** entirely. A source that hits a problem shows an **Error** badge. ## Tools None of the four review providers declares a read tool, so no agent flow can read reviews directly. None of the four declares a write tool either, so there's no reply path back to the reviewer. ## A worked example Add your iOS app for the US storefront and your Trustpilot domain. Over the next day the recent reviews land as signals and cluster with everything else you've collected. A one-star review about a broken export and a support ticket about the same export end up in the same cluster, and turn up together inside [insights](/insights). Track a competitor's app the same way if you want their reviews as evidence too. Squad treats them as ordinary signals. ## Limits No triggers and no agent tools, so reviews are evidence only. Public reviews only, with no reply path back to the reviewer. The daily sync fetches the most recent reviews rather than the full history, so a source added today won't backfill. # Slack Source: https://docs.meetsquad.ai/integrations/slack Capture feedback from Slack, read channel history from an agent, and get Squad's output posted back into a channel. Slack is where product feedback actually gets said. Squad pulls those messages in as [signals](/signals), lets an agent read a channel's recent history, and posts its own output back into Slack. It's the only provider Squad can send anything to. Slack integration settings Slack integration settings ## Connect Click **Connect** on the Slack card and approve the Squad app for your Slack workspace. You come back to the Slack detail page, which holds every setting below. Run `/invite @Squad` in each channel you want Squad to see, public or private. The bot only sees channels it has been invited to. Once it's in, the channel appears under **Capture Channels**, with a lock beside the private ones. If someone uninstalls the app or the token is revoked, the detail page shows a red **Disconnected** state with a **Reconnect** button. Capture, thread sync and notifications stay off until you use it. Squad sometimes needs a Slack permission it didn't ask for at install. Slack won't grant one to an app that's already installed, so the detail page shows an amber banner naming exactly what's missing, and anything depending on those permissions does nothing until a workspace admin clicks **Reconnect**. Reconnecting keeps your capture channels and their settings. ## Capture modes Every channel the bot can see gets a mode. No capture. The channel can still receive notifications. Capture when someone reacts with `:squad:`, `:squad-bug:`, `:squad-idea:` or `:squad-praise:`, or when someone asks the bot directly. Capture every top-level human message in the channel. In an auto channel, prefix a message with the loudspeaker emoji to keep that one message out of Squad. Two toggles sit alongside the mode and work independently of it. **Notifications** posts new insights, action proposals and signal spikes into the channel. **Thread sync** confirms back on the message it came from. ## How Squad confirms a capture Squad reacts to the message rather than replying to it. A manual capture gets a white check mark, an auto capture gets an inbox tray, and a magnifying glass follows once extraction finishes and signals exist. The whole channel can see the state of a message at a glance, and the conversation underneath it stays yours. That matters more than it sounds. A captured message's thread stays a sync target for as long as its link is enabled, so anything Squad posts there accumulates for the life of the thread. Workspaces connected before reactions were supported fall back to a single text reply instead. Reconnect the app from the Slack detail page to grant the permission and switch to reactions. ## Capture on demand Reply in a thread with `@Squad log this as feedback` and Squad captures the message you replied to, whatever the channel's mode says. Pasting a permalink works too, as in `@Squad capture this: https://…`. Asking in a channel that has never been configured counts as consent, so Squad sets it to manual mode and captures the message. Captured messages become external sources and run the same extraction as everything else, so they end up as signals with a link back to the original Slack message. ## Write it up as a brief Ask the bot in a thread to turn the discussion into a brief and it drafts one from what was said. "Write this up" or "make a PRD from this" both work. Squad replies with the brief's number and a link, and the document appears in [Briefs](/briefs) while it drafts. Squad also offers when you have not asked. If its analysis in a thread would make a strong PRD or decision brief, it posts a **Create brief** button under the reply. Click it and the button is replaced by the draft's status line. Ignore it and nothing happens. A channel thread gets one brief. Asking the bot and clicking the button produce the same draft, and so does clicking twice, so you can do both without ending up with duplicates. In a DM there are no threads, so each request drafts its own. If the thread is too short to work from, the button reports that instead of drafting. ## Triggers Slack declares no agent triggers, by design. Its own runtime handles Slack events (chat with the bot, emoji capture, mentions, thread sync), so they never reach the generic agent trigger dispatcher. A workspace whose only connected provider is Slack sees no integration trigger group in the agent builder at all. Slack still works as a source of signals, as a tool provider and as a delivery channel. It can't start an agent run. ## Tools | Tool | What it does | | - | - | | **Read channel history** | Gives an agent the recent messages from one channel. | The tool only appears for agents that have Slack channels configured as sources, and it's bound to exactly those channels. The agent chooses how far back to read on each run (a daily check reads 24 hours, a weekly digest 168), up to 90 days and 200 messages per call. The Squad bot has to be a member of the channel or the tool comes back with an error telling you to invite it. | Tool | What it does | | - | - | | **Capture message as signal** | Takes a Slack permalink, or a channel and message timestamp, and runs the same capture pipeline the emoji reactions use. | It dedupes, so calling it twice on the same message is safe. ## Delivery Agent reports render as a Slack card and get posted into a channel, optionally as a reply in a thread. The card carries the report title, the run's findings, a **Key takeaway** line, and a **View full report** button. Findings come through as a bulleted list, each one written to stand alone, so the channel gets them without anyone opening the report. Older reports have no findings list, and their card shows the summary paragraph instead. A link inside a finding or the takeaway stays clickable when it points at a page in Squad or at a full web address; anything else shows as plain text. Citations in the report body are not on the card, so open the full report for those. The takeaway is the part to read if you read nothing else. It says which finding to act on first and why, which is the question a list of findings leaves open. Notifications and thread sync use the same path. ## A worked example You run a `#customer-feedback` channel where support drops verbatim quotes. Set it to **Auto** so everything lands in Squad. Turn on **Notifications** so the channel hears about new insights, and leave **Thread sync** on so each captured message picks up an inbox tray, then a magnifying glass once its signals land. For a noisier channel like `#general`, use **Manual** instead and let people react with `:squad:` on the few messages worth keeping. Those get a white check mark. ## Limits The bot reads only channels it has been invited to, public or private. The read tool needs the channel configured as a source on the agent, not connected at the workspace level. History reads cap at 200 messages and 90 days per call, and long results get truncated. Slack can't trigger an agent. # Knowledge & documents Source: https://docs.meetsquad.ai/knowledge-documents The document library your workspace and your agents both write to. Folders, the editor, tags, source attribution, version history, and Trash. Knowledge is your workspace's document library, and the context Squad reads before it answers anything. You write in it. Agents write in it. One tree of folders and documents, and both sides can edit the same page. The Knowledge document library The Knowledge document library ## The Knowledge page Open **Knowledge** from the bottom of the sidebar. You get the whole tree, every folder and document, on one page. **Trash** in the top right opens deleted documents (see [Trash](#trash)). The other three buttons always act on the folder you're currently inside: Imports files from your computer as documents. Creates a subfolder and drops you straight into renaming it. Opens the template picker. **Search documents...** at the top filters as you type. It matches document titles and folder names, not the text inside a document. To search by meaning, ask Squad in chat ("find our docs on onboarding friction"). A brand-new workspace shows **No documents yet** and a **Create your first document** button. ### List view and card view The toggle in the toolbar switches between a compact tree (**List view**) and a grid of tiles (**Card view**). Squad remembers which one you picked. **Mark all read** sits to the left of the toggle whenever the library holds a document nobody has opened. It clears every unread mark across the workspace, not only the folder you are in, and the count on the sidebar's **Knowledge** link goes with them. A document an agent files while you are reaching for the button stays unread. In list view, clicking a folder expands it inline under its parent, and the set of expanded folders survives navigation. In card view, clicking a folder tile opens that folder in place, with a breadcrumb trail under the toolbar to step back up. Either way you stay on the Knowledge page with the same header, search box, and toggle. Card view keeps the two apart. Folders gather on their own lines at the top as filled tiles, each with the number of items it holds. Documents sit below as white cards. [Briefs](/briefs) draws its library the same way. Clicking a document opens the editor. Cmd/Ctrl-click opens it without losing your place. Documents you haven't opened yet carry a small blue dot and a bolder title, which clears when you open one or use **Mark all read**. Open a document and its breadcrumbs name the folders it sits in, each one a link back to that folder's contents on the Knowledge page. The back arrow returns you to the folder rather than the top of the library. ### Moving, selecting, and deleting Drag a document or folder onto another folder to move it. Drag onto the empty area to move it back up to the level you're viewing. Squad blocks moves that would put a folder inside itself. Shift-click to select a range. The toolbar then shows **Delete 4** (or whatever the count is), and a confirmation dialog appears before anything goes. Selecting a folder selects everything inside it. Deleted documents go to Trash. Deleted folders are gone, and the documents inside them go to Trash. Right-click any item for its menu. On a folder you get **New Document**, **New Folder**, **Upload file**, **Rename**, **Tags**, **Delete**. On a document you get **Open**, **Copy as Markdown**, **Download as .md**, **Tags**, **Copy URL**, **Delete**. The `⋯` button on a row or card tile carries the same items, minus **Upload file**. ### Uploading files **Upload** accepts `.md`, `.txt`, `.docx`, and `.pdf`, up to 20 MB per file. You can also drag files from your desktop straight onto a folder row. Each file becomes a document in that folder. Anything unsupported is skipped with a toast telling you what was left out. Uploaded documents start with no tags. ## Creating a document **New Document** opens a picker rather than creating a blank page. **Blank document** gives you an empty page titled *Untitled*. Below that, **Templates** lists every document in the workspace tagged **Template**. Picking one copies its content into a new document named `{original title} (copy)`. There are no built-in templates. If the list is empty you'll see *No templates yet. Tag any document as a template to see it here.* Write the document you want to reuse, tag it **Template**, and it shows up in the picker. ## The editor Documents use a block editor. Type markdown and it converts as you go, or use the formatting menu. Set the title in the large field at the top (it shows *Untitled* until you fill it in) and pick an icon next to it from the Lucide icon set, searchable from the picker. There is no save button. Edits save about a second after you stop typing. Type `@` anywhere in the body to link to another document, folder, goal, insight, or signal by name. Two people (or a person and an agent) editing the same document at the same time will overwrite each other. When someone else saves, your view reloads with their version and any uncommitted typing of yours is lost. Version history keeps the earlier states, but avoid co-editing a page live. ### The side panel The right-hand panel shows **Info** (**Created**, **Updated**, and editable **Tags**), then **Referenced by**, which lists the briefs and other entities that link to this document. Below that are four buttons: Hands the document to Squad in chat. Opens the document's version history. Puts the whole document on your clipboard. Saves it as a file. A badge at the bottom shows whether you, an agent, or the system last touched the page. ### Review knowledge **Review knowledge** takes a version snapshot, opens the chat, and asks Squad to improve the document in place. It reads the page, reads related workspace documents for context, researches the web, then rewrites to your intent with better structure, fresh data, filled gaps and citations. The edits arrive in the open editor as it works. The snapshot comes first, so you can undo the whole rewrite from **View history**. ## Tags Six fixed tags. **Product**, **Competitor**, **Feedback**, **Market**, **Research**, **Template**. There are no free-form tags. Tags show as coloured chips in the tree and in the Info panel. Set them from the **Tags** submenu on a document's menu, or from the **Tags** row in the Info panel. **Template** is the only one with a side effect. It puts the document in the template picker. Folders can carry tags too, and folder tags flow down to every document inside. An inherited tag appears on the document with a folder icon and the note *from folder*, and you can't remove it from the document. Remove it from the folder instead. Documents you create or upload start untagged. Documents an agent creates are tagged by the agent based on what it wrote. ## Source attribution When content arrives from somewhere outside Squad (a Slack thread, a GitHub file, a page an agent fetched), Squad records where each block came from and shows it in the right-hand gutter of the editor. Blocks with a source get a coloured left border and a small source icon. Green means the block still matches what was imported. Amber means you've edited it since. Click the icon for a popover naming the source, the import date, and a link out where a link exists. What the popover shows depends on the provider. Channel and author for Slack, repository, issue number, author, and state for GitHub, project, ID, and state for Linear, page title for Notion, event name for PostHog. Where the original has a web address you get **Open in Slack**, **View on GitHub**, **Open in Linear**, or a similar link. Where it doesn't, the popover shows the details without a link. If a block has content from more than one source, the popover shows a tab per source with the count at the top. ## Version history Squad keeps earlier states of a document so you can roll one back. Open it with **View history** in the side panel, or **History** in the document's `⋯` menu. The page is titled **Version History** and has a breadcrumb back to the document. You never save a version by hand. Squad takes a snapshot at four moments: 1. When you leave a document you have been editing. 2. Before **Review knowledge** runs, so the rewrite never overwrites your only copy. 3. When an agent updates the document. 4. When you restore an older version, which snapshots the state you're moving away from. Snapshots that would be identical to the previous one are skipped, so the list has no duplicates. Versions are listed newest first, with a badge reading **You**, **Agent**, or **System**, a relative timestamp, and a version number like `v4`. Click one to expand it, check the title it had at that point, and click **Restore**. The document reverts and you land back on it. Restoring is itself recorded, so you can go forward again. The twenty most recent versions are shown, and Squad keeps up to fifty per document. A document that has never been edited and left shows *No versions yet.* ## Folders Folders nest as deep as you want. Rename them from the right-click menu, drag them to reorganise, and delete them. Deleting a folder removes it and its subfolders for good, and moves every document inside to Trash. One folder is managed for you. **Agent Reports** is where agent reports land. It appears in the tree like any other folder and you can read everything in it, but it can't be renamed, moved, or deleted. These folders hold documents. [Briefs](/briefs) keeps its own separate set, so a folder made here never shows up there. ## Trash Deleting a document moves it to Trash. That holds however it was deleted: from its menu, in a bulk delete, by deleting its folder, or by an agent. A **Moved to Trash** toast appears with **Undo**, which puts it straight back. Trash keeps a document for 30 days, then deletes it permanently along with its version history. While it's there, it doesn't show up anywhere else. It's gone from the tree, from search, from `@` mentions, from Context Health, and from what agents can read. Open **Trash** from the top right of the Knowledge page. Each row shows how long the document has left (**12 days left**). Hover it to see when it was moved to Trash. The Knowledge Trash page The Knowledge Trash page Puts the document back where it was, with its content, tags, sources, links, and version history intact. Deletes one document permanently, after a confirmation. Deletes everything in Trash permanently, after a confirmation. If the document's folder was deleted in the meantime, **Restore** puts it at the top level of Knowledge. A link to a deleted document still opens it, read-only. The header marks it **In Trash**, says how long it has left, and has a **Restore** button. ## What happens after you write Saving a document queues it for re-embedding, which makes it findable by meaning in chat and links it to related entities. It can also fire agent triggers. An agent set to run when knowledge is created or updated picks the document up from there. See [Agents](/agents) and [Tools and access](/agent-tools-access). Content from your connected tools arrives through [Integrations](/integrations), and agents that read web pages write what they find here too. ## Cookbook Write it once, tag it **Template**, then start every future copy from **New Document** and pick it out of the **Templates** list. Switch to **List view**, drag documents onto folders, and use **New Folder** for anything missing. Tag the folder rather than the documents inside it; the tag flows down. Click **Undo** on the toast if it's still showing. Otherwise open **Trash** from the Knowledge page and click **Restore** on the row. You have 30 days. Open **View history**, find the version with the **You** badge from just before the agent ran, expand it, and click **Restore**. In a document written from a connected tool, click the icon in the right gutter next to the paragraph you're questioning. The popover names the source and links to the original where one exists. An amber border means someone has edited that block since it was imported. Open it and click **Review knowledge**. Squad snapshots it, researches, and rewrites with citations. Compare against the snapshot in **View history** and restore if you prefer what you had. Agents file reports overnight and every one of them lands unread. If you would rather triage from the sidebar than from a badge, open **Knowledge** and click **Mark all read**. The documents stay where they are; only the blue dots go. Open the folder it belongs in, click **Upload**, and pick the `.md`, `.txt`, `.docx`, or `.pdf`. Tag it afterwards so Squad knows what kind of document it is. # Squad MCP server Source: https://docs.meetsquad.ai/mcp/overview Connect Claude, ChatGPT or any MCP client to Squad over OAuth and work signals, insights, actions and briefs from your assistant. Squad MCP Squad MCP Squad runs a hosted MCP server. Point a client at it, authenticate once in your browser, and your assistant can read the evidence behind a decision, capture new feedback and generate decision briefs without leaving the conversation. ## Connect ``` https://mcp.meetsquad.ai/mcp ``` Streamable HTTP transport. Nothing to install, nothing to self-host. ```bash theme={null} claude mcp add --transport http squad https://mcp.meetsquad.ai/mcp ``` Other clients take the URL directly. The server publishes `.well-known/oauth-protected-resource` metadata naming its authorization server, so most clients need nothing else. The first tool call triggers an OAuth flow in your browser. Log in with the account you use for Squad, approve the request, and the client stores the resulting token. Later sessions reuse it. Four scopes are requested. `read:workspace`, `write:workspace`, `openid` and `email`. Tools run against one workspace. If your account can reach exactly one, the server selects it on the first call and remembers it. If you can reach more than one, the first call comes back listing your organisations and workspaces. Your assistant then calls `select_workspace` with the IDs. ## Read scope and write scope Read tools need `read:workspace`. Write tools need `write:workspace`. The scope check happens when a tool is called, not when tools are listed. A read-scoped session still sees every write tool in `tools/list`. The call then fails with a message saying the token does not include `write:workspace` and to reconnect with write access. Retrying won't get you anywhere. Reconnect with write scope. Which tools are which is on [Tools](/mcp/tools). ## Switching workspace Switch at any time by asking for another workspace by name. The assistant calls `list_workspaces`, then `select_workspace`. If your access to the selected workspace is revoked, the next call clears the selection and asks you to choose again. ## Version compatibility The hosted server is version 4 and targets the current Squad platform, the one behind [app.meetsquad.ai](https://app.meetsquad.ai). Version 3 targets the previous Squad product and speaks a different API. `https://mcp.meetsquad.ai/mcp` always reaches the current version, so there is nothing to pin. ## Prompts Four ready-made workflows come with the server. Most clients surface them as slash commands or a prompt picker. | Prompt | What it runs | | - | - | | `triage-feedback` | Checks for duplicates, ingests a piece of feedback, reports where it landed | | `weekly-product-review` | What changed, what the evidence says, what needs deciding | | `draft-decision-brief` | Generates a brief from an action or insight and walks it to a readable draft | | `ground-this-ticket` | For coding agents: pulls the customer evidence behind a piece of work before building it | ## Resources Two resources hold workspace context so strategy questions cost no tool calls. Pin them in clients that support resources. | URI | Contents | | - | - | | `squad://workspace/context` | The current workspace's mission and product context | | `squad://goals` | Strategic goals with importance rankings | ## Display IDs Squad entities carry short IDs so your assistant can cite its evidence. `SI-` signal, `IN-` insight, `AC-` action, `GL-` goal, `BR-` brief, `DC-` document, `CL-` cluster. Ask for `IN-42` and you get insight 42. ## Where to go next All thirty tools, their parameters, and the scope each one needs. The same capabilities in a shell. # Tool catalogue Source: https://docs.meetsquad.ai/mcp/tools All thirty Squad MCP tools, grouped by area, with their parameters and the scope each one needs. Thirty tools, seventeen read and thirteen write. Read tools need the `read:workspace` scope, write tools need `write:workspace`. Setup is on [Squad MCP server](/mcp/overview). Every tool below is listed to every session regardless of scope, so seeing a write tool doesn't mean you can call it. A read-scoped session gets an error on invocation telling it to reconnect with write access. ## Conventions List tools take `limit` (default 25, maximum 100) and `cursor`. When more results exist, the response carries a `nextCursor` to pass back on the following call. Anywhere a tool takes an entity ID, both the display ID (`AC-12`) and the UUID work. ## The catalogue | Tool | Scope | What it does | | - | - | - | | `list_workspaces` | read | Every organisation and workspace you can access, with the current selection marked | | `select_workspace` | write | Sets which organisation and workspace later tools operate on | | `get_workspace_overview` | read | Mission, top goals, seven-day signal activity, chain health, open work counts | | `update_workspace` | write | Edits name, description, mission statement or logo | | `list_members` | read | People in the organisation with their user IDs | `select_workspace` takes `orgId` and `workspaceId`, both from `list_workspaces`. `update_workspace` takes any of `name`, `description`, `missionStatement`, `logoUrl`. `get_workspace_overview` is the orientation call. Run it first in a new session. Use `list_members` to resolve a person to the user ID that `update_action` wants for `assignee`. | Tool | Scope | What it does | | - | - | - | | `search` | read | Keyword search across signals, insights, actions, goals, documents and clusters | | `get_entity` | read | Fetch any entity by display ID or UUID | `search` takes `query` (required), `types` (any of `signal`, `insight`, `action`, `goal`, `document`, `cluster`) and `limit`. Matching is on title and content, so it wants real keywords rather than a question. `get_entity` takes `id` and an optional `include` array. Insights accept `include: ["evidence"]`, which returns the supporting signals with their source links, capped at ten. Documents come back as markdown. It also polls asynchronous work such as brief generation. Signals, clusters and insights. See [Signals](/signals) and [Signal clusters](/signal-clusters). | Tool | Scope | What it does | | - | - | - | | `list_signals` | read | Browse raw feedback with filters | | `find_similar_signals` | read | Semantically related signals for a given one | | `list_clusters` | read | Clusters with sizes and labels | | `get_cluster` | read | A cluster's stats, member signals and linked insights | | `list_insights` | read | Insights ranked by combined score | `list_signals` takes `source`, `signalType`, `sentiment` (`positive`, `neutral`, `negative`, `mixed`), `clusterId`, `since`, `until`, `includeDismissed`. Dismissed signals are excluded by default. Rows are summaries, so follow up with `get_entity` for full content. `find_similar_signals` takes `signalId` and `limit` (default 5, maximum 20). Use it before ingesting something that might already be known. `list_clusters` takes `signalType` and `includeUnlabeled`. `get_cluster` takes `clusterId` and caps member signals at fifteen. `list_insights` takes `goalId` to scope to one goal, plus `category` (`pain_point`, `feature_request`, `positive_signal`, `trend`, `risk`), `minScore` and `status` (`active`, `stale`, `archived`, `resolved`). See [Actions](/actions). | Tool | Scope | What it does | | - | - | - | | `list_actions` | read | Ranked actions, filtered | | `get_action_context` | read | The action, its insight, the evidence and the goals it serves | | `update_action_status` | write | Moves an action through its lifecycle | | `update_action` | write | Edits metadata, assigns, or links an action | `list_actions` takes `statuses` (`suggested`, `in_progress`, `completed`, `dismissed`), `assignee` (a user ID or `me`), `insightId`, `priority` (`P0`, `P1`, `P2`) and `includeSnoozed`. It defaults to open work, meaning suggested and in progress, with snoozed excluded. `get_action_context` takes `id` and returns everything needed to execute the action in one call, including the top eight customer quotes with source links. Call it before implementing or deciding. `update_action_status` takes `actionId`, `status` (`start`, `complete`, `dismiss`, `snooze`) and an optional `note` that gets appended to the action's notes. It is annotated destructive because the transition changes state others can see. `update_action` takes `actionId` plus any of `priority`, `effort` (`low`, `medium`, `high`), `category` (`comms`, `operational`, `product`, `strategic`, `workspace`), `notes`, `assignee` (a user ID, `me`, or null to unassign), `linkInsightId`, `linkBriefId`. Its `notes` replaces the whole field. To append, use `update_action_status`. See [Goals](/goals) and [Activity](/activity). | Tool | Scope | What it does | | - | - | - | | `list_goals` | read | Goals ordered by importance | | `get_activity` | read | The workspace change feed, newest first | | `create_goal` | write | Creates a strategic goal | | `update_goal` | write | Edits title, description or importance | | `update_insight` | write | Sets category or status, links or unlinks a goal | | `dismiss_signal` | write | Permanently removes a signal | `list_goals` takes `minImportance`. `create_goal` takes `title`, `description` and `importance` (1 to 5, default 3). `update_goal` takes `goalId` plus the fields to change and keeps a version snapshot. `get_activity` takes `entityTypes`, `actorType` (`human` or `agent`) and `agentId`, so you can separate what Squad's agents did from what people did. `update_insight` takes `insightId` plus `category`, `status`, `linkGoalId`, `unlinkGoalId`. Insight titles and descriptions come from the pipeline and cannot be edited. `dismiss_signal` deletes the signal. It cannot be recovered. It takes `signalId` and an optional `reason`, which is echoed back in the response rather than stored on the record. See [Knowledge documents](/knowledge-documents). | Tool | Scope | What it does | | - | - | - | | `list_documents` | read | Documents and briefs with paths and tags | | `create_document` | write | Creates a document from markdown | | `update_document` | write | Replaces body or title, manages tags | `list_documents` takes `tag` and paginates. The tag filter applies to the current page, so page through for full coverage. `create_document` takes `title`, `markdown`, and optional `directoryId` and `tags`. A near-identical title returns the existing document instead of creating a duplicate. Do not open the markdown with the title as a heading, since the title renders separately. `update_document` takes `documentId` plus `markdown` (replaces the whole body), `title`, `addTags`, `removeTags`. A version snapshot keeps the previous content recoverable in the app. See [Briefs](/briefs). | Tool | Scope | What it does | | - | - | - | | `list_briefs` | read | Briefs with status and recommendation | | `generate_brief` | write | Starts AI generation of a brief | | `update_brief_status` | write | Moves a brief through review | `list_briefs` takes `status` (`building`, `draft`, `in_review`, `finalised`, `failed`), `type` (`decision` or `prd`) and `sourceInsightId`. `generate_brief` takes exactly one of `actionId`, `insightId` or `retryBriefId`, plus an optional `type`. Generation runs asynchronously, so poll the returned `BR-` ID with `get_entity` until its status moves past `building`. `update_brief_status` takes `briefId` and `status` (`draft`, `in_review`, `finalised`). The `building` and `failed` states belong to generation and cannot be set here. | Tool | Scope | What it does | | - | - | - | | `ingest_signal` | write | Captures feedback into the evidence chain | `ingest_signal` takes a `signals` array of 1 to 50 items. Each item takes `content` (required), plus `source`, `title`, `sourceUrl`, `author`, `occurredAt` and `strength` (0 to 1, default 0.5). Content is deduplicated semantically on the server, then clustered and distilled asynchronously, so check back with `get_activity` or `list_signals` shortly after. For one-off items, run `find_similar_signals` or `search` first to see whether the theme is already known. | Tool | Scope | What it does | | - | - | - | | `list_integrations` | read | Connected feedback sources and their sync health | Returns each source's provider, status, most recent sync time and total signals pulled. Use it to explain a coverage gap before blaming the pipeline. Connect sources in the app. See [Integrations](/integrations). # Notifications Source: https://docs.meetsquad.ai/notifications The switches that decide what Squad tells you, and the sidebar inbox where it lands. Notifications have two separate surfaces, and they're easy to confuse. What Squad tells you about. They live on the **Notifications** tab of Settings. Where those notifications land. A popover on the sidebar, opened from **Inbox** under the bell icon. The inbox is a popover, not a page. It has no route of its own, so there's no URL you can bookmark or share for it. The notification inbox and settings The notification inbox and settings ## Choosing what you hear about Open **Settings** in the sidebar and pick the **Notifications** tab. Every topic Squad can notify you about is listed there, each with its own description. Each row carries two switches: **In-app** and **Email**. Some topics offer both, some only one, and a row shows only the switches its topic actually supports. Turning both off unsubscribes you from that topic. Email sending is not switched on yet, so **Email** records your preference and no mail arrives. Leave **In-app** on for anything you need to see. Toggle a switch and it applies immediately. There's no save button and no confirmation toast. If a change fails it snaps back and tells you why. Your choices are yours alone, so muting a topic doesn't affect anyone else on the team. They're also per workspace, which lets you follow one workspace closely and stay quiet on another. Open a second tab and a change made in one appears in the other without a reload. ## The inbox **Inbox** sits near the top of the sidebar with a bell icon. A number appears on it when you have unread notifications, and reads `9+` past nine. Click it and the inbox opens beside the sidebar. The list is flat, newest first. Unread rows are tinted, bold, and carry a small dot on the right. Ten load at a time, with **Load more** at the bottom when there are more. **Mark all read** appears in the header while anything is unread. It clears everything unread, not just what's on screen, and stops at the newest item you've actually seen, so something arriving mid-click stays unread. The count on the bell is the real number waiting for you in this workspace, and reads `9+` past nine. Clicking a notification marks it read and takes you to what it's about. If Squad doesn't recognise the kind, the row still appears and still marks read; it just has nowhere to send you. **All activity** at the bottom of the popover opens the full [Activity](/activity) feed, which is the complete change log rather than the subset you subscribed to. With nothing waiting, the inbox shows **No notifications yet**. New notifications also appear as a toast in the corner while you have Squad open. Clicking the toast does the same thing as clicking the row. ## What Squad notifies you about **Action assignments.** Someone assigns an action to you. This one is directed at a person rather than broadcast, so it defaults to in-app and email both. Individual insights, documents and briefs don't notify. They arrive in volume, mostly made by machines, so one notification each would drown out the things aimed at you. Squad never notifies you about something you did yourself. **Agent reports.** Every agent that writes reports gets its own row under **Agent reports** in Settings, so you follow the ones you care about and ignore the rest. Each row names the agent and links to it. There is nothing to turn on at the agent's end: reports always reach their subscribers, and the two switches decide whether yours arrive in-app, by email, or both. A briefing arrives differently on each channel. **In-app** gives you the headline and opens the briefing when you click it. **Email** carries the whole briefing, so you can read it without leaving your inbox; a briefing too long to send in full says so and links to the rest. If nobody is subscribed, the run records the delivery as skipped rather than failing, and says why. See [Agents](/agents). ## Cookbook Open **Settings**, go to **Notifications**, and turn both switches off on the topics you don't want. Squad notifies you only about things aimed at you, so there is not much to mute, but a workspace with many agents can get loud. Turn off the agents you don't follow under **Agent reports** and check [Insights](/insights) on your own schedule. Turn **In-app** on for it. That is the channel that delivers. The two switches are independent, so a row can be set one way, both ways, or not at all, but **Email** on its own means the topic reaches nobody. Open the **Inbox**, work down the list clicking through the ones that matter, then hit **Mark all read**, which clears the lot rather than just the visible page. For the fuller picture of what changed while you were out, including everything you never subscribed to, click **All activity**. The switches are per workspace. Switch workspace, open **Settings**, and set the toggles differently there. # The evidence pipeline Source: https://docs.meetsquad.ai/pipeline How Squad gets from a customer complaint to a decision you can defend. The evidence pipeline The evidence pipeline Squad runs one chain. Feedback arrives from your connected tools and gets broken into individual claims. Those claims group by meaning, the groups get synthesised into findings, and the findings turn into work. Every screen in the product is one stage of that chain, and each stage below links to the page that covers it. A source hands Squad raw text. That might be a Slack thread, a GitHub issue, a Gong call transcript, an app store review, a page an agent read, or a document you uploaded. Squad reads it and pulls out the specific claims it contains, one per **data signal**. A signal keeps the verbatim quote, a one-line summary, a type (pain point, feature request, bug report, and so on), a sentiment, a strength between 0 and 1, and a link back to where it came from. Nothing gets paraphrased away, so you can always read the customer's actual words. See [Data signals](/signals). The moment a batch of signals lands, each one is compared against the existing clusters of the same type. Close enough to one, it joins. Close to nothing, it starts a cluster of its own. The comparison is on meaning rather than wording, so "the export takes forever" and "CSV downloads time out" can end up in the same place. Once a cluster reaches three members, Squad reads them and writes a theme label plus a confidence score for how well the grouping holds together. Under three members a cluster stays unnamed, which is why a new workspace shows an empty Signal Clusters tab for a while. See [Signal clusters](/signal-clusters). When a clustering pass finishes, Squad looks at every active cluster with at least two members and synthesises what they add up to. A one-member cluster also qualifies if the signal behind it was captured deliberately by you or a teammate rather than picked up passively. An **insight** has a title, a description, and a link back to every signal supporting it. Before it's saved, the new insight is checked against the ones you already have. A near-identical match folds into the existing insight instead of duplicating it. A close but distinct match creates a new insight with a "related to" link to its neighbour. See [Insights](/insights). Every insight the extraction pass touched is rescored. The score has two halves. **Strength** measures how well evidenced the insight is. It combines volume (how many signals), statistical confidence in that volume, how many distinct customers those signals came from, and how many different kinds of source corroborate it. A brand new insight with two signals is pulled toward your workspace's baseline rather than being crushed to zero. **Momentum** measures whether the theme is alive. Recent signals count for more than old ones, a sudden burst of arrivals lifts it, and the trend over the last four weeks is read as accelerating, steady, or decelerating. The number you see on the Insights page is `strength * 0.6 + momentum * 0.4`. It moves when new evidence reaches the insight. It doesn't drift on its own between extraction runs. An insight that scores 0.65 or above is handed to Squad for action proposals. You get a short ranked list of next steps on the insight's detail page under **Squad recommends**. A nightly pass sweeps active insights over the same bar in case one crossed it since the last run. You can also trigger ranking by hand on any insight, which ignores the score bar entirely. See [Actions](/actions). Nothing gets written up automatically. When an action's real job is a document, you choose **Generate PRD** or **Generate decision brief** and Squad drafts it in the background from the evidence behind the action. You can also generate straight from an insight, or from a prompt of your own. See [Briefs](/briefs). ## Where goals fit Goals steer the judgement calls. They don't touch the arithmetic. During extraction, Squad decides which of your goals each new insight supports and writes those links. When it proposes actions, it sees your goals and their importance (1 to 5), so the ranking it returns reflects what you actually care about. Raising a goal's importance from 3 to 5 won't move a single number on the Insights page. It changes how Squad weighs relevance when it chooses and orders work. See [Goals](/goals). ## What holds the chain together Each stage writes a link rather than a copy. A signal points at its cluster and at the insights it supports. An insight points at its goals. A brief points at everything its body cites. That's why you can open any brief and walk back to the customer sentence that started it. Some of those links are yours to make and break. See [Relationships](/relationships). ## What runs itself and what doesn't Signal extraction, clustering, labelling, insight synthesis, scoring, and action proposal all run without you. Squad also links insights to goals on its own. Creating goals, deciding an action's priority and owner, generating a brief, and making the final call on a decision brief are yours. Squad never does those unprompted. ## Every stage, in order Individual claims, each with its verbatim quote and source Themes formed from signals that mean the same thing Scored findings, and how strength and momentum combine Concrete next steps, in priority order PRDs and decision briefs, backed by cited evidence The objectives that steer what Squad recommends How entities link, and how to trace a decision back to a customer sentence # Quickstart Source: https://docs.meetsquad.ai/quickstart Set up a new workspace, from the opening conversation to your first source and your first insights. Quickstart Quickstart Squad sets a workspace up by talking to you. There's no setup wizard and no form to fill in. Create a workspace and the chat panel starts a conversation, asks what your product is, and writes what it learns straight into the workspace as you answer. ## The opening conversation Until a workspace is set up, the chat panel opens on its own, docked to the right, and sends the first message for you. Squad's first question is waiting by the time the page settles. This happens once, on a workspace with no conversations yet. On a phone the panel stays closed until you tap **Ask your Squad**. Answer in prose. Squad saves as it goes rather than at the end, so a conversation you abandon halfway still leaves the workspace better off. ### What it asks first Squad works out what your product is before anything else. * **Product name and what it does.** Written to your workspace immediately. * **Your website URL.** Squad reads the site and writes a product overview document from what it finds, tagged `product`. * **The tools your team uses.** Name Slack, GitHub, Linear, Notion and it points you at [Integrations](/integrations) to connect them. * **Tech stack and target users.** Saved to the workspace description. ### What it asks next Once it can describe your product back to you, Squad moves on to the market around it. * **Competitors.** Name who you compete with and Squad researches each one and writes it up. * **Current priorities.** Tell it what matters this quarter and it creates [goals](/goals). * **Background research.** Squad kicks off a research run that keeps working after the conversation ends, writing competitor, market, trend and persona documents into your knowledge base. Documents appear as they land, so there's nothing to refresh. ### When onboarding is done Squad closes onboarding itself once it's confident it understands your business. The background research run also closes it when the workspace reaches five documents and one goal. After that the chat panel stops opening on its own and returns to whatever mode you last left it in. Your knowledge base already has five folders waiting. **Product**, **Competitors**, **Feedback**, **Market** and **Research**. Squad files what it writes into them and adds folders when a topic needs one. ## Then, in this order Work through these five and the workspace starts producing insights of its own. Give Squad the product name, the URL and at least one competitor. Everything downstream reads this context, so a thin workspace produces weak insights. Open [Integrations](/integrations) and connect where your feedback actually lives. Support conversations, sales calls, issue trackers, review sources. One busy source beats four sparse ones. [Slack](/integrations/slack) is the most common starting point. Squad breaks incoming text into [data signals](/signals), each keeping the customer's verbatim words and a link back to where it came from. Watch them land under **New evidence** on the [Dashboard](/dashboard). Signals that mean the same thing group into [clusters](/signal-clusters), and a cluster stays unnamed until it reaches three members, so expect the clusters view to look sparse at first. Clusters get synthesised into [insights](/insights), scored on how well evidenced they are and whether the theme is growing. An insight scoring 0.65 or above gets a ranked list of [actions](/actions) under **Squad recommends**. Read the top insight, check the signals behind it, then start or dismiss what it suggests. Create a [goal](/goals) and give it an importance from 1 to 5. Goals never change an insight's score. They change which work Squad puts in front of you, because it weighs relevance to your goals when it ranks actions. ## Checking your work The **Context health** card on the [Dashboard](/dashboard) scores the workspace from 0 to 100 and labels it Starved, Lean, Healthy, Bloated or Flooded. Press **Improve** for a breakdown by category and a list of specific things to fix, each with a button that takes you there. A fresh workspace starts Starved. Connecting a source and adding goals is what moves it. You can use Squad without finishing the setup conversation. It has less to work from, so its recommendations are more generic. Add context later by talking to the assistant, editing [workspace settings](/workspace-settings), or connecting a source that carries product context. ## Where to go next The sidebar, the command palette and reference chips What Squad can do for you once the workspace is running # Relationships Source: https://docs.meetsquad.ai/relationships How entities connect to each other, which of those links are yours to change, and what removing one actually does. Squad stores connections between entities as links, never as copies. A signal is not duplicated into the insight it supports. The insight points at it. That is why you can open a brief, follow it back to the insight, then to the signals, then to the customer sentence that started the whole thing, and find nothing has been paraphrased on the way. You read those links on detail pages. Every entity page carries panels listing what it connects to, and each panel is a table you can open, sort, and act on. ## Where relationships show up **Representative data signals** shows up to three quote cards, with **View all** opening the full table when there are more. The right column holds **Goals** (the goals this insight supports) and **Referenced by** (briefs and knowledge documents whose body cites it). **Cluster** names the theme the signal was grouped into, with the member count. **Related data signals** shows the nearest neighbours. **Insights** lists what the signal helped produce. **Referenced by** works the same as on an insight. The member signals appear as quote cards, and past a handful of members they also render as a paginated table. **Insights** in the right column lists what Squad synthesised from the group. **Insights** lists the top five insights attached to the goal, with **Manage** (or **View all N** past five) opening the complete list in a dialog. Rows behave the same everywhere. Click one to open it. Right-click for **Open**, **Copy ID**, **Copy URL**, and **Copy content as JSON**, plus **Remove** on the tables where the link is yours to change. ## What can link to what Six kinds of link can be created or removed on demand, whether you do it or Squad does it on your behalf. Each has a fixed direction. | Link | Direction | | - | - | | A knowledge document informs an insight | Document to insight | | An insight supports a goal | Insight to goal | | An insight is related to another insight | Insight to insight | | An action belongs to an insight | Action to insight | | A brief is derived from an action | Brief to action | | A brief cites an insight | Brief to insight | Anything outside that list is refused. You cannot attach a goal straight to a data signal, and you cannot link two goals to each other. The pipeline's own connections sit outside this set. A signal joins a cluster and a cluster produces an insight as the evidence moves, and neither is something you edit. ## The link you make yourself One of those six is under your control in the app, an insight supporting a goal. You can set it from either end. The **Goals** panel on the right of an insight page has **Link goals**, which reads **Manage links** once at least one goal is attached. The dialog lists your goals with a search box at the top. Press **Link** on a goal to attach it. An attached goal shows **Linked**, and hovering that button turns it into **Unlink**. Goals cannot be created here. If the workspace has none, the dialog says so and points you at the Goals page. The **Insights** section on a goal page has **Add insight** when nothing is attached, **Manage** when five or fewer are, and **View all N** beyond that. All three open the same dialog. **Add insight** inside it opens a search popover, typing filters the list, and insights you have already attached are left out of the results. You can't create an insight here either. Squad writes those from evidence. Ask the assistant to link an insight to a goal and it will, using the same rules. See [The chat assistant](/chat-assistant). ## Removing a link On the goal page, right-click an insight row and choose **Remove from this Goal**. A confirmation appears, headed with the reference you are about to detach (**Remove IN-42?**), and it spells out what will happen. The link goes, the entity stays, and you can re-link it later. In the insight's goal dialog, hovering a **Linked** button turns it into **Unlink** and one click detaches it with no confirmation step. Removing a link destroys nothing. The insight keeps its title, its description, its supporting signals, and its score. The goal keeps its title, its importance, and every other insight attached to it. Scores come from evidence alone, so detaching a goal will not move a single number on the Insights page. What changes is relevance. Squad reads your goals when it ranks actions for an insight, and an insight attached to nothing gets no help from that. See [Goals](/goals). Squad decides which goals an insight supports when it first creates the insight. If you remove a link Squad wrote, it stays removed. Fresh insights arriving later are matched against your goals as usual. ## What Squad links on its own Most of the chain is written for you. Signals join clusters as they arrive, clusters produce insights, and those insights carry a link back to every signal behind them. When a new insight comes out close to an existing one but distinct, Squad creates it with a "related to" link to its neighbour instead of merging the two. Actions are created against the insight they answer. Generate a brief from an action and the document keeps a link to it, plus a citation to the insight it argues from. Reference a `SI-`, `IN-`, `GL-`, or `BR-` chip anywhere in a document body and it becomes a link. That is what fills the **Referenced by** panel on the entity you mentioned. Delete the mention and the link goes with it. See [The evidence pipeline](/pipeline) for the full chain. ## Cookbook **Find the strategy gap.** On the Insights list, filter **Goals** to 0 and sort by score descending. Anything scoring well with no goal attached is either an insight nobody has connected or a gap in what you wrote down as strategy. Attach it from the insight's **Goals** panel, or rewrite the goal so it says something specific enough to match. **Prune a goal that has collected the wrong evidence.** Open the goal, choose **Manage**, and read the attached insights. Remove the ones that do not belong. What remains is the case for the goal, and the list you can walk in a planning meeting. **Trace a decision back to a quote.** Open the brief, follow the insight it cites, open that insight's supporting signals, and read the original text on any signal detail page. Every hop is a link, so nothing along the way was rewritten. # Signal clusters Source: https://docs.meetsquad.ai/signal-clusters The themes that form when many separate pieces of feedback say the same thing. One signal is a single customer sentence. A cluster is the shape a hundred of those sentences form. "Slow dashboard loads", "requests for SSO", "confusion in onboarding". Clusters are where a complaint stops being anecdote and starts being evidence. Signal clusters Signal clusters For how clusters fit between signals and insights, see [The evidence pipeline](/pipeline). ## Where clusters live Signal Clusters is the third tab on the **Insights** page, next to **Insights** and **Data Signals**. A cluster gets a `CL-` reference (`CL-12`) and a theme label once Squad has named it. ## How a cluster gets its name You don't create clusters. Squad forms them as signals arrive, comparing each new signal against the existing clusters of the same type and either adding it to the closest match or starting a new one. Naming waits for evidence. A cluster stays as **Pending label** until it reaches three members. At that point Squad reads a diverse sample of the members and writes a short theme label plus a **confidence** score for how well the grouping holds together. Around 0.9 means one clear theme. Around 0.6 means mostly coherent. If the members are too jumbled to name honestly, Squad writes nothing rather than inventing a label. Labels get refreshed as clusters grow, and a nightly pass revisits clusters whose membership has changed. A grouping that has drifted too far apart is dissolved and its signals go back into the pool to be regrouped. ## The clusters list One row per cluster. * **Theme.** The `CL-` reference, the label (or **Pending label**), and a type badge where one applies. * **Data Signals.** How many signals belong to the cluster. * **Confidence.** A bar showing how sure Squad is about the label. Filter by **Data Signals** count (presets 3, 5, 10, 25), by **Confidence** (0.2, 0.4, 0.6, 0.8), or by **Type**. Sorting and filters live in the URL, so a filtered view is shareable. Click a row to open the cluster. Types are the same seven a signal can carry. Pain point, feature request, bug report, praise, churn risk, competitive intel, and agent insight. A cluster only ever contains one type, so a bug report never lands in the same group as a feature request even when the wording is close. ## Inside a cluster **Members.** The signals that make up the theme. The five most recent show as quote cards so you can read the real feedback without clicking through. Larger clusters get a paginated table below with the rest. Every quote links back to its signal. **Info.** Type, signal count, how many insights the cluster has produced, label confidence, and when it was last labelled. **Insights.** The insights Squad synthesised from this cluster. More than three, and **View all** opens the full list. A young cluster will show none yet. New members and refreshed labels appear without a reload. ## How to read a cluster A theme worth trusting. An early hint that will either firm up or fade. Use the **Members** quotes to sanity-check that the grouping holds. If the quotes are talking about different things, the confidence score has usually already said so. Treat the **Insights** panel as the exit. A large, confident cluster with no linked insight means the evidence is there but the conclusion hasn't been drawn yet. ## Cookbook **Find out what's driving a spike in complaints.** Open the **Signal Clusters** tab, filter **Type** to pain point, and sort by **Data Signals** descending. Open the largest cluster and skim the member quotes. If there's a linked `IN-` insight, follow it to see the score and what Squad recommends. **Sanity-check a theme before you quote it.** Open the cluster, read its confidence in **Info**, then read the member quotes. If the label says "billing confusion" and half the quotes are about export speed, don't build a case on it. # Data signals Source: https://docs.meetsquad.ai/signals The smallest unit of evidence in Squad. One claim, quoted verbatim, with a link back to where it came from. A data signal is one claim, pulled verbatim out of something a customer or a system said. A line from a Slack thread. A sentence in an app store review. A complaint in a sales call. Everything above it (clusters, insights, briefs) traces back to a set of signals. Data signals Data signals For what happens to a signal after it lands, see [The evidence pipeline](/pipeline). ## What a signal carries Every signal has an `SI-` reference (`SI-482`) and these fields: | Field | What it holds | | - | - | | **Quote** | The original text, unedited. On the detail page this appears under **Quote from source**. | | **Summary** | A one-line version, used as the row title and the page heading. | | **Source** | Where it came from, shown as a badge. When Squad has a link back to the original, the badge is clickable. | | **Sentiment** | Positive, negative, neutral, or mixed. | | **Type** | Pain point, feature request, bug report, praise, churn risk, competitive intel, or agent insight. | | **Strength** | A bar from 0 to 1 for how much weight the signal carries. | | **Captured** | The date it arrived. | ## Where signals come from Signals come from three places. The providers you can connect today are Slack, GitHub, Linear, Jira, Notion, PostHog, Gong, and Fellow, plus four review sources (App Store, Google Play, Google Reviews, and Trustpilot). An agent pointed at a URL reads the page on its schedule and writes signals from what changed. A research run produces them too, at a lower weight. Files you upload and knowledge documents in the workspace get read for signals the same way an integration payload does. If a tool is not on the Integrations page, nothing from it reaches your workspace. ## How a signal gets weighted How much a signal counts depends on what kind of source produced it and how deliberately it was captured. An integration signal is **1.0**, the baseline everything else is discounted against. | Source type | Base weight | | - | - | | Integration | 1.0 | | Scraped from a URL | 0.8 | | Read out of a document | 0.7 | | Turned up by an agent during research | 0.6 | Something a product owner captured on purpose counts double. An agent's unprompted find counts least. | Captured by | Multiplier | | - | - | | A product owner, on purpose | 2.0 | | Another workspace member | 1.5 | | An integration you subscribed to | 1.0 | | An agent's research | 0.5 | | An agent, discovered unprompted | 0.3 | The two multiply together with the signal's own strength. That combined weight decides how much the signal pulls its cluster's centre of gravity and how much it contributes to an insight's score. Strength also decays with age, so a complaint from two years ago pulls less than the same complaint from last week. One thing a customer told you in a call, captured by you, outweighs a dozen passively scraped mentions. ## The Data Signals list Open **Insights** in the sidebar and pick the **Data Signals** tab. One row per signal, showing the `SI-` reference and summary, the source badge, whether it belongs to a cluster, its sentiment, and the capture date. Search with **Search data signals or SI-…** to match on text or reference. The filter toolbar narrows by **Source**, **Cluster** (has one or does not), **Sentiment**, **Date**, **Type**, and **Strength**. Strength offers presets at 0.2, 0.4, 0.6, and 0.8, and filters at or above the value you pick. Sorting and filters are held in the URL, so a filtered view can be bookmarked or pasted to a colleague. Right-click any row for **Open**, **Copy ID**, **Copy URL**, **Copy content as JSON**, and **Delete**. Click the row to open the signal. ## Inside a signal The detail page leads with the summary as its heading and the verbatim quote below it, so you read the customer's words before Squad's version of them. When the source has a link, the quote card carries it. **Cluster.** The theme this signal was grouped into, with the cluster's type and member count. Click through to see the rest of the group. **Related data signals.** Other signals close to this one. The first three show as quote cards. If there are more, **View all** opens the full table. **Info.** Source, sentiment, type, strength, and capture date, in the right-hand panel. **Insights.** The insights this signal helped produce. A signal that landed recently, or one in a cluster too small to synthesise, shows nothing here yet. **Referenced by.** Any brief or knowledge document whose body cites this signal. ## Cookbook **Check whether a complaint is isolated or a pattern.** Open the signal, look at the **Cluster** card. A cluster with 2 members and a **Pending label** means Squad hasn't seen enough of this yet. A cluster with 30 members and a confident theme label means it's a pattern, and the **Insights** panel tells you whether it's already been written up. **Audit what a source is actually producing.** On the Data Signals tab, filter **Source** to one provider and sort by **Date**. A connected tool producing nothing, or producing noise, shows up straight away. Fix it from [Integrations](/integrations). **Find your strongest recent evidence.** Filter **Strength** to the 0.6 preset and **Date** to the last month, then sort by strength descending. That's the evidence worth quoting in a review. # Workflows Source: https://docs.meetsquad.ai/workflows Switch one on and what a connected tool holds lands in Squad, with no agent and no brief. A workflow brings what a connected tool holds straight into Squad. Name it, say what it covers, switch it on. There is no brief to write. Most capture as things happen, so there is no schedule to pick either. The card tells you which kind you are switching on: **As it happens** for the ones that wait on the tool, **Keeps up to date** for the repo scan, which reads the repository when you install it and tracks it from then on. An [agent](/agents) reasons. A workflow does not. An agent reads what you gave it and decides what to do, which is what you want for research and reports, where a wrong answer costs you a paragraph. Ingestion is different. A customer's support ticket should reach your [signals](/signals) whether or not a model felt like fetching it that morning. ## Switching one on Open **Agents** in the sidebar and go to the **By Squad** tab. Workflows sit in the same gallery as the [agent templates](/agent-templates), with the provider's logo on the card and how often it runs where a cadence would be. A workflow card carries one button, **Set up**. There is no cog beside it, because a workflow has no brief to open and edit. Setting up a workflow Setting up a workflow Click **Set up** on the card. Every workflow is on the tab whether or not you have connected the tool behind it. Pick one you have not connected and the modal offers **Connect** for that provider right there. Tools that ask for a key collect it in the modal and drop you straight back on the form. Tools that sign you in on their own site send you back to this card with the modal still open. Jira ends on its settings page instead, because it needs you to choose which service desks Squad watches before it can bring anything in. The name is prefilled and yours to change. It is what you will scan for in the list, so name it after what it covers rather than the tool it came from. Each workflow asks for whatever it needs to know what is yours. Leave it empty and you get everything the connection can see. Gong calls skips this step, because the automation rule you wrote in Gong is already the filter. It starts immediately. For the capturing workflows, nothing that arrived before this moment is backfilled. You can run several instances of the same workflow. Two Jira workflows over two different sets of projects, each named for the team that cares about them, is a normal setup. **Set up** stays on the card once one is running, and the card badges how many you have. Take the prefilled name twice and the second becomes "Jira requests 2", so the list never shows you two rows you cannot tell apart. ## What you can switch on Every new service desk request, with its comment thread, as it is raised. Scope it to the service desks you pick, or leave it empty for every service desk the connection is monitoring. Meeting notes and their transcripts, as Fellow finishes them. Scope it by words in the meeting title, so "discovery" and "renewal" come in and your one-to-ones stay out. Call transcripts with speaker names, as Gong finishes recording them. This one has no scope to set: your Gong automation rule already decides which calls get sent. Issues people open, with their comment threads. An issue also comes in when it is reopened, so an older one joins the moment it comes back into play. Scope it to the repositories you pick. Reads one repository and writes up what the product does, capability by capability, into your [knowledge base](/knowledge-documents). Reads it when you install it, then corrects what merged code has made wrong. Fellow's scope is worth setting. Its trigger fires for every meeting the connected user attends, so an empty list pulls in one-to-ones, interviews and board calls alongside the customer calls you wanted. GitHub's scope is worth setting too. An empty repository list means every repository the install can see, private ones included, and installs are often set to **All repositories** on the whole account. ## Reading what happened Workflows appear in the **Agents** tab alongside your agents, with what they have captured and when they last did. Open one and the page is mostly its history. The repo scan reads differently: it writes documents rather than capturing items, so its history is a record of what merged and what it rewrote, and the documents themselves are in your [knowledge base](/knowledge-documents). A workflow's capture history A workflow's capture history Every attempt is a row, and there are three kinds. It arrived and is in your feedback. The title links out to the item in the tool it came from, when the provider has a web view for it. A repo scan uses this row for the other direction. A merge that changed files your documents describe says how many documents are waiting, and a finished rewrite says how many parts it corrected and at which commit. It was outside the scope you set. On a narrowly scoped workflow this is most of the list, and that is the workflow doing its job. On a repo scan it means a merge landed and touched nothing you have documented, or a rewrite ran and found nothing worth changing. Something went wrong, and the row says what. A transient failure is retried; a permanent one is not. This history is the answer to "why is nothing arriving". A column of skips means the scope is narrower than you thought. A column of failures usually means the connection broke. ## Running one by hand Most workflows wait on the tool and give you nothing to press. The repo scan is the exception, because keeping documents current is work you sometimes want done now. **Refresh** appears in the header when the **Freshness** row says documents may be out of date, and rewrites the flagged parts immediately rather than leaving them for the overnight sweep. **Scan the whole repository again** lives in the `⋯` menu. It asks you to confirm first, since a full re-read costs what the first scan cost and nothing on the page moves while it works. Starting either one disables both until it finishes, so an impatient second click cannot buy a second run. ## Pause, resume, delete **Pause** stops new items arriving and keeps everything else. Nothing is captured while it is paused, so this is a real off switch rather than a filter on the view. **Resume** starts it again, and the gap is not backfilled. Deleting removes the workflow and its history. Everything it already captured stays in your feedback, because those are signals now and they belong to your workspace rather than to the workflow that fetched them. A workflow shows **Error** when its connection stops working. The page says what broke and offers **Check connection** and **Retry**. Reconnect the provider on [Integrations](/integrations) first, then retry. A repo scan whose repository has dropped out of the GitHub install lands here too, and says so. Put the repository back in the install, then retry. ## Workflows and agents together Use both. Run a workflow to get the raw material in reliably, then point an agent at the [insights](/insights) it feeds, or at the [goals](/goals) those insights move. The workflow guarantees the evidence arrives. The agent is what has an opinion about it. # Workspace settings Source: https://docs.meetsquad.ai/workspace-settings Your workspace name, its icon, and what Squad notifies you about. Two tabs, nothing else. **Settings** sits at the bottom of the sidebar, under **Knowledge** and **Integrations**. The page holds two tabs, **Workspace** and **Notifications**, under the heading *Manage your workspace configuration*. Settings are per workspace. Switch workspace and you're looking at a different set. Workspace settings Workspace settings ## The two tabs Two things live here, the workspace name and its icon. ### Name Type into the **Name** field and click **Save**, or press Enter. Up to 120 characters. **Save** stays greyed out until you change something, and an empty name can't be saved. A toast confirms with **Workspace name updated**. Renaming the workspace also changes its web address. Squad rebuilds the URL slug from the new name and moves you to it, so an old bookmark or a link you pasted into Slack will stop working. Rename deliberately and re-share any links. ### Icon The icon shows next to the workspace name in the switcher. Click **Upload logo** to set one, or **Replace logo** to swap it. **Remove** clears it back to the default. PNG, JPEG, WebP, or SVG, up to 5 MB. Squad resizes what you upload to 256 pixels on its longest edge, so a large screenshot or a full logo lockup will come out small and unreadable. Use a square mark. There's no save step. The icon is stored the moment you pick the file, and you get a **Logo updated** toast. If a file is rejected the toast tells you why. The wrong format, over 5 MB, or still too heavy after compression (try a simpler image with fewer colours). A switch per topic controls what Squad tells you about, with separate in-app and email switches on each row. They're per person and per workspace, so your choices don't affect your teammates. Everything about those switches, the inbox they feed, and the notifications that ignore them is on [Notifications](/notifications). ## What isn't here **Workspace** and **Notifications** are the only two tabs. There's no API keys tab and no other settings screen behind this one. Members, invites, and roles are managed for your whole organisation, outside the workspace. There's no workspace deletion and no per-workspace billing. Connecting Slack, GitHub, Linear, and the rest happens here. What Squad's agents are allowed to read and write is set per agent.