# PRD: Public Website Launch

## Summary

ThinkWork needs a **single-page public website** for launch.

Not a full marketing maze.
Not a many-page corporate site.
Just one sharp landing page that does three jobs:

1. explain ThinkWork fast,
2. sharpen the category and competitive story,
3. send people to the two real next steps: **Docs** and **GitHub**.

The core launch message should be:

**ThinkWork makes agent infrastructure easy without handing the harness to a black-box vendor.**

That single page should emphasize two things especially hard:
- **Memory** as a portable, harness-owned context layer
- **Self-hosted infrastructure** inside the customer’s own AWS account

This PRD turns the earlier homepage direction into a concrete **single-page website launch brief**.

---

## Why this PRD exists

We already have:
- `.prds/public-homepage-messaging.md`
- `.prds/managed-agents-competitive-messaging.md`

Those are useful, but they were written as broader messaging inputs.

For launch, we need one simpler decision:

**What should the one public launch page say, show, and link to?**

This doc is that answer.
It should function as the single website brief for launch work.

---

## Problem

ThinkWork now has a stronger product story than the public surface communicates.

The strongest current truths are:
- ThinkWork is an **open harness for AI work**
- it deploys into the customer’s **own AWS account**
- **threads** are the system of record
- **memory** is the portable, harness-owned context layer
- **control** is part of the product, not an afterthought
- it is the answer to “agent infrastructure is hard” without requiring a hosted black-box runtime

But the public site still risks sounding like:
- a generic agent platform,
- a docs-heavy open source repo,
- or a fuzzy AWS-native AI toolkit.

That would waste the launch.

---

## Goals

- Launch a public website that makes ThinkWork feel sharp, modern, and differentiated.
- Lead with **ease + ownership**, not generic platform language.
- Make ThinkWork’s system model legible: threads, memory, agents, connectors, control.
- Tie the public story directly to the current product truth and docs architecture.
- Turn the Anthropic Managed Agents moment into a positioning advantage.
- Create a site structure that can support launch now and expand later without rewriting the story.

---

## Non-goals

- Do not launch with every future roadmap area as a first-class page.
- Do not build a bloated marketing site full of startup filler.
- Do not lead with pricing, enterprise forms, or category jargon.
- Do not turn the website into a copy of the docs site.
- Do not promise generalized autonomy magic.

---

## Core strategic message

### Primary positioning line

**ThinkWork makes agent infrastructure easy without handing the harness to a black-box vendor.**

### Supporting truths

- Five commands. One AWS account. Production-grade agent infrastructure.
- Threads run the work.
- Memory carries context forward.
- Control keeps the system safe.
- Connectors bring in external systems without becoming the product contract.
- You own the runtime boundary, the work record, and the memory contract.

### Category framing

ThinkWork should be framed as:

**Open infrastructure for AI work**

Not:
- generic “agent platform”
- pure workflow automation
- just another managed-agent runtime
- just RAG + tools + evals in a trench coat

---

## Audience

### Primary
- technical founders
- platform engineers
- internal AI/product teams
- AWS-native teams
- buyers who care about control, audit, and portability

### Secondary
- teams comparing ThinkWork to hosted managed-agent products
- teams deciding whether to build their own harness
- open source builders looking for a serious substrate

---

## Public site jobs

The launch website should answer these questions fast:

### 1. What is this?
A production-grade open harness for AI work.

### 2. Why should I care?
Because agent infrastructure is hard, and ThinkWork makes it easy without forcing you into a hosted black box.

### 3. Why is this different?
Because it combines:
- easy deployment,
- owned AWS boundary,
- thread-native work system,
- portable memory contract,
- and control surfaces that survive past the demo.

### 4. What should I do next?
- read docs,
- view GitHub,
- follow quick start,
- or talk to us if they need deeper help.

---

## Website narrative

The site should follow this sequence:

1. **Ease** — agent infrastructure is hard, but ThinkWork makes it easy.
2. **Ownership** — the easy path does not require giving up the harness.
3. **System model** — threads, memory, agents, connectors, control.
4. **Proof** — five-command deploy, AWS account boundary, open repo, docs.
5. **Activation** — quick start, docs, GitHub.

That order matters.

If we lead with architecture taxonomy, we lose.
If we lead with “open source” alone, we sound ideological.
If we lead with “control and governance” alone, we sound enterprise-brochure boring.

The winning move is:

**easy first, owned second, system truth third.**

---

## Single-page structure for launch

The launch site should be **one page** with strong sectioning, not a multipage marketing tree.

Purpose:
- explain ThinkWork in under ten seconds
- establish category and differentiation
- emphasize memory + self-hosted infrastructure
- push people to **Docs** and **GitHub**

Recommended section order:

## 1. Hero
- one hard headline
- one short supporting paragraph
- CTA to Docs
- CTA to GitHub

## 2. Proof strip
- five-command deploy
- runs in your AWS account
- open source core
- threads + memory + control built in

## 3. Why ThinkWork
- easy infrastructure
- owned deployment boundary
- portable memory contract

## 4. System model
- Threads
- Memory
- Agents
- Connectors
- Control

## 5. Memory + self-hosting wedge
This is where the site should hit the strongest differentiator:
- memory belongs to the harness, not a backend vendor
- the runtime lives in your AWS account
- the work record lives in your boundary
- control and audit stay with you

## 6. Quick start
- show the fast path
- prove this is not hand-wavy infrastructure marketing
- point to docs for full setup

## 7. Final CTA
- Read the docs
- View on GitHub

Important constraint:
- the website should **link out** to docs and GitHub for depth
- it should **not** try to duplicate full docs or architecture documentation inline

---

## Single-page requirements

## Hero

The hero must compress:
- ease,
- ownership,
- and product identity.

Recommended direction:

### Headline option A
**Open agent infrastructure, minus the infrastructure headache.**

### Headline option B
**Own the harness, not just the prompt.**

### Headline option C
**Agent infrastructure made easy, not opaque.**

### Supporting copy
ThinkWork gives you threads, memory, agents, connectors, and control inside your own AWS account, with a five-command path to a production-grade harness for AI work.

### Hero CTAs
- Read the docs
- View on GitHub

## Proof strip

Immediately under hero:
- Five-command deploy
- Runs in your AWS account
- Open source core
- Threads + Memory + Control built in

## Memory + infrastructure emphasis

The page should spend disproportionate energy on these two ideas:

### Memory
- memory is a harness-owned context layer
- memory is portable and inspectable
- memory should not be trapped behind one backend’s API

### Self-hosted infrastructure
- ThinkWork deploys into your AWS account
- no SaaS control plane
- your work system stays in your boundary
- your governance and audit stay in your boundary

## System model section

Show:

**Threads → Memory → Agents → Connectors**

With **Control** wrapping the whole system.

Keep this visual and compact.

## Quick start section

This is non-negotiable.
The site needs proof, not just claims.

Show the fast path.
Keep it real.
Then link to docs for the full setup.

---

## Messaging rules

## Phrases to use
- open harness
- own the harness
- your AWS account
- thread-native AI work
- portable memory contract
- easy agent infrastructure
- no SaaS control plane
- production-grade in five commands

## Phrases to avoid
- agent platform
- orchestration layer
- enterprise AI workflows
- AI employees
- autonomous coworkers
- knowledge module
- generic “build AI agents faster” fluff

## Tone
- sharp
- opinionated
- short sentences
- adult, not breathless
- technically credible
- not defensive

---

## Required alignment with docs

The public website and docs cannot tell different stories.

Current issue:
- the deployed Memory docs are still behind the new memory direction
- this is **not just** the `/concepts/knowledge/` overview page
- we likely need a broader pass across the full memory docs cluster

The updated memory story should be:
- threads are the record of work
- memory is the harness-owned context layer
- ThinkWork exposes a stable memory contract above pluggable engines
- both Hindsight and AgentCore are supported adapters
- hosted ThinkWork defaults to Hindsight
- self-hosted/serverless-friendly users may choose AgentCore

This does **not** need to turn the docs into engine soup.
It does need to stop teaching the old story.

### Required docs alignment work
- update `docs/src/content/docs/concepts/knowledge.mdx`
- revisit the rest of the memory docs cluster, not just the overview page
- align `document-knowledge.mdx`
- align `memory.mdx`
- align `retrieval-and-context.mdx`
- align `knowledge-graph.mdx`
- align docs landing Memory card language
- align architecture wording
- keep “Memory” as the umbrella concept, not “Knowledge” in spirit, even if URL stability remains for now

---

## Launch content set

Minimum required launch surfaces:
- one landing page
- docs CTA
- GitHub CTA

Optional follow-on pages later if needed:
- comparison page: owned harness vs hosted managed agents
- deployment boundary / trust page
- lightweight FAQ

Not required for launch:
- pricing page
- full case studies
- polished enterprise conversion funnel
- roadmap microsite
- a multi-page marketing site

---

## Visual/content principles

- show product/system truth, not abstract stock-art metaphors
- diagrams should simplify, not perform complexity
- use threads/memory/control as recurring conceptual anchors
- every page should contain at least one concrete proof point
- copy should sound like the product knows what it is

---

## Success criteria

The public website is successful if a serious visitor quickly understands:
- ThinkWork is easy to deploy
- ThinkWork runs in their AWS account
- ThinkWork is not a hosted black-box runtime
- Threads are the work system
- Memory is portable and harness-owned
- ThinkWork is a real product, not just a repo

Secondary success signals:
- stronger docs clickthrough
- stronger GitHub conversion from homepage traffic
- less confusion about what ThinkWork actually is
- less collapse into generic “agent platform” comparisons

---

## Recommended next execution steps

1. tighten the landing page copy and sections using `.prds/public-homepage-messaging.md`
2. update the website build target to a single-page launch surface
3. revisit the full memory docs cluster so docs match the new memory story
4. align README/docs landing with the same messaging before public push
5. launch with strong links to Docs and GitHub, not extra page sprawl

---

## Bottom line

ThinkWork’s launch website should make one thing unmistakable:

**This is the easy path to serious agent infrastructure, without giving up ownership of the harness.**

That is the launch story.
That is the wedge.
And the site should be built to hammer it cleanly.
