# An agent harness for PMs

> Almost everything a PM needs to stop being the human clipboard between Slack, Notion and their agents already ships in Claude Code. Here's my setup.

By [Tom Bennet](https://tombennet.dev/) · 1 Nov 2026 · 7 min read

![Pixel art of a person at an old telephone switchboard, seen from behind, patching tangled cables between four app windows: a chat, a document, a terminal and a bar chart.](https://tombennet.dev/_astro/switchboard-operator.DrQc-Rxe.webp)

The human clipboard.

I recently noticed that more of my time was being spent as the "glue" between different services.

A colleague DMs me a question I've answered before, so I ask Claude to dig out the most appropriate link and send it their way (I'd prefer not to perform an AI-version of LMGTFY). Other times I'm juggling windows, cross-referencing Hex Threads, Claude Code, Figma and Notion.

Sometimes it's the agents waiting on me. I start a Claude Code session to investigate a bug, and ten minutes later I check the terminal: the agent has spent the whole time waiting for my permission to query our analytics.

I'd rather spend my time **deciding what we need to do and how** than ferrying context between tools. So I decided to try and build a better agent harness.

_Animation: Agent view with five sessions across three folders. Sessions move from working to done, and when one stops to ask me a question, agent view flags it as waiting for input._

Agent view: every session in one place, grouped by folder, with the ones waiting on me flagged. I built this mockup by giving Claude screenshots of itself. Strong [Philip K Dick vibes](https://en.wikipedia.org/wiki/The_Electric_Ant).

## Where the problems arose

When I listed every place I was acting as the glue, it came down to three missing pieces:

- **Shared reach.** Every agent should see the same tools. Mine didn't: desktop app had some connectors, terminal sessions others, cloud sessions others again.
- **Attention.** I need to know when an agent needs me. Mine blocked silently in windows I wasn't looking at.
- **Handoff.** Giving an agent work should take one line. Mine needed the context re-explained every time.

Most AI-workflow advice is aimed at engineers: more capable agents, or fleets of them in parallel. I found my agents were capable enough already. I don't need a factory; I need better triage and communication between tools.

## My new setup: how it works day-to-day

Most of the time I have two windows open: Slack, and VS Code with my agents.

**Answering a question.** Alice DMs me asking whether we ever agreed on what counts as an activated user for the new onboarding flow. There's a Notion page on this, but I can't remember the title. So in agent view, I hand it to `pa`, my personal assistant agent:

```
@pa deal with alice's message
```

`pa` finds Alice's message, then searches my own past Slack messages, then Notion, then Linear. Once it finds the answer, it drafts a **short, concise, brief, direct, to-the-point** reply (even w/Opus 5.5 you really have to labour the point 😅) with links to the sources, and saves it as a draft in Alice's DM. Its row in agent view turns green and a notification tells me it's done.

_Animation: In agent view, I type “@pa deal with alice's message”. A new session reads Alice's DM, searches my past Slack messages and Notion, and is marked done. In Slack, a reply linking the Notion page is waiting as a draft in Alice's DM._

Handing over a DM: one line in agent view, then the reply waits in Slack as a draft.

**Fixing a bug.** Someone reports a bug in a channel. I react to indicate I'm investigating, and then:

```
@web-app /triage-bug see bug reported by Bob today in #product-issues
```

`@web-app` runs the session in that repo, and `/triage-bug` is a skill I wrote that:

1. reads the report
2. checks Amplitude for how many users are affected, and since when
3. checks LaunchDarkly for recent flag changes in that area
4. reproduces the bug
5. fixes it in its own worktree and checks test coverage
6. opens a draft PR
7. drafts an update in the original thread

The PR number appears on the session's row, coloured by the status of its checks.

_Animation: I react to Bob's bug report in #product-issues with 👀, then type “@web-app /triage-bug see bug reported by Bob today in #product-issues” in agent view. The session checks Amplitude and LaunchDarkly, reproduces and fixes the bug, and opens draft PR #482, whose label turns green when its checks pass. In Slack, an update is waiting as a draft reply in Bob's thread._

Triaging a bug. The PR label turns green once its checks pass, and the thread update waits as a draft.

**A week in.** I don't have any comparative statistics showing before & after - all I know is that I've spent markedly less time feeling like a switchboard operator. My trusty `pa` reports 51 agent sessions completed (I can hear the engineers in the room already - _"those are rookie numbers - gotta pump those numbers up"_).

Adopting [worktrees](https://code.claude.com/docs/en/worktrees) for coding - something I put off for ages - has also boosted my efficiency.

## It's mostly configuration

As of November 2026, almost everything I needed ships as standard in Claude Code, and [OpenCode](https://opencode.ai) has most of it too. I'd just been too "busy" to set it up properly.

| What I needed                        | Claude Code                                   |
| ------------------------------------ | --------------------------------------------- |
| Same tools in every session          | MCP servers at user scope                     |
| Agents working in parallel           | Background sessions, each in its own worktree |
| One place to see who's waiting on me | Agent view (`claude agents`)                  |
| An assistant that drafts replies     | A subagent plus the Slack MCP's draft tool    |
| One-line handoffs                    | Skills, like `/triage-bug`                    |
| Approval before anything goes out    | Slack drafts                                  |

Things move fast, so it's worth checking what your tools already do before you build anything.

If you're comfortable on the command line and in the code, it's an hour or two of setup at most, and I've included a generic version of my setup prompt [at the end](#wrap-up).

## How I set it up

**1. One parent folder as headquarters.** All my repos sit directly under `hq`, and that folder holds a single context file. It has a short description of each repo, where things live (channels, project keys, key docs), my rules for agents, and examples of how I work and write.

Claude Code loads context files (`AGENTS.md` / `CLAUDE.md`) from every parent directory, so every session in every repo inherits this one, including sessions running in worktrees.

```
~/hq
├── CLAUDE.md          ← loaded by every session below
├── web-app            ← repo 1
│   ├── CLAUDE.md
│   └── .claude
│       └── worktrees
│           └── free-credit-limit
└── avatar-quickstart  ← repo 2
    └── CLAUDE.md
```

**2. Every tool, connected once.** Slack, Notion, Linear, Amplitude, LaunchDarkly and Hex are all installed at user scope, so every session on my machine has the same reach. Permissions come in three tiers:

- Reads are pre-approved, so agents never stall on a lookup.
- Anything that changes state outside the repo asks me first.
- Sending a Slack message is denied outright. Agents can only save drafts.

**3. One pane to watch.** VS Code is open on the parent folder, with a terminal tab pinned in the editor area running agent view. I group it by directory, and the tab title shows how many agents are waiting on me. The code is one click away whenever I want it (which happens less and less often these days).

**4. A personal assistant.** `pa` is a custom subagent: one markdown file with a prompt, which any session can call. The prompt tells it where answers usually live and in what order to look. I use it for anything not tied to one repo or service.

**5. Skills for repeat jobs.** A skill is a markdown file of steps behind a slash command, so a job I hand over often, like `/triage-bug` above, is easily repeatable.

## Rules that made it work for me

- **I triage, the agent executes.** My first plan was an agent that swept my DMs every half hour. I binned this. Deciding whether an agent can handle a task takes me two seconds, and it's the most valuable filter in the system. It also means nothing ever acts on a message I haven't seen. So I read Slack as normal, and can hand something to my `pa` with one line.

- **Drafts are the approval gate.** When I open Slack, the agent's reply is already sitting in the composer, so I read it, tweak it and hit enter.

## Where I think this is going

First, it's worth noting how [my predictions in early 2025](/blog/lessons-from-ai-assisted-migration-to-astro) have fared.

I was using the cutting-edge Claude 3.5 Sonnet to migrate an old Hugo site to Astro, and found it useful for automating repetitive tasks but useless for making anything new. My conclusion back then was that AI _"works best as an eager assistant, or a helpful second pair of eyes. It's not a great pilot."_ Less than two years later, I have agents fixing bugs and opening PRs while I'm in Slack, and I often don't need to look at the code at all.

My attempt to one-shot [an SVG of a Venus Flytrap](/blog/lessons-from-ai-assisted-migration-to-astro#32-creating-a-new-astro-component) is quite funny in light of how [drawing pelicans on bicycles](https://simonwillison.net/2026/Sep/4/astra-pelicans/) has since become a weird proxy benchmark of a model's capabilities. Here's the same brief, given to Opus 5.5:

[Video](https://tombennet.dev/_astro/vft-diagram.C_02YhgD.mp4): Feb 2025 · Claude 3.5 Sonnet

Oct 2026 · Opus 5.5: _Interactive diagram: an open Venus flytrap seen from above, with three trigger hairs on each lobe. Touching a hair starts a 20-second window, and a second touch within it snaps the trap shut._

The 2025 Flytrap attempt, and the same brief built by Opus 5.5. Touch a trigger hair.

For what it's worth, here's where I see things going...

- **Engineers and PMs _who keep up_ won't be out of a job.** AI makes the output of the job better and faster, but that doesn't mean everyone will suddenly learn to manage agents and build great software.

- **Some roles will begin to merge.** The best senior PMs will start to look more like a hybrid of a PM and an engineer, and they will increasingly build their own bespoke tooling that works for them.

- **The ability to write will become more valuable than ever.** Here I mean the ability to write clearly in your own voice. For me, [writing is thinking](https://danielmiessler.com/blog/writing-is-closer-to-thought-than-code), and being able to concisely articulate the problem you're solving, the product you're building, and the value you're adding is only going to matter more.

Which brings me to a caveat. Don't become a meat proxy, pasting AI slop into Slack and Notion as your own. Let the agent draft; anything that needs actual thinking is still on you, and that's where you still add value.

## Wrap up

Anyone reading this who already has a vast, [Gas Town](https://github.com/gastownhall/gastown)-style factory of agents probably thinks this is quaint. But it works for me.

If you're a technically minded PM who's become the glue, **give it a try**. Here's a generic version of <a href="/agent-harness-setup-prompt.txt" target="_blank">my setup prompt</a>, which you can hand straight to Claude Code.

Thanks for reading!
