Scout

Scout started as a personal way to stop useful community conversations from disappearing into browser tabs. It became a complete operating loop: find a public question, decide whether it signals a real RevOps problem, structure the context, prepare a useful response, and bring unfinished work back to the operator.

The important boundary is what Scout does not do. It does not post, comment, connect, or message anyone. It prepares work in Notion. A person decides what happens next.

View the public repository or inspect the v0.1.1 release.

The problem

A community post is not automatically a lead. It is evidence that someone is dealing with a problem, often described with more operational detail than a form submission would ever capture.

The difficult part is triage. Which posts describe a meaningful RevOps issue? What kind of problem is it? Is there a useful, non-generic response? Has anyone followed up? What happened after that?

Scout turns that scattered work into a visible queue without pretending the underlying people or conversations are owned by the system.

The operating loop

The six workflows form one system:

1. Capture: Read three public HubSpot Community RSS feeds or accept a signal entered manually.
2. Reduce: Remove old posts and posts without a RevOps keyword before sending anything to a model.
3. Qualify: Ask Claude to classify the remaining signal by warmth, persona, track, pain area, and response angle.
4. Map: Store qualified signals in a Notion database with a next action and a draft response.
5. Maintain: Fill missing drafts and move a signal forward when an engagement notification is recognized.
6. Report: Prepare stale-work nudges and a weekly scorecard for the operator.

Every workflow imports inactive and without credentials. The diagram's dashed line is the product boundary: everything above it prepares work; everything below it requires a person.

System architecture

The first workflow contains the complete discovery loop and is the only workflow required to begin. The remaining five add manual intake, follow-up, engagement tracking, draft backfill, and reporting.

The workflow uses built-in n8n nodes, HTTP requests to Anthropic and Notion, and explicit setup values near the trigger. A stranger can import Workflow 01, see the entire path, and understand what must be configured before anything runs.

Constraints shaped the product

Four constraints are part of the architecture rather than footnotes:

• The automated source is narrow. Scout accepts only three public HubSpot Community RSS feeds. It validates HTTPS, the exact host, the .rss path, and the absence of embedded credentials before making the first request.
• Human review is permanent. Claude can qualify a signal and prepare a draft. It cannot send the response.
• Volume controls are not billing controls. The public defaults limit candidate items, but model nodes can retry. The documentation tells operators to use provider-side usage controls as the actual guard.
• Retention is an operator decision. Notion stores the signal map, while n8n may retain execution inputs and outputs depending on instance settings. Activation comes after that policy is reviewed.

The availability of an RSS feed is not treated as permission for every downstream use. The repository's source policy is product guidance, not legal clearance.

What could carry to another source

Scout v0.1 supports HubSpot Community RSS and a RevOps signal schema. It is not a generic community scraper.

The reusable part is the system shape: intake, qualification, signal mapping, and human-reviewed action. GitHub issues, n8n discussions, or another community would need a separate connector, parser, validation boundary, and access-policy review. Adding a different feed URL to this release is rejected before the first request.

The public and private boundary

The public repository contains inactive, credential-free templates. Instance identifiers, workflow identifiers, credential references, active-state metadata, environment-specific values, and recipient addresses are removed before a workflow can become a reusable artifact.

Private operational exports stayed outside Git. Sanitized derivatives were rebuilt with deterministic template identifiers and passed through structure validation, a public-export scanner, tests, and current-tree and history scans. The released repository began as a clean public snapshot rather than carrying the private development history forward.

This was less convenient than uploading the original JSON. It was also the only release boundary that matched the claim being made.

The failure that changed verification

The first real n8n sandbox run failed before making an external request.

Scout used JavaScript's URL constructor to validate and clean links. The offline harness supplied that global, so 322 tests passed. The target n8n 2.36.8 Code sandbox did not supply it. Workflow 01 could not start, Workflow 02 rejected valid URLs, and Workflows 03 and 06 silently removed every link from their digest output.

The tests were not false. They were faithful to the wrong runtime.

The fix replaced the unavailable global with a dependency-free HTTP URL parser inside each affected Code node. More importantly, the test harness stopped injecting capabilities the target sandbox does not have. Regression checks then ran inside a real n8n Code node before the live service run continued.

That failure changed the release standard. Static structure, clean import, offline behavior, target-sandbox behavior, and live external-service behavior are now recorded as separate dimensions because one passing result cannot stand in for another.

Verification, separated by dimension

The current release records ten checks. Eight passed. Two have not been performed.

Workflow 01 was also imported through the n8n Editor UI for v0.1.1, rendered with its complete graph and setup notes, and saved inactive without credentials. The Editor UI path has not been separately tested for Workflows 02 through 06.

Read the complete verification record.

Results from one controlled run

The live run used a disposable n8n instance, a throwaway Notion workspace, reduced item settings, retries disabled, and a hard allowance of six Anthropic requests. Five were used.

Workflows 03 and 06 produced and exposed their computed digest content without executing the Gmail nodes. No Gmail credential was configured and nothing was sent.

The run says nothing about typical volume. Cost was not calculated, and the public defaults of five have not been exercised live.

What remains unverified

Scout has not delivered an email to a real inbox. Workflow 04 has not reacted to a real Gmail notification. Workflows 02 through 06 have not been imported separately through the Editor UI. Nothing has run on a schedule or in production.

Cost per run and setup duration have not been measured. Behavior has not been observed at the public default volume, through feed failures or format changes, beyond the first 100 open Notion rows, or through the fallback Needs review path.

Those are accepted limits of this release, not implied successes.

What this project demonstrates

Scout is a small operational system, but the work spans more than workflow assembly. It required defining a useful GTM signal, respecting the source boundary, choosing where automation should stop, translating RevOps judgment into a schema, building the workflows, testing their code, validating the target runtime, and releasing reusable artifacts without publishing private operations.

That is the work I am interested in: bridging marketing, RevOps, and engineering so a useful idea can become a system a team understands and can operate.

Repository and technical artifacts

• Explore the complete public repository
• Inspect the architecture and storage boundaries
• Read the source and extension policy
• Review the live-verification record
• Inspect Workflow 01

The repository is MIT licensed. It includes all six workflows, setup documentation, the exact Notion schema, synthetic fixtures, validation tooling, and the decision log behind the release.