PostHog and Cal.com bots, and alert hooks for platform agents

[replicas-connector]

Requested by Arjun Maheswaran, https://rowboat.spaces.x.rowboatlabs.com/s/01M0HWBJR0KSG04PWM4411N29X/m/01M40DPZC97A93XQP79CKB9BBZ

What

@PostHog and @Cal are new agent types. They work like those services' Slack apps: someone mentions a command, Harbor calls the service's API with the org's key, and the result is posted as the reply. No LLM is involved. Any platform agent can also send alerts into a space.

Commands (@X help lists them):

• PostHog: count <event> [days], top [days], query <HogQL>, insights [search], flags [search].
• Cal.com: today, tomorrow, upcoming, links, slots <type> [date], book <type> <YYYY-MM-DDTHH:MM> <email> [name], cancel <id> [reason]. Times use the key owner's Cal.com time zone.

Alerts:

• On the agent's page in the app, the owner picks a space and gets a secret webhook address. It is shown once and only its hash is stored.
• That address goes into the service's webhook settings. Alerts are posted into the space by the agent itself.
• Cal.com: booking events and the "Ping test" button. PostHog: any webhook destination, with a {"text": "…"} body posted as written.

Bots, not agents, in the app: they run commands rather than work things out, so the app calls them bots, as Slack does.

• The Agents dialog ("Agents and bots") lists them in their own section and adds them under Add bot. Add agent offers Hermes, Replicas and Custom.
• They're labelled "PostHog bot" and "Cal.com bot" in the roster, mention autocomplete and their page.
• Harbor still treats them as agent members, so nothing changes on the wire (SPEC §8 Integrations says why).

How

• Harbor:
  • connectors/commands.ts is a shared command connector: it reads the command, calls the API, replies, and handles keys the service rejects. connectors/posthog/ and connectors/cal/ each hold only their client, commands and alert wording, so another service is one module.
  • New posthog/cal pairs in AGENT_PAIRS.
  • Hook routes PUT/DELETE /v1/agents/:id/hook (owner, or an admin to turn off).
  • Pre-auth POST /v1/hooks/:agentId/:token. A wrong token and an unknown agent both return 404, so the address reveals nothing.
  • Migration 032 (agent_hooks), policy rules, and SPEC §8 "Integrations" and "Alerts", plus a CONTRACT bullet.
• App: PostHog and Cal.com options under Add bot (key prompt, how-to steps), an Alerts section on the agent's page, and the IPC and client calls behind it.

Not in this PR

• Clickable buttons, previews of private PostHog/Cal.com links, OAuth (pasted keys only), and plain-language requests.
• Official logos: the generic mark is used until they are added with a SOURCE.md.

Testing

• test/integrations.test.ts runs a real Harbor against fake PostHog and Cal.com APIs, built from their docs (checked 2026-10-03). It covers the commands, a rejected key, the region lookup, and the full hook lifecycle.
• Harbor: 542 tests pass and typecheck is clean.
• App renderer: 1126 tests pass and npm run typecheck is clean.
• Not tried against the real PostHog or Cal.com APIs. The field names in PostHog's insight-alert payload were not documented: a destination's default body is shown as the alert's name and properties, and an unknown shape is posted as raw JSON.

Deploy: additive change, so no server/app coupling. Needs HARBOR_INTEGRATION_KEY, as Replicas agents already do.

🤖 Generated with Claude Code

---

_{Created by Arjun Maheswaran with Replicas}