GTM Pipeline Daily Digest — read-only morning brief for your agent fleet
Every weekday at 8am, one read-only agent queries your pipeline tables for the last 24 hours, computes find/verify rates, and drops a clean stat block into Slack. You can't tune what you can't see — this is the observability layer for a fleet of GTM agents.
The outcomes on their scorecard
New jobs, new leads, emails-found rate, verify rate, leads pushed to sequencer — the six numbers that actually matter, refreshed every morning before your team logs in.
If the scraper failed overnight, all counts come back zero — and the agent still posts. You spot the failure at 8am instead of three days later when a customer asks where their leads are.
workspace_db is set to `read_only: true`. The agent literally cannot UPDATE or INSERT. The safest agent in your fleet.
Six SQL queries + one Slack call + haiku. Costs cents per month to run, even on a daily cron.
How the work gets done
Once you have a scraper, an enricher, and a sequencer all running overnight on different cadences, the natural next question is "did it all work?" — and you don't want to answer that by opening five tables in a SQL client every morning. This agent is the read-only observability layer. It runs at 8am on weekdays, queries the pipeline tables for the last 24 hours of activity, computes derived rates (emails-found rate, verify rate), and posts a single formatted message to Slack. workspace_db is read_only=true so the agent literally cannot write to anything — that's the whole guarantee. It's the smallest agent in the pipeline by design: one model (haiku), one connector tool (Slack), six SQL queries, one message. Pair this with your scraper, enricher, and sequencer to close the observability loop.
You don't see how your overnight pipeline is doing until you go look. This agent makes you not have to look — every weekday morning, the stat block lands in Slack with last-24-hour counts and derived rates. Read-only, so it's impossible for the agent to corrupt anything. One Slack message per weekday morning. That's the whole job.
Your new teammate
GTM Pipeline Daily Digest
Read-only scheduled agent that runs every weekday morning at 8am, queries the pipeline tables for the last 24 hours of activity, computes find / verify rates, and posts a formatted stat block to Slack. workspace_db is read_only=true. The simplest agent in the fleet.
What it runs on
This hire is assembled from the public toolkit. Every piece below is a tool your own agents can call too.
How setup works
- 01
Claim the hire
One click. No questionnaire. The brief is already written from your business, and you can edit it before you build if you want to.
- 02
Your hire deploys itself
Agents, tools, schedules, memory, hand-off queues and the database schema are provisioned into your workspace automatically, then the first real run fires while you watch.
- 03
Hand it the keys it still needs
You land in chat with your hire and its findings. Anything it still needs is asked for conversationally, whenever you want.
Other hires that pair well
Champion Job-Change Watcher — daily LinkedIn company-change detection
A champion moving to a new company is one of the highest-conversion outbound signals in B2B. They already trust your product; their new employer doesn't. This agent walks your champion + customer list daily, detects company changes from LinkedIn, and pings Slack the morning it happens.
Outbound Research Analyst
Turn the people writing about your problem on LinkedIn — and the ones quietly liking and commenting on posts about your space, including your competitors' — into a qualified outbound pipeline: scraped daily, enriched with verified email, scored against your ICP, and added to both your LinkedIn outreach (HeyReach) and cold email (Instantly) campaigns — automatically and deduped.
X (Twitter) profile qualifier and enricher
Hand any X username to this agent and get back a qualified, ICP-scored lead with a verified email and a resolved LinkedIn profile.
Every hire is assembled from the same toolkit.
Same data sources, same database, same memory, schedules and queues. Point your own agent at the MCP endpoint and wire it your way instead.