Intent. Intelligence. Impact. / Creator Lab
Design lab · Build evidence pendingDay 1. The Creator Workbench
Discover → Plan. Crisis Cat explains the mission. Wicked Spooky converts that intent into a headless application design, one module at a time.
Crisis Cat's brief
The source pitch is preserved below as the product brief. Its statements describe Crisis Cat's vision, not a claim that this lab has built or deployed the product.
Read Crisis Cat's complete product brief
Crisis Cat: I built an AI social media team for a one person company with zero employees.
Crisis Cat: And today, I'm giving you the exact blueprint for free.
Crisis Cat: Let me show you.
Crisis Cat: It handles everything: research, content, posting, and reporting.
Crisis Cat: But nothing goes public until you sign off on it.
Crisis Cat: Module 1 Research.
Crisis Cat: Claude digs into your niche like a full time strategist would.
Crisis Cat: What's trending this week?
Crisis Cat: Which competitor post just blew up and what your audience keeps asking in the comments.
Crisis Cat: Then it pulls the top videos on your topic and lines up their hooks side by side.
Crisis Cat: What they said in the first three seconds and why it worked.
Crisis Cat: Module 2 Content.
Crisis Cat: All that research turns into a full week of content.
Crisis Cat: Short videos, carousels, captions, all in your voice.
Crisis Cat: Every video opens with a hook built on what's already working, but made for you, not copied from someone else.
Crisis Cat: And every post sits in an approval queue until you hit approve.
Crisis Cat: Module 3 Posting and Community.
Crisis Cat: Once you approve a post, it goes out on every platform at the right time.
Crisis Cat: Comments get replies, DMs get answered, and anyone who asks how much gets flagged as a lead instead of getting lost in your inbox.
Crisis Cat: And running the whole thing?
Crisis Cat: Claude code.
Crisis Cat: It tracks the money, not just the likes.
Crisis Cat: Which posts brought in new followers who clicked your link, and which clicks actually turned into paying customers.
Crisis Cat: Then every morning, it sends you a one-page summary.
Crisis Cat: One person, zero employees, a full social media team.
Crisis Cat: I think I can market this on social media; it will go viral, and thousands of new customers will sign up to use it.
Crisis Cat: But right now, I don't have any money, so I am hoping we can use free or very low-cost services that will auto-scale or convert easily to a paid tier the second (or near real time) it catches fire and goes viral.
Wicked Spooky's first design decision
“We kept your four outcomes: research, content, posting and community, and revenue reporting. We made Amplify the presentation and control layer. Jobs, approvals, subscriptions and receipts belong to a durable backend that continues when the browser closes. We also separated the tool that helps us build the system from the services that run it.”
Claude Code can assist development. The Creator Workbench was designed to produce quality inputs: source-grounded research, clear intent, brand voice, permissions, constraints, reusable prompt templates and versioned output schemas. These inputs belong to the workbench and travel through provider adapters. The application is model agnostic: Claude is one option, and an evaluated local model or another cloud model can serve the same task contract. Model changes require quality, tool/schema compatibility, privacy, latency and cost checks; they do not change the human approval rule. Claude Code remains a development tool rather than the production scheduler or workflow engine. Amplify Gen 2 defines authentication, data, storage and functions; custom infrastructure adds the event-driven services. Cognito authenticates people. AppSync serves tenant-authorized commands and queries. DynamoDB holds state. S3 holds assets and reports.
Boundary: This lesson specifies the future product. The existing WickedSpooky.ai Amplify application hosts these lesson pages only. No Creator runtime is installed by this lab.
The user journey
The owner chooses a brand and permitted channels, receives a researched plan, reviews draft versions, approves destinations and timing, and then receives publication receipts, leads and a daily brief. Revising a draft invalidates the earlier approval. Comments and DMs also become drafts requiring approval before sending.
flowchart TD
accTitle: Creator Workbench owner journey
accDescr: An owner connects permitted accounts, researches, reviews and approves immutable drafts, publishes, reviews community replies, and sees revenue in a daily brief.
A[Connect brand and permitted accounts] --> B[Choose topic and weekly goal]
B --> C[Receive source-linked research]
C --> D[Review original content drafts]
D --> E{Approve exact version?}
E -->|Revise| D
E -->|Approve| F[Select destinations and schedule]
F --> G[Headless publishing and receipts]
G --> H[Review comments, reply drafts and leads]
H --> I{Approve a reply or DM?}
I -->|Approve| J[Send through supported adapter]
I -->|Hold| K[Keep draft private]
J --> L[Read daily revenue and cost brief]
K --> L
G --> L
L --> B
If the diagram cannot load, open Mermaid source below.
Mermaid source
flowchart TD
accTitle: Creator Workbench owner journey
accDescr: An owner connects permitted accounts, researches, reviews and approves immutable drafts, publishes, reviews community replies, and sees revenue in a daily brief.
A[Connect brand and permitted accounts] --> B[Choose topic and weekly goal]
B --> C[Receive source-linked research]
C --> D[Review original content drafts]
D --> E{Approve exact version?}
E -->|Revise| D
E -->|Approve| F[Select destinations and schedule]
F --> G[Headless publishing and receipts]
G --> H[Review comments, reply drafts and leads]
H --> I{Approve a reply or DM?}
I -->|Approve| J[Send through supported adapter]
I -->|Hold| K[Keep draft private]
J --> L[Read daily revenue and cost brief]
K --> L
G --> L
L --> B
SAA alignment: tenant access and human authority exercise 1.1 Learn · Practice · Execute, 1.2 Learn · Practice · Execute, 1.3 Learn · Practice · Execute; the asynchronous journey exercises 2.1 Learn · Practice · Execute, 2.2 Learn · Practice · Execute; storage, compute, data access and ingestion exercise 3.1 Learn · Practice · Execute, 3.2 Learn · Practice · Execute, 3.3 Learn · Practice · Execute, 3.4 Learn · Practice · Execute, 3.5 Learn · Practice · Execute; bounded processing and transfer exercise 4.1 Learn · Practice · Execute, 4.2 Learn · Practice · Execute, 4.3 Learn · Practice · Execute, 4.4 Learn · Practice · Execute. Each module below ties the design to specific evidence.
Module 1. Research
Product outcome: A concise, source-linked picture of the niche: current topics, audience questions, competitor examples and the opening hooks of permitted video sources. Evidence informs original work; it is not permission to copy it.
| Design question | Selected behavior |
|---|---|
| Inputs | Brand voice, niche, time window, authorized platform data, uploaded references and licensed/public sources |
| Trigger | Owner request or weekly EventBridge Scheduler job |
| Processing | SQS buffers work; Lambda adapters normalize inputs; a bounded Step Functions workflow coordinates collection and synthesis |
| Local AI first | Local embeddings, transcript segmentation, deduplication and economical summarization; deterministic ranking when sufficient |
| Frontier escalation | Bounded Bedrock reasoning only when evaluated quality or complexity justifies the cost |
| Outputs | ResearchRun, source dates/URLs and confidence notes in DynamoDB; large transcripts/reference assets in private S3 |
| Failure behavior | Missing permission or stale source is reported; source outage retries within a limit; unsupported collection never silently becomes scraping |
“Trending” requires a defined source and observation window. “Top videos” requires a permitted ranking signal. Three-second hook comparison requires a transcript or media we may process. Where those inputs are unavailable, the UI shows the gap and accepts an upload rather than fabricating market evidence.
Acceptance experiment: Repeat the same collection event; verify one logical research result, retained source lineage, bounded retries and a measured cost. Feed contradictory or malicious source text; verify that it cannot authorize actions or access credentials. SAA tasks: 1.2 Learn · Practice · Execute, 1.3 Learn · Practice · Execute, 2.1 Learn · Practice · Execute, 2.2 Learn · Practice · Execute, 3.5 Learn · Practice · Execute, 4.2 Learn · Practice · Execute.
Module 2. Content
Product outcome: A week of original drafts in the owner's voice: scripts, hooks, captions and carousel plans. Short videos can begin with owner-supplied footage and scripts; generated video is an explicitly priced extension.
| Design question | Selected behavior |
|---|---|
| Inputs | Research evidence, approved brand profile, platform limits, calendar and included usage allowance |
| Preparation | Deterministic templates assemble prompts, constrain length, remove repeated context and attach source IDs |
| Local AI first | Small model drafts, caption variants, extraction and rubric checks; local transcription/rendering where permitted and practical |
| Cloud processing | Lambda validates structured output; queued container/Batch work handles long media tasks if required; Bedrock handles bounded premium reasoning |
| Storage | Immutable ContentVersion and private S3 object version/checksum; no large media blobs in database items |
| Review | AppSync exposes a tenant-scoped queue; approve/reject/revise are server-validated commands |
| Publication authority | Approval binds exact text, asset checksum/version, destinations, approver, schedule and expiry |
We chose a real state machine: DRAFT → IN_REVIEW → APPROVED → SCHEDULED → PUBLISHING → PUBLISHED, with rejected, cancelled, partial, failed and unknown-delivery states. Clients cannot directly set approved or published status. Approval and publication claiming use conditional transactions; content changes require new approval. Cancellation before the send claim prevents publication; after a provider accepts a send, cancellation is best effort.
Acceptance experiment: Race edit, approve and publish. Confirm that stale approval never authorizes a new content version and that the audit records the decision. Compare small-model drafts to a bounded premium baseline using the same rubric. SAA tasks: 1.1 Learn · Practice · Execute, 1.3 Learn · Practice · Execute, 2.2 Learn · Practice · Execute, 3.1 Learn · Practice · Execute, 3.2 Learn · Practice · Execute, 3.3 Learn · Practice · Execute, 4.1 Learn · Practice · Execute, 4.2 Learn · Practice · Execute, 4.3 Learn · Practice · Execute.
Module 3. Posting and community
Product outcome: Approved content reaches each supported destination at its selected time. Incoming interactions become reviewable replies and leads, with visible status instead of a forgotten inbox.
| Design question | Selected behavior |
|---|---|
| Scheduling | Approval writes durable outbox intent; a dispatcher creates a deterministic schedule; reconciliation repairs missing schedules |
| Publishing | Per-platform SQS queue and Lambda adapter check current approval, entitlement, rate budget and capability before sending |
| Credentials | Scoped OAuth tokens in Secrets Manager, protected by appropriate KMS policy; no token in prompts or browser bundles |
| Idempotency | Tenant/content-version/platform/schedule-version key, conditional lease, provider key where supported, saved external receipt |
| Ambiguous send | Timeout after submission enters UNKNOWN_DELIVERY; reconcile before retrying to avoid duplicate public posts |
| Community intake | Signed HTTPS webhook, replay checks, durable enqueue, normalized CommunityItem and lead intent |
| Local AI first | Rule-based “how much” detection; small-model classification and reply drafting; human approval before external reply/DM |
| Recovery | Bounded jittered retries, provider-rate token bucket, circuit breaker and DLQ; successful destinations are not replayed with failed ones |
“Every platform” means an extensible adapter architecture, not identical features or unrestricted API access. Each advertised channel must have a verified contract for account type, permissions, content/media, scheduling, comments, DMs, rate limits, receipts and app-review status. Unsupported actions remain visibly unsupported. AI does not bypass an API limitation.
Reference adapter families: Meta / Instagram, Facebook Pages, YouTube, TikTok, LinkedIn, and X. These are integration references; actual access and approved use cases are prerequisites to prove before enabling the corresponding adapter.
Acceptance experiment: Inject 429, revoked OAuth, partial multi-channel success and a timeout after provider acceptance. Verify bounded spend, no blind duplicate send, useful error status and narrow DLQ redrive. SAA tasks: 1.2 Learn · Practice · Execute, 1.3 Learn · Practice · Execute, 2.1 Learn · Practice · Execute, 2.2 Learn · Practice · Execute, 3.2 Learn · Practice · Execute, 3.5 Learn · Practice · Execute, 4.2 Learn · Practice · Execute, 4.4 Learn · Practice · Execute.
Module 4. Attribution and the daily brief
Product outcome: Explain which posts led to tracked clicks and verified purchases, then produce a one-page morning brief. Likes are supporting signals; revenue and cost drive commercial decisions.
Campaign IDs and UTM metadata connect PublishReceipt to Click and verified Conversion records. Signed commerce webhooks contribute payment/refund facts; repeated or out-of-order events are reconciled. We label last-click attribution and tracking gaps rather than claim causal proof that a follower became a customer. Reports distinguish customer sales from the subscription revenue that funds our own runtime.
Scheduler starts daily aggregation in the tenant's timezone. Lambda computes totals deterministically from compact records; S3 holds the report; a small model may explain the numbers. Bedrock is optional for narrative quality, never required to add revenue correctly. The brief includes approvals due, publications, failed/unknown deliveries, audience signals, leads, attributable revenue/refunds, costs and uncertainty. Delivery begins in the control surface; email/messaging is a separate verified, metered integration.
Acceptance experiment: Replay a conversion and refund in different orders; verify stable totals. Test a timezone/DST boundary and a failed narration step; the factual brief must still be available. SAA tasks: 1.3 Learn · Practice · Execute, 2.1 Learn · Practice · Execute, 2.2 Learn · Practice · Execute, 3.3 Learn · Practice · Execute, 3.5 Learn · Practice · Execute, 4.3 Learn · Practice · Execute.
The local-focused AI agent
We chose an agent with bounded tools, not a model with broad AWS credentials. A router first tries deterministic processing, then a task-appropriate small model, then bounded Bedrock escalation. Job and model provenance are recorded. Quality failures may escalate or return for review; a model's self-reported confidence is not the gate.
flowchart TD
accTitle: Bounded local-first AI routing
accDescr: Durable AWS jobs try deterministic processing and a leased small-model worker, then use budgeted cloud inference when quality or availability requires it. Every output remains a draft.
A[Durable AWS job and cost reservation] --> B{Rules or templates sufficient?}
B -->|Yes| C[Deterministic result]
B -->|No| D[Lease job to scoped small-model worker]
D --> E[Training: local hardware / Paid: tested AWS worker]
E --> F{Available and passes task rubric?}
F -->|Yes| G[Validated draft and usage record]
F -->|No| H{Cloud fallback budget available?}
H -->|Yes| I[Bounded Bedrock inference]
H -->|No| J[Requeue or return for review]
C --> G
I --> G
G --> K[Human approval before any external send]
If the diagram cannot load, open Mermaid source below.
Mermaid source
flowchart TD
accTitle: Bounded local-first AI routing
accDescr: Durable AWS jobs try deterministic processing and a leased small-model worker, then use budgeted cloud inference when quality or availability requires it. Every output remains a draft.
A[Durable AWS job and cost reservation] --> B{Rules or templates sufficient?}
B -->|Yes| C[Deterministic result]
B -->|No| D[Lease job to scoped small-model worker]
D --> E[Training: local hardware / Paid: tested AWS worker]
E --> F{Available and passes task rubric?}
F -->|Yes| G[Validated draft and usage record]
F -->|No| H{Cloud fallback budget available?}
H -->|Yes| I[Bounded Bedrock inference]
H -->|No| J[Requeue or return for review]
C --> G
I --> G
G --> K[Human approval before any external send]
| Execution mode | How it fits | Reliability and cost boundary |
|---|---|---|
| Training workstation | Existing CPU/GPU runs a licensed small model and local processing; an agent polls only its scoped job queue using short-lived credentials | No public inbound inference port; lease/heartbeat, private asset access, local data deletion and cost of electricity/hardware documented |
| AWS-hosted small model | Same versioned inference contract runs in a queued container/instance worker or a suitable managed inference service | Paid compute, model loading and storage included; no assumption that GPU inference fits Lambda or a free allowance |
| Bedrock fallback | Offline worker, failed quality rubric or paid premium task routes through the cloud model adapter | Deadline plus explicit fallback budget; neither silent frontier calls nor indefinite workstation dependency |
A local agent can lower frontier-model usage without making inference free. Long model startup, GPU memory, throughput and licensing must be benchmarked. The workstation is optional: headless AWS scheduling, durable state and approval remain authoritative. Before commercial service, we prove a cloud path while the workstation is powered off. Cost and quality decide whether self-hosting actually beats economical managed inference.
Subscription plumbing belongs in the design now
The future product needs a verified billing provider before it advertises paid subscriptions. Hosted checkout keeps card entry out of our app. Signed billing events update server-owned entitlements; a success redirect does not grant access. Plan changes, payment failure, cancellation, refund and duplicate/out-of-order events have explicit policies. Stripe subscription webhooks provide one reference implementation; the design is provider-adaptable and fee assumptions must be replaced with actual terms.
The control surface checks availability and shows allowance/overage choices. The backend reserves worst-case cost and usage atomically before accepting an expensive job. Payment integration is part of the future specification, not a checkout feature on these lesson pages. SAA tasks: 1.2 Learn · Practice · Execute, 2.1 Learn · Practice · Execute, 2.2 Learn · Practice · Execute, 3.3 Learn · Practice · Execute, 4.2 Learn · Practice · Execute.
Day 1 design handoff
We finished the design session with module contracts, a user journey, version-bound approval, AI routing, integration boundaries and measurable experiments. We still need to verify Crisis Cat's assumed infrastructure, provider access, model economics and growth limits. Those are the focus of Day 2 — Wicked Spooky's architecture review.