The Agentic Work Report · 2026-04-06 → 2026-07-05
The Agentic Work Report for Harbor & Pine
Harbor & Pine runs client work through Slack the way most agencies do: requests arrive in client channels, get re-typed into Asana, chased in threads, and summarized again for Friday updates. Across 12 channels we found four AI workers' worth of repeatable coordination — intake, traffic, reporting, and delivery support — adding up to roughly 23 hours of skilled people's time every week. None of it requires replacing anyone; all of it requires giving a well-scoped agent the same read access your coordinators already have, with your leads approving anything that leaves the building.
From 18,437 messages · 12 channels · 24 people · 9 connected apps · 16 skills observed · 19 lessons learned from your team's corrections. Estimates are directional — see methodology.
Where the week goes
Estimated hours of repetitive coordination per week, by worker.
Meet your agentic team
You'll recognize every one of these — they're built from your team's own threads. Each shows what it saves and how it runs; expand any worker for the receipts.
📥Juno · Client Intake Coordinator
No client request waits and none gets re-typed into Asana — every ask arrives scoped, assigned, and acknowledged.
8.7h/wk≈ $29k/year back- Triage inbound client requests~6.4h/wk
- Draft weekly client status updates~2.3h/wk
Works in #client-meridian, #client-bluffton, #client-northgate +1 more · runs these flows end-to-end in the tools you already use · Priya Raman signs off before anything leaves the building.
See how it runs — steps, tools, guardrails
Juno · Client Intake Coordinator
No client request waits and none gets re-typed into Asana — every ask arrives scoped, assigned, and acknowledged.
Juno watches the client channels, recognizes new requests, drafts the work ticket with everything the team needs (context, links, deadline, suggested owner), and posts an acknowledgment for the account lead to approve. Juno never communicates a commitment to a client and never sets a deadline without a human sign-off.
As head of accounts, Priya already reviews every client commitment in these channels — most intake threads end with her sign-off.
Dana answers most “where does this go / who owns this” questions today; she knows every client's scope boundaries by heart.
- Each client has a different tolerance for being asked clarifying questions — Meridian wants one consolidated question, Northgate prefers none until a draft exists.
- “Urgent” from a client contact who isn't the decision-maker still gets acknowledged fast but scheduled normally until the account lead confirms.
Triage inbound client requests
When a client posts a request in their channel, capture it as a structured Asana task with context, attachments, and a suggested owner and due date, then post a draft acknowledgment for the account lead to approve.
A client-side member posts a message containing an ask (new work, change request, question needing follow-up) in a client channel
The account lead approves the acknowledgment and the task before anything is posted to the client or created in Asana.
- Detect that a message is a request rather than conversation
- Pull related context: recent thread history, the client's active projects in Asana, any attached files
- Draft an Asana task in the client's project with a summary, links, and suggested owner based on who handles that work today
- Post the draft acknowledgment in-thread and tag the account lead for approval
- On approval, create the task and confirm to the client in the channel
- If nobody approves within 4 business hours, escalate with a DM to the account lead
- Check whether a request duplicates an existing Asana task before creating one — duplicate tasks caused rework twice in the window.
- Link every attachment the request references in the task; missing links were the most common follow-up question.
| Tool | Access | Scope | Why |
|---|---|---|---|
Asana project management | Write | Client delivery projects only (Meridian, Bluffton, Northgate) | Creates the intake task in the right client project |
Google Drive file storage | Read | Client folders for the three active accounts | Links the latest brief or asset the request refers to |
What we saw (evidence)
- Client channels averaged 30+ inbound asks per week that a coordinator re-typed into Asana by hand
- Multiple threads where a request sat unacknowledged for a day until someone asked “did we see this?”
- The same triage pattern (ask → clarify → task → confirm) repeats across all three client channels
Draft weekly client status updates
Every Friday, compile what shipped, what's in progress, and what's blocked for each client from Asana activity and channel history, and draft the status post for the account lead to edit and send.
Scheduled: Friday 9am, per client channel
The account lead edits and approves every status update before the client sees it.
- Pull the week's completed and in-progress tasks from the client's Asana project
- Scan the client channel for decisions and commitments made in threads
- Draft the status update in the team's usual format (shipped / in flight / needs input)
- Post the draft privately to the account lead for edits
- Account lead approves; the update is posted in the client channel
- Internal hour-tracking details never go in a client-facing update — one update was edited to strip them after posting.
| Tool | Access | Scope | Why |
|---|---|---|---|
Asana project management | Read | Client delivery projects only | The week's task activity is the backbone of the update |
What we saw (evidence)
- Account leads posted a near-identical “weekly update” format in each client channel most Fridays
- Several Friday threads where leads asked teammates to remind them what shipped this week
🚦Marlow · Studio Traffic Manager
Nothing slips and nobody has to nag — the “just checking in on this” hours go back to real work.
4h/wk≈ $14k/year back- Chase upcoming and slipping deadlines~2.5h/wk
- Compile the Monday resourcing digest~1.5h/wk
Works in #production, #design-studio, #copy-room · runs these flows end-to-end in the tools you already use · Theo Okafor signs off before anything leaves the building.
See how it runs — steps, tools, guardrails
Marlow · Studio Traffic Manager
Nothing slips and nobody has to nag — the “just checking in on this” hours go back to real work.
Marlow tracks due dates and handoffs across the studio's production channels, nudges owners before things slip, and compiles the Monday resourcing picture. Marlow never reassigns work or changes a deadline — it surfaces, humans decide.
Theo runs the Monday resourcing meeting and is the de-facto arbiter of who has capacity.
Client-impacting slips get escalated to Priya, matching how escalations already flow.
- Creative deadlines slip for good reasons — nudge once, then escalate with context instead of repeating.
- Deadlines blocked on client feedback belong to the account lead, not the maker — route the chase accordingly.
Chase upcoming and slipping deadlines
Watch Asana due dates against actual progress signals in the production channels, nudge task owners a day before deadlines, and flag genuinely slipping work to the traffic lead with context.
Daily scan of Asana due dates within 48 hours plus channel threads that suggest a blocker
Marlow only nudges and reports. Re-planning, reassignment, and client conversations stay with the traffic lead.
- Each morning, list tasks due in the next 2 days across delivery projects
- Cross-reference channel threads for blockers or waiting-on-client signals
- DM each owner a short heads-up with the task link and anything blocking it
- If a deadline has already slipped, post a summary in #production tagging the traffic lead
- Keep a weekly slip log so patterns (chronically underestimated work) become visible
- A “waiting on client” note pauses nudges — chasing the team for client-side delays caused visible friction once.
| Tool | Access | Scope | Why |
|---|---|---|---|
Asana project management | Read | All delivery projects | Due dates and assignees drive the nudge schedule |
What we saw (evidence)
- “Bumping this” and “any update here?” messages appeared dozens of times per week in production channels
- Deadline slips were usually discovered in the Monday meeting rather than when they happened
Compile the Monday resourcing digest
Before the Monday resourcing meeting, compile who is over/under capacity this week from Asana workloads and Harvest time entries, so the meeting starts from a shared picture instead of building one live.
Scheduled: Monday 7:30am
The digest is an input to the human-run meeting; Theo corrects and finalizes it live.
- Pull this week's assigned task load per person from Asana
- Pull last week's logged hours per person from Harvest
- Draft the digest: overloaded, underloaded, and unstaffed work
- Post to #production ahead of the meeting for the traffic lead to annotate
- Contractors log time in a separate Harvest project — the digest under-counted them once before Theo corrected it.
| Tool | Access | Scope | Why |
|---|---|---|---|
Asana project management | Read | All delivery projects | Task assignments are the capacity numerator |
Harvest time tracking | Read | Weekly time reports | Logged hours show actual load vs. planned |
What we saw (evidence)
- The first 30 minutes of Monday threads were consistently spent reconstructing who's busy
- Theo posted a hand-built capacity summary most Mondays, occasionally apologizing for it being late
📊Etta · Client Reporting Analyst
Month-end decks show up ready for review instead of eating days — numbers pulled, charts drafted, narrative outlined.
6h/wk≈ $20k/year back- Assemble monthly performance decks~5h/wk
- Flag invoice and budget drift~1h/wk
Works in #client-reporting, #marketing-analytics · runs these flows end-to-end in the tools you already use · Priya Raman signs off before anything leaves the building.
See how it runs — steps, tools, guardrails
Etta · Client Reporting Analyst
Month-end decks show up ready for review instead of eating days — numbers pulled, charts drafted, narrative outlined.
Etta owns the mechanical 80% of client reporting: pulling performance data, updating the deck template, drafting the “what happened and why” narrative for a strategist to sharpen. Etta never sends a report to a client and never invents an explanation for a metric it can't ground in data.
Sofia builds most reporting decks today and knows each client's KPIs and sensitivities.
Every client-facing report already goes through Priya's review.
- Every client deck uses that client's KPI vocabulary — Sofia keeps the mapping and corrects any drift from it.
- A metric that moved more than 20% gets flagged for a human explanation, never auto-explained.
Assemble monthly performance decks
At month end, pull each retainer client's campaign metrics, update the reporting deck from the template, draft the narrative sections, and hand the deck to the strategist with anomalies flagged for human interpretation.
Scheduled: first business day of each month, per retainer client
A strategist owns the narrative and an account lead approves before anything reaches a client.
- Export the month's metrics from GA4 and the ad platforms for the client's campaigns
- Update the deck template's charts and tables in Google Slides
- Draft the summary narrative, flagging metrics that moved more than 20% for human interpretation
- Post the draft deck in #client-reporting tagging the strategist
- Strategist edits the story; account lead approves; deck goes to the client
- Paid and organic results are reported separately — a merged chart was sent back for rework during the window.
- Never annualize a partial month; flag it as partial instead.
| Tool | Access | Scope | Why |
|---|---|---|---|
Google Analytics analytics | Read | Client properties on retainer | Source of traffic and conversion metrics |
Google Slides documents | Write | The 'Client Reporting' shared drive folder | Updates the deck from the agency template |
Meta Ads advertising | Read | Client ad accounts on retainer | Campaign spend and performance data |
What we saw (evidence)
- The first week of each month showed a burst of screenshot-pasting and 'deck almost done' threads
- Team members described report assembly as taking 'most of a day per client'
- The narrative sections follow a recognizable template across months
Flag invoice and budget drift
Weekly, compare logged hours against each retainer's budget and flag accounts trending over before month end turns it into an awkward conversation.
Scheduled: Wednesday morning
Etta flags; the account lead decides whether and how to raise it with the client.
- Pull week-to-date and month-to-date logged hours per retainer from Harvest
- Compare against each retainer's monthly budget
- Post a one-line status per account in #client-reporting (green/amber/red)
- For red accounts, draft the talking points a lead would need for the client conversation
- Retainer rollover hours are excluded from drift math — including them produced a false red flag once.
| Tool | Access | Scope | Why |
|---|---|---|---|
Harvest time tracking | Read | Retainer time reports | Logged hours vs. budget is the whole signal |
What we saw (evidence)
- Two month-end threads showed budget overruns discovered only at invoicing time
- Leads asked for 'hours so far this month' by hand several times
🔧Otis · Web Delivery Runner
Builders stay building — bugs, review requests, and launch checklists move themselves between Slack and the board.
4.8h/wk≈ $16k/year back- Turn client bug reports into triaged tickets~3.5h/wk
- Run pre-launch checklists~1.3h/wk
Works in #web-dev, #client-meridian · runs these flows end-to-end in the tools you already use · Dana Whitfield signs off before anything leaves the building.
See how it runs — steps, tools, guardrails
Otis · Web Delivery Runner
Builders stay building — bugs, review requests, and launch checklists move themselves between Slack and the board.
Otis bridges the web team's Slack and Linear: client-reported issues become triaged tickets, stale review requests get nudged, and launch checklists get compiled and tracked. Otis never merges, deploys, or closes a ticket — it moves information, humans move code.
Marcus triages most bug reports today and sets severity conventions on the Linear board.
Dana approves anything posted back to a client about an issue's status.
- Severity conventions are Marcus's call — suggest, never set, a P1.
- Timelines quoted to clients come from the account lead even when the fix is trivial.
Turn client bug reports into triaged tickets
When a client or teammate reports a site issue in Slack, reproduce the basics, file a Linear ticket with environment details and screenshots, suggest a severity, and confirm back in-thread once a human triages it.
A message describing something broken on a client site, in a client channel or #web-dev
The web lead confirms severity and scheduling; client-facing replies are approved by the account lead.
- Recognize a bug report and gather what's known: URL, screenshot, browser, expected vs. actual
- Check Linear for duplicates and link them if found
- File the ticket in the client's Linear project with a suggested severity
- Tag the web lead for triage confirmation
- Once triaged, post the ticket link and expected timeline draft for approval before it goes back to the client
- Always search Linear for an existing ticket before filing — duplicates were filed and closed twice in the window.
- A bug report without a URL or screenshot gets one clarifying question before it becomes a ticket.
| Tool | Access | Scope | Why |
|---|---|---|---|
Linear issue tracking | Write | Client web projects only | Files and links the triaged ticket |
What we saw (evidence)
- Bug reports arrived in client channels and were re-typed into Linear by hand, sometimes a day later
- The Linear app already posts ticket updates into #web-dev, so the loop is half-built
Run pre-launch checklists
Before each site launch, compile the standard go-live checklist (redirects, analytics, forms, SSL, backups) as a tracked thread, chase each item's owner, and summarize readiness for the launch call.
A launch date is set in #web-dev, or on request
Go/no-go is always a human decision on the launch call.
- Instantiate the team's go-live checklist as a thread with owners per item
- Nudge owners on unchecked items daily as the date approaches
- Summarize readiness (done / at risk / blocked) each morning of launch week
- Post the final readiness summary before the launch call — a human makes the go/no-go call
- Redirect verification happens on production, not staging — a redirect missed on staging shipped broken once.
| Tool | Access | Scope | Why |
|---|---|---|---|
Linear issue tracking | Read | Client web projects only | Checklist items map to open tickets |
What we saw (evidence)
- Two launches in the window used a copy-pasted checklist thread with manual chasing
- One launch thread showed a missed redirect item discovered post-launch
The skill library
The atomic skills your workers are built from — each observed in your history, with the people who practice it today.
Triage inbound requests
Recognize that a message is an ask, judge urgency, and get it in front of the right owner.
Asana, Linear
Capture request context
Gather the thread history, files, and prior work a request refers to before anyone starts.
Google Drive, Asana
Route work to the right owner
Know who handles what, and hand new work to them with context.
Asana
Deduplicate requests
Spot when an incoming ask already exists as tracked work and link instead of re-filing.
Linear
Draft status updates
Turn a week of activity into the team's shipped / in-flight / needs-input format.
Asana
Summarize long threads
Condense a winding thread into decisions made and actions owed.
Chase deadlines
Track due dates against reality and nudge owners before things slip.
Asana
Escalate blockers with context
Recognize a genuine blocker and raise it to the right person with what they need to act.
Pull metrics from tools
Export the right numbers from analytics, ads, and time-tracking tools without asking twice.
Google Analytics, Meta Ads, Harvest
Compile recurring reports
Assemble numbers and structure into the team's standing report formats.
Google Slides, Harvest
Draft data narratives
Write the first-pass “what happened and why” for a human strategist to sharpen.
Google Slides
Flag metric anomalies
Notice when a number moved enough to need a human explanation before it ships.
Google Analytics
Track budget vs. actuals
Compare logged hours to retainer budgets and see drift early.
Harvest
Flag billing drift
Turn budget drift into an early, private heads-up with talking points.
Harvest
Run structured checklists
Instantiate the team's standing checklist, chase every item, and report readiness.
Linear
Send scheduled reminders
Remind the right person at the right moment without becoming noise.
Assumptions we made
Unverified reads the analysis relied on — confirm or correct each in a minute.
- We assumed #client-northgate's voice-note feedback is transcribed and summarized by hand today — nobody in the window said otherwise.
- We assumed the Harvest retainer projects map one-to-one to the three client channels; if retainers are split differently, Etta's drift math changes.
- Hours estimates extrapolate a 90-day window to a steady-state week — seasonality (pitch season, launch crunches) is not modeled.
- We assumed the people most active in each channel are the right teachers for its workers; job titles weren't visible in Slack.
Channel by channel
Inbound requests, revisions, and status updates for the studio's largest retainer.
Roughly one in five messages is a request that someone re-types into Asana.
Campaign coordination and weekly reporting for a marketing retainer.
The Friday status update has followed the same three-section format for 11 straight weeks.
Design review cycles with a slower-moving brand client.
Feedback arrives as long voice-note transcriptions that someone summarizes by hand.
Cross-project traffic: deadlines, handoffs, and capacity.
“Any update on this?” and its variants appeared 200+ times in 90 days.
Critique, asset handoffs, and version wrangling.
Figma links are shared constantly, but the 'final-final-v3' file-naming saga is alive and well.
Drafting, review rounds, and tone debates.
The work here is judgment-heavy craft — the coordination around it lives in #production.
Build progress, bug triage, code review, launches.
Linear and GitHub apps already post here — the plumbing for an agentic loop half-exists.
Monthly deck assembly and metric wrangling.
Report-building consumes the first week of every month for two people.
Ad-hoc metric pulls and campaign checks.
Most asks are variants of the same five queries.
Lead handling, proposal drafting, pitch prep.
Proposal boilerplate is reassembled by hand for every pitch.
Announcements and social chatter.
Leave it be — this is where the team is a team.
Links, templates, and 'where is that doc?' archaeology.
The same onboarding questions get re-answered roughly monthly.
The tool access, all in one place
Every tool the workers touch and the access each needs. Start read-only where you can.
| Tool | Category | Used by | Access |
|---|---|---|---|
| Asana | project management | Juno, Marlow | Write Read |
| Harvest | time tracking | Marlow, Etta | Read |
| Google Analytics | analytics | Etta | Read |
| Google Drive | file storage | Juno | Read |
| Google Slides | documents | Etta | Write |
| Linear | issue tracking | Otis | Write Read |
| Meta Ads | advertising | Etta | Read |
Honest watchouts
- Estimates are extrapolated from 90 days of messages — treat hours as directional, not payroll math.
- Client-facing communication should keep a human approver indefinitely, not just during rollout; the trust cost of one bad automated client message outweighs months of saved time.
- #copy-room and the craft side of #design-studio scored low on purpose: the work is the judgment. Automate the coordination around creatives, not the creating.
- Budget and invoice data (Harvest) is sensitive — start Etta with read access to reports only, and audit what she posts for the first month.
How this was made
Scout read 90 days of history from 12 channels — 18,437 messages from 24 people and 9 connected apps. Deterministic signal detection first mapped the requests, chase messages, recurring cadences, approvals, and correction/rework moments in every channel; frontier-model analysis then identified the atomic skills being exercised, the lessons in the corrections, and the flows they compose, recorded anything it couldn't verify as an explicit assumption, and organized everything into workers a team could actually onboard. No message content leaves the analysis; raw messages are deleted once this report exists.
Want Ergoly to onboard these workers?
Ergoly builds and runs trainable AI workers for Slack. Leave your email — we onboard new teams as capacity opens.
Made with ergoly.ai · paraphrase-only, no verbatim quotes · privacy