Claude CoWork Activation Plane

The Claude CoWork branch runs the same enrichment framework as the GCP branch — the same parsers, schema, indications, round trips and adversarial-monitor lane — but puts a person and a set of custom skills in front of it. CoWork starts and steers enrichment runs from chat, and then works the enriched leads through the HubSpot connector: outreach, scheduling, activity logging, deal conversion and content.

The activation plane

Two things make up the activation plane for a deployment:

1. The custom skills — packaged, repeatable workflows that know the probate program's rules: the brand, the compliance guardrails, the approval gates and the field-governance model.
2. The CoWork–HubSpot connection — the Cowork HubSpot connector, which reads the whole enriched record and writes activity back onto native HubSpot objects, alongside Gmail, Google Calendar and Google Drive.

The framework fills the record. The activation plane turns the record into a conversation, a meeting, a deal or a published post, and logs every action back onto the same contact.

Two patterns, one portal

Data flow

RapidUpload - File Drop v-1.1 ──▶ HubSpot contact (PENDING, lead_uid)
                                        │
   CoWork chat ── run_enrichment.py ────┤  Pattern A: S0 · A1 · A2 · B · C · LOAD
                                        │  DNC + contact append round trips
                                        ▼
                          enriched, routable HubSpot record
                                        │  read (unrestricted)
                                        ▼
   CoWork + custom skills ──────────────┤  Pattern B: outreach · appointment · log
     (HubSpot connector, Gmail,         │  status · deal · blog · social
      Calendar, Drive)                  ▼
                          activity logged back on native objects

CoWork vs GCP Cloud Run

The CoWork–HubSpot connection

The Cowork HubSpot connector is the other half of the activation plane. Both patterns share one portal, so the connection is governed by a single rule:

Connector tools

The field guard

scripts/field_guard.py reads assets/field_governance.json (denylist model, version 2) and checks every proposed property in order:

1. hs_lead_status — dropped if the target is ARCHIVE_LISTED, ARCHIVE_SOLD, ARCHIVE_VALUE or ARCHIVE_DNC. Archiving is the framework's decision. Any working-funnel value is allowed.
2. Immutable keys — lead_uid, lead_id, createdate, ingest_timestamp, hs_object_id are never overwritten.
3. Protected framework fields — dropped if the name is on the protected list or matches a configured prefix or pattern.
4. Everything else is allowed — native objects and standard properties.

After any workflow the skill reports what it read, what it sent or updated, and anything the guard dropped, so the line between the person's actions and the framework's fields stays visible.

Protected vs writable

Keep the denylist current against the live schema. If the framework's fields share a naming convention, set protected_prefixes or protected_name_patterns so new fields are protected automatically — without matching native hs_* names.

Lead → deal, without duplicates

Setting hs_lead_status = Open Deal is the trigger. On the full system the framework's open-deal mode also mirrors the contact onto a deal, so the skill creates deals idempotently: it checks for a deal already associated with the contact in the target pipeline and updates it, or creates one if none exists. The native contact↔deal association is the key; no custom snapshot fields are added, and the enrichment data stays reachable through the association.

Where the connection meets the framework

On this branch the orchestrator is scripts/run_enrichment.py, driven from a CoWork session. This is the admin skill of the activation layer: API batch processing across the portal, started and watched from chat. Full stage, schedule and schema detail lives in the Real Estate Enrichment Automation Framework reference.

What a run does

Driving it from chat

CoWork runs the CLI with the same flags the Cloud Run jobs wrap: --mode, --stages, --county, --limit, --oldest, --dry-run / --apply.

python3 scripts/run_enrichment.py --mode weekly --dry-run
python3 scripts/run_enrichment.py --mode catchup --stages A1 --limit 10 --oldest --dry-run
python3 scripts/run_enrichment.py --mode catchup --stages C --county Medina --limit 10 --oldest --apply
python3 scripts/run_enrichment.py --mode update --apply
python3 scripts/run_enrichment.py --mode catchup --stages LOAD --apply

Operating modes

Stage Engagement card

The Stage Engagement card on the control contact lead_uid=PIPELINE_SETTINGS sets the A1 value floor (default 175,000) and switches Stage B (default off) and Stage C (default on) for scheduled runs. Catch-up runs ignore the B/C toggles and always run the named stage.

Skills are the part of the activation plane a person actually uses. Each one packages a workflow with its rules, so the same request produces the same compliant, on-brand result every time. Custom skills were built for this program; plugin skills come from installed packages and fill in general CRM and social tasks.

Skill catalog

Capability map

probate-lead-engagement-google

The human-in-the-loop engagement layer over the probate portal. It reads the full record, including every enrichment field, and writes only to native HubSpot objects. New-lead creation is not enabled at this level, so the framework stays the only minter of lead_uid.

Every workflow follows one spine: read the portal → act through Google Workspace → log back onto existing native objects.

probate-content-studio-google

A recurring content engine for Plum Tree Real Estate Marketing / BuySellLiveOhio.com. Three stages, each separated by a human approval gate, with every item tracked in a JSON ledger (content_state.py) so nothing is lost between scheduled runs.

1. Research — a scheduled CoWork task (default weekly, Monday 08:00 ET) scans probate, estate, inherited-property and Northeast Ohio market topics, scores them, writes a research brief per idea and sends a digest of the best 2–3. Gate 1: the user picks.
2. Draft — writes the blog post and upserts it into HubSpot as a draft, writes one social variant per channel (LinkedIn, Facebook, optional Instagram and X), then self-checks compliance. Gate 2: the user edits and approves.
3. Publish / schedule — publishes or schedules the approved draft on HubSpot's hosted blog and records the live URL; schedules social where a connector exists, otherwise hands over a ready-to-post package. Gate 3: go-live time confirmed.

Ledger statuses: RESEARCHED → PICKED → DRAFTED → APPROVED → SCHEDULED → PUBLISHED, with HOLD and REJECTED for ideas set aside.

Brand skill

Anything a probate family or attorney receives carries the client brand, with identical chrome on every send.

Plugin skills

• hubspot-sales (by HubSpot) — the entry point for general CRM questions and quick updates: contact lookup, pipeline pulse, daily brief, call prep, call logging, follow-up drafts, contact import and portal onboarding.
• postiz — social scheduling, media upload and analytics across 28+ platforms. Media must go through postiz upload before it can be attached to a post.

Guardrails shared by every skill

• Human-in-the-loop. Outreach, publishing and posting are drafted, shown and sent only on explicit approval.
• No legal advice. The program is not a law firm; content explains process generally and points to an attorney where a topic touches legal steps.
• Empathy first. No pressure tactics or "motivated seller" language; the audience is often grieving.
• Fair housing and honesty. No steering, no fake urgency, no guaranteed outcomes.
• Never contact archived or DNC records. Outreach keys on contactable_channel.

CoWork integration is the lead-in product for future deployments. A client gets value from the activation plane before any cloud infrastructure exists: the skills and the HubSpot connection work against any portal, and the framework runs on demand from the same CoWork session.

Deployment sequence

1. Connect the portal. Attach the Cowork HubSpot connector and the client's Google Workspace (Gmail, Calendar, Drive).
2. Install the skills. Engagement, content studio, the client brand skill, and the hubspot-sales and postiz plugins.
3. Configure field governance. Verify field_governance.json against the live schema before the first write.
4. Load and enrich on demand. Run RapidUpload - File Drop v-1.1 for ingest, then run_enrichment.py from CoWork chat — trial passes first (--limit 10 --dry-run), one stage and county at a time.
5. Work the leads. Outreach, appointments, activity logging and deal conversion through the engagement skill; content through the content studio.
6. Schedule the recurring work. The weekly content research task and any recurring enrichment runs as CoWork scheduled tasks.
7. Graduate to Cloud Run when volume calls for it. The GCP branch runs the identical framework unattended; CoWork stays the engagement layer on top.

What carries over to a new client

Status