Platform Opportunities Addendum
Fresh-eyes review of the 2026-07-07 Build on Agend doc set: the opportunities that live in the seams between the documents. Each was invisible to the docs individually because they were written in sequence. Status: OPPORTUNITY REGISTER · 2026-07-07 · Companion to
platform-readiness-scorecard.md
O1 · Objects × Workflows = "Programs" (the product hiding in two scorecard rows)
Scorecard #8 (custom objects) and #7 (workflows for clients) are listed separately. Their intersection is a sellable product: a client defines a Mentorship object (ADR-001), then wires workflows to its events — on created → email both parties; +30 days → check-in survey; on status=complete → award CPD points. That is a no-code program builder, and "programs" (mentoring, awards cycles, SIGs, buddy schemes) are what associations currently run in spreadsheets.
- Cost: near-zero beyond the two rows themselves — the combination needs only object events registered as workflow triggers (already in the build plan, slice 3).
- Value: a named, demoable platform capability ("Agend Programs") rather than two infrastructure features; directly answers "can we build X?" for the most common X.
- Action: name it in the platform narrative; demo = mentoring program end-to-end once slices 0–3 land.
O2 · The registry is a triple surface: REST + widgets + MCP (the AI angle)
The repo already ships @agend/mcp-tools, an MCP server and an agents registry — absent from the scorecard's ten primitives and every client-facing doc. The object registry (ADR-001) can drive three surfaces from one catalogue: register mentorship once → REST endpoint + widget + an AI-agent-callable MCP tool, automatically.
- Why it matters: associations will want member-facing assistants ("when's my membership due?", "book me into the conference"). A registry designed for MCP exposure now makes every object — system and custom — AI-accessible for free later; retrofitting is a rebuild.
- Cost: a design constraint on the registry (slice 2), not a build. Tool-generation from registry entries is a later, separately-sized piece.
- Action: add "MCP exposure" to the registry's design requirements; added as scorecard row #11.
O3 · Sync vs migrate: W4 events might be the wrong plan
Every doc assumes events = build the Upbeat events ingest driver (the flagged-hardest, ~40%-bespoke case). But the dashboard has a native Events module (22 API routes: tickets, registrations, check-in, waitlists, iCal). The unexamined alternative: migrate event management INTO Agend and let Upbeat's events become legacy — a data-migration project instead of the hardest driver build.
- Decision framework (per module, not just events): sync when staff workflow and the system of record must stay in Dynamics; migrate/adopt-native when Agend's module is equal-or-better and the Upbeat model is the bespoke tail.
- Action: decision doc before any W4/driver work starts; full analysis in
upbeat-data-bridge-map.md§4.
O4 · Generic Upbeat driver → custom objects (config, not code)
ADR-001 rightly keeps custom objects out of Upbeat sync for v1. The forward opportunity: a config-driven generic driver — point at any BusinessConnector endpoint, declare a field map, land records in a client-scoped custom object. Read-only, no write-back.
- Value: turns future entity feeds (committees, qualifications, CPD history, loyalty, ref data) from bespoke driver builds into configuration; also a cheap read-side stopgap for entities awaiting a proper home.
- Cost: one driver that takes (endpoint, mapping, target definition) instead of hard-coded pairs — a natural slice after the custom-objects MVP.
O5 · The commercial layer is unwritten
Metering is shipped; nothing prices it. Missing pieces, in order of leverage:
- Packaging one-pager — sandbox (free) / builder / platform tiers; custom-object, key and API-call allowances mapped to the existing entitlement checks.
- Agency ecosystem — every association's web agency is a channel: partner tier, certification, listed-partner directory. Appears in zero documents; it converts "AHRI wants control" into a go-to-market motion.
- Platform contract (scorecard #9) is the trust prerequisite for both.
- Action: commercial modelling session (Glen-led — pricing judgement, not engineering).
O6 · One WordPress build for every client type (the convergence play)
The hub is CRM-agnostic — Upbeat is one pluggable source, not a dependency. That collapses Agend's two WordPress product lines (the proprietary Upbeat kiosk plugins AND the legacy Groundhogg-based AMS build) into one WordPress experience: the thin no-IP integration plugin (BOA-08) + widget library + a scoped API key, identical for three client configurations:
| Client type | Behind the hub | Notes |
|---|---|---|
| Upbeat clients | upbeat-* drivers + write-back outbox | The full bridge; write capability arrives with W1–W4 |
| Legacy AMS (Groundhogg) clients | One-off migration, no bridge — apps/crm/lib/migration Groundhogg transformers + wp-migration-* schema migrations already exist | Simplest type: no sync, no conflicts, all write capability available immediately |
| New clients | Nothing — native Agend CRM | Day-one platform clients |
- Value: every widget/API improvement ships to all clients of all types simultaneously; "clients like WordPress" flips from legacy burden to distribution channel; the legacy-AMS migration doubles as the upgrade sales motion ("same site, better engine").
- Prerequisite: a one-page old-AMS → suite-module parity map before the first legacy migration (see
legacy-ams-parity-map.md). - Rule of thumb: bridge clients with a CRM investment worth preserving (Dynamics); migrate clients whose CRM was Agend's own implementation choice (Groundhogg).
Small gaps patched in this same commit
| Gap | Where fixed |
|---|---|
| W4 sync-vs-migrate alternative absent | writeback-two-way-sync.md Phase W4 note |
| MCP/AI surface absent from primitives | scorecard row #11 |
| Webhook egress (SSRF) never audited | hardening findings — unchecked areas |
| Data portability clause missing | operating model — change management |
| Custom objects absent from AHRI workshop agenda | operating model — open items |
| Generic object widget not future-proofed | WP plugin spec — future scope note |
What this register is for
Review these when sequencing each quarter. O1 and O2 are cheap design constraints on work already planned; O3 is a decision that could delete the hardest roadmap item; O4 compounds the objects investment; O5 is the only one requiring no code at all.