Working-session capture, 2026-06-15. Founder answered the open architecture questions from the [[2026-06-14-caf-restructure-organizing-brief]]; this doc records his answers, the decisions that follow, and a first-pass meta-council × workflow-pattern map (his ask #7). Builds on the verified plugin/MCP mechanics in [[2026-06-14-caf-restructure-organizing-brief]] (addendum) and the [[2026-06-04-agent-workflow-patterns-catalog]].
Founder answers (2026-06-15, verbatim gist)
- Data governance / tenancy. All client discovery info lives in a flat, evenly-accessible Google Drive — any phData engineer can see all clients (assigned or not), gated to phData-internal. Same flat structure should work in Snowflake. The only hard wall is external: client info must not leak across tailored demo sites.
- Collaborators / harness. ~12 engineers + ~60 salespeople. Majority of work in Claude Cowork.
- Scale. Full Fortune 2000 + many private companies. Leaning Snowflake VARIANT columns (Postgres JSONB may be equivalent).
- 321GO. New offering, owned by Vincent (Chief Strategy Officer); vision well locked-in.
- Contract shape (Contracts 0-6). Deferred — "talk through this later." → parked for a live working session.
- Partner site platform. Doesn't need a particular platform; assume AWS, keep it as simple as possible.
- Meta council. Should be per phase; wants it diagrammed with the workflow patterns (delivered below).
- Sandboxes. phData has Snowflake sandbox envs available.
Locked architecture decisions (follow from the answers)
A. Tenancy model — "open internal, hard-walled external" (the load-bearing call)
- Internal data plane is flat + shared. No per-client row isolation internally; mirrors the current flat Drive. This removes a huge amount of multi-tenant complexity (no internal RLS, no per-client schemas).
- The entire isolation budget moves to ONE chokepoint: the external tailored-demo boundary. A tailored/demo site must serve exactly one client's data and never another's.
- Design consequence: the tailoring step is the security-critical step. The agent emits a per-client, client-scoped JSON bundle; the external site renders only that bundle; the gated URL serves only that client. Get this one seam airtight and the rest can stay simple.
B. Datastore — Snowflake VARIANT + a thin typed spine
- Catalog = Snowflake (sandboxes already exist, #8). Use VARIANT for the flexible/evolving per-client discovery payload (#3).
- Wrap the VARIANT blob in a thin typed spine so it stays queryable + governable:
client_id, phase, contract_id, status, created_at/updated_at, owneras real columns; everything fluid in VARIANT. (Avoids "everything-in-one-blob" un-queryability.) - Postgres JSONB is a viable alt but Snowflake wins on "they already have it + sandboxes + it's the phData house platform."
C. Harness + distribution (VERIFIED against current Anthropic docs 2026-06-15)
- Data plane = ONE shared remote MCP server, and it spans BOTH harnesses. Claude Code connects it (bundled in the Code plugin, per the June-14 addendum); Claude Cowork connects the same server via "Custom Connectors" (org-admin configurable, OAuth + URL). → the data tools are unified across Code + Cowork.
- ⚠️ Constraint: the MCP server must be internet-reachable from Anthropic's IP ranges (allowlist Anthropic IPs if it sits behind a private network/VPN). Factor this into where the data API is hosted.
- Skills distribution is per-surface, because Cowork plugins ≠ Code plugins:
- Cowork-primary rail (the ~60 salespeople + most engineers): org-admin-published Skills via Team/Enterprise Organization settings — these appear across Cowork, the Desktop chat tab, and web chat. This is now the dominant skills rail, given #2.
- Code rail (the dozen engineers who live in Code): the Code plugin (skills + the MCP connector bundled).
- Author skills once; distribute on whichever rail(s) the audience uses.
- This refines the June-9 "plugin = Code only" call: the data plane is universal (remote MCP, both surfaces); skills ride two rails (org-published for Cowork, plugin for Code). Cowork being primary means org-published skills is the main rail, not the plugin.
D. Demo / partner site — AWS, quick-sites pattern, simple
- Per #6: AWS, keep it simple. Use the quick-sites pattern (static shell + per-client JSON bundle from the store + gated URL); agent emits JSON, not bespoke HTML.
- This is also decision-A's isolation chokepoint — the per-client gated URL is where "no cross-client leakage" is enforced. (RDCO's quick-sites uses Cloudflare Access OTP for exactly this; the AWS equivalent = e.g. CloudFront + Cognito/signed-URL gating, one client per site.)
- AWS deploy path for the static Astro shell (verified vs current docs 2026-06-15 night): no official one-click "Claude→AWS." Two static paths: S3 + CloudFront (community consensus; Astro has an official AWS deploy guide) or AWS Amplify Hosting (Git-connected, auto-build/deploy, CDN+SSL, automates the S3/CloudFront plumbing — simplest). The bridge from a Claude-built codebase: AWS open-sourced "Agent Plugins for AWS" (Feb 2026) incl. a
deploy-on-awsplugin for Claude Code (analyze codebase → recommend services + cost → generate CDK/CloudFormation → deploy on confirm). NOT "Claude Platform on AWS" (that's running Claude models via AWS IAM/billing, unrelated). claude.ai Artifacts have no export/deploy path (preview-only) — copy code out first. Next step offered to founder: trial the deploy-on-aws plugin on a throwaway Astro site to learn the flow before the CAF demo. (Founder declined the plugin 2026-06-16; wants the official Astro→AWS guide or Amplify path documented as "written support.") - ⚠️ OPEN FORK raised 2026-06-16 night — static demo vs LIVE APP (likely supersedes the static framing above). Stakeholders want (a) sales reps editing use cases in the UI and persisting back to the DB (writes), and (b) generating a new use case live on a call via the Anthropic SDK. That's an interactive app, not a static site. Cascade if confirmed: DB → Postgres/RDS (OLTP serving store; Snowflake = analytics/source-of-truth or steps back — exactly the live-backend case flagged in the ERD doc; VARIANT→JSONB port already designed); framework → full-stack (Next.js/Remix/SvelteKit) fits better than Astro (Astro can SSR+endpoints+islands but you fight its content-first grain for an edit/generate app — keep Astro only if mostly-static w/ small islands); hosting → needs server compute (Amplify SSR/functions, or Lambda/ECS/App Runner behind CloudFront, + RDS in a VPC); Anthropic SDK = server-side only (key never in browser; endpoint does input→Claude→persist→return). Ray offered to spec both side-by-side — founder said go 2026-06-15 night; spec delivered → [[2026-06-15-caf-demo-readonly-vs-liveapp-spec]]. Synthesis: one system, two surfaces (live app = internal authoring source of truth; static read-only = hardened external export sharing schema/contract/components). Now awaiting founder's framework + phasing call (Ray leans Next.js + Aurora Serverless v2).
E. 321GO
- Vincent (CSO) owns it; vision locked (#4). The sales-demo site is the surface; build to his vision, don't re-spec it. Demo site = the decision-D AWS quick-sites pattern.
Meta-council per phase × workflow patterns (answer to #7)
The meta-council is a per-phase quality gate, not a single end-of-engagement review. Expressed in the [[2026-06-04-agent-workflow-patterns-catalog]] vocabulary:
ENGAGEMENT = Pipeline (#7) over phases
Phase 0 ─▶ Phase 1 ─▶ Phase 2 ─▶ … ─▶ Phase 6
│ │ │
▼ ▼ ▼
[META-COUNCIL GATE] (one per phase, same shape each time)
ONE GATE (zoomed in):
phase output
│
▼
[Classify-And-Act #1] ── route to the right VALIDATION ARCHETYPE
│ (domain-rule check / data-grounding / client-fit / feasibility)
▼
┌─ council member ─┐
│ (lens: domain) │
│ council member │ Adversarial Verification (#3):
│ (lens: client- │ each member INDEPENDENTLY tries to refute
│ fit) │ the phase output through its own lens
│ council member │
│ (lens: data- │
│ grounding) │
└──────┬───────────┘
▼
consensus? ──no──▶ [Evaluator-Optimizer #9 loop]
│ phase REFINES → re-submit → re-judge
│ (until pass OR escalate)
│
unsure / high-stakes ──▶ HITL checker (human gate — the
│ Classify-And-Act "unsure = its own
│ escalating branch" design)
▼
pass ──▶ advance to next phase
Pattern roll-up:
- Engagement = Pipeline (#7) of phases (items = engagements flow through phases independently).
- Each phase gate = Adversarial-Verification (#3) panel (council members = independent refuting lenses, must be blind to each other) wrapped in an Evaluator-Optimizer (#9) convergence loop (fail → refine → re-judge until the bar is met).
- Validation-archetype routing = Classify-And-Act (#1) (route the output to the matching validation kind; the CAF "validation-archetype routing" we agreed NOT to collapse).
- HITL checker = the Classify-And-Act escalating "unsure" branch (high-stakes / low-confidence → human, don't guess).
This is also why these four CAF pieces were on the do-NOT-collapse list (June-9 proposal): meta-council gates, validation-archetype routing, domain-rule extraction, HITL checkers — they ARE the gate's pattern structure.
New open questions raised today
- Cowork↔Code skills seam (verify with Anthropic). Docs don't definitively confirm that Skills published to the Team/Enterprise org settings (Cowork rail) ALSO auto-appear in Claude Code's skill directory. If not, engineers' Code skills need separate plugin distribution. → confirm with Anthropic support before assuming one upload covers both surfaces.
- External demo boundary = the single isolation chokepoint. Decision A puts all tenancy risk here. Needs an explicit airtight design: per-client bundle scoping at tailoring time + per-client gated serving on AWS. Highest-risk surface in the whole system.
- Contract shape (Contracts 0-6) — founder #5, parked for a live working session.
Still blocked on
- CAF repo not on this machine. Can't draw the real ERD, the Contracts 0-6 schemas, or the 106-skill→~15-20 collapse map without it. Everything above is conceptual/architecture-level; the concrete schema + skill-collapse work waits on the repo (founder owes path/clone).
Cross-references
- [[2026-06-14-caf-restructure-organizing-brief]] — vision, capability unbundling, the plugin/MCP verified addendum
- [[2026-06-09-caf-restructure-proposal]] — the original 4-move proposal + do-NOT-collapse list
- [[2026-06-04-agent-workflow-patterns-catalog]] — the pattern vocabulary used in the meta-council map