AFW is the authoring environment where work is developed. External systems (Gmail, Notion, Slack, GitHub) are delivery channels where finished work is dispatched.
This is unidirectional flow: AFW → External. The external artifact is a receipt of what was delivered, not the source of truth.
┌─────────────────────────────────────────────────────────────┐
│ AFW (Authoring Environment) │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Context │───▶│ Output │───▶│ Dispatch │─────┼──▶ External
│ │ (decisions,│ │ (iterate, │ │ (send, │ │ (Gmail,
│ │ constraints)│ │ version) │ │ publish) │ │ Notion...)
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ ▲ │ │ │
│ └──────────────────┴───────────────────┘ │
│ (all linked, versioned via events) │
└─────────────────────────────────────────────────────────────┘
1. Provenance stays intact The drafts, iterations, feedback, and decisions that shaped an output all live in AFW, attached to the output. External systems just have the final artifact.
2. No sync problem Unidirectional dispatch avoids bidirectional sync complexity. The email in Gmail doesn't need to "sync back" - it's a dispatched artifact, immutable.
3. Agent context is maximized When you start in AFW, the agent has full context - linked decisions, constraints, related records, past attempts. Starting in Gmail means re-explaining everything.
4. External edits are intentional forks If someone modifies the Google Doc after publishing, that's a branch. The AFW version remains what you produced with provenance.
This pattern reveals that "persistent memory" and "visible provenance" are the same thing from different perspectives:
| Perspective | What They See |
|---|---|
| Agent | Persistent memory - "I have context to work with" |
| Human | Visible provenance - "I can see how this evolved and why" |
The authoring environment is where these converge.
The event-sourced architecture already provides implicit version control. Every change is an event; any point in time can be reconstructed.
Meaningful events serve as implicit checkpoints:
output.created → first draftoutput.updated → new iterationoutput.dispatched → final/sent versionExplicit version tagging can wait. If semantic checkpoints become needed ("v1 release", "post-client-feedback"), they can be layered on later. Not core.
For work that benefits from provenance:
External tools are for consumption/delivery, not authoring.
Not just blobs attached to records, but:
| Output Type | Dispatch Channel |
|---|---|
| Gmail API / client handoff | |
| Document | Notion, Google Docs |
| Message | Slack |
| Code/PR | GitHub (already exists via Git) |
Input capture: Reactive work (responding to received email, Slack message) starts externally. Options:
Quick actions: Not everything needs full provenance. Need heuristics or user choice for what goes through AFW vs. direct.
Synthesized from exploration of "outputs must live in AFW" implication of the AFW Collapse thesis. Developed through analysis of email drafting as canonical example of the pattern.
AFW is the authoring environment where work is developed. External systems (Gmail, Notion, Slack, GitHub) are delivery channels where finished work is dispatched.
This is unidirectional flow: AFW → External. The external artifact is a receipt of what was delivered, not the source of truth.
┌─────────────────────────────────────────────────────────────┐
│ AFW (Authoring Environment) │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Context │───▶│ Output │───▶│ Dispatch │─────┼──▶ External
│ │ (decisions,│ │ (iterate, │ │ (send, │ │ (Gmail,
│ │ constraints)│ │ version) │ │ publish) │ │ Notion...)
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ ▲ │ │ │
│ └──────────────────┴───────────────────┘ │
│ (all linked, versioned via events) │
└─────────────────────────────────────────────────────────────┘
1. Provenance stays intact The drafts, iterations, feedback, and decisions that shaped an output all live in AFW, attached to the output. External systems just have the final artifact.
2. No sync problem Unidirectional dispatch avoids bidirectional sync complexity. The email in Gmail doesn't need to "sync back" - it's a dispatched artifact, immutable.
3. Agent context is maximized When you start in AFW, the agent has full context - linked decisions, constraints, related records, past attempts. Starting in Gmail means re-explaining everything.
4. External edits are intentional forks If someone modifies the Google Doc after publishing, that's a branch. The AFW version remains what you produced with provenance.
This pattern reveals that "persistent memory" and "visible provenance" are the same thing from different perspectives:
| Perspective | What They See |
|---|---|
| Agent | Persistent memory - "I have context to work with" |
| Human | Visible provenance - "I can see how this evolved and why" |
The authoring environment is where these converge.
The event-sourced architecture already provides implicit version control. Every change is an event; any point in time can be reconstructed.
Meaningful events serve as implicit checkpoints:
output.created → first draftoutput.updated → new iterationoutput.dispatched → final/sent versionExplicit version tagging can wait. If semantic checkpoints become needed ("v1 release", "post-client-feedback"), they can be layered on later. Not core.
For work that benefits from provenance:
External tools are for consumption/delivery, not authoring.
Not just blobs attached to records, but:
| Output Type | Dispatch Channel |
|---|---|
| Gmail API / client handoff | |
| Document | Notion, Google Docs |
| Message | Slack |
| Code/PR | GitHub (already exists via Git) |
Input capture: Reactive work (responding to received email, Slack message) starts externally. Options:
Quick actions: Not everything needs full provenance. Need heuristics or user choice for what goes through AFW vs. direct.
Synthesized from exploration of "outputs must live in AFW" implication of the AFW Collapse thesis. Developed through analysis of email drafting as canonical example of the pattern.