docs: add an architecture reference page and embed the platform diagrams

src/content/docs/enterprise/enterprise-features/architecture-and-deployment.mdx

@@ -19,7 +19,9 @@ Warp's cloud agent infrastructure has four key components:
 3. **Execution** - Where the agent actually runs (Warp-hosted environment, your infrastructure, or your existing CI/orchestrator).
 4. **Visibility** - How the team monitors and intervenes ({VARS.DASHBOARD}, session sharing, APIs/SDKs).
 
-{/* TODO: Insert system architecture diagram once received from design team */}
+![Warp stack overview diagram showing clients, the Warp control plane, the data plane, Warp-hosted and customer-hosted execution planes, and external systems](../../../../assets/agent-platform/warp-stack-overview.png)
+
+The [stack overview](/platform/architecture/#stack-overview) reference describes each component in this diagram.
 
 ### High-level data flow
 
@@ -136,6 +138,8 @@ Understanding what data stays where is critical for security and compliance deci
 
 Consider the following when selecting a deployment model:
 
+![Deployment models diagram comparing Warp-hosted, managed self-hosted, and unmanaged self-hosted patterns by what runs on Warp versus customer infrastructure](../../../../assets/agent-platform/deployment-models.png)
+
 **Warp-hosted** is right if:
 * You want zero infrastructure management for agent execution.
 * Your security team is comfortable with SOC 2 Type II certified, ZDR-covered infrastructure.
@@ -152,6 +156,7 @@ Consider the following when selecting a deployment model:
 
 ## Related resources
 
+* [Architecture reference](/platform/architecture/) - Diagrams of the stack, the run lifecycle, self-hosted execution, and data boundaries
 * [Deployment Patterns](/platform/deployment-patterns/) - Detailed patterns for CLI-only, {VARS.WARP_AUTOMATION_PLATFORM}-hosted, and self-hosted setups
 * [Security overview](/enterprise/security-and-compliance/security-overview/) - Data handling, encryption, and compliance details
 * [Bring Your Own LLM](/enterprise/enterprise-features/bring-your-own-llm/) - Route inference through your own cloud infrastructure

src/content/docs/factories/how-factories-work.mdx

@@ -17,6 +17,19 @@ Deciding which repositories belong in this factory is a separate question. See [
 
 A **work item** is a single request the factory acts on, such as an issue, support request, pull request, or Factory MCP task. It keeps its identity from intake to handoff, however many agents contribute to it along the way.
 
+![Warp Factories system diagram showing work sources, automations, the foreman and stage agents, human handoff, the factory definition, platform execution, the factory dashboard, and the measure-and-improve loop](../../../assets/agent-platform/factories-work-item-flow.png)
+
+The diagram's components, from intake to improvement:
+
+* **Work sources** - Work items arrive from [Slack](/factories/integrations/slack/), [GitHub](/factories/integrations/github/), [GitLab](/factories/integrations/gitlab/), [Linear](/factories/integrations/linear/), or [Jira](/factories/integrations/jira/), from local coding agents through the [Factory MCP](/factories/factory-mcp/), or from direct runs and schedules.
+* **Automations** - [Automations](/factories/automations/) filter provider events and decide which agent handles them. Schedules fire them on a timer; direct requests go straight to the foreman.
+* **Foreman and stage agents** - The foreman holds one conversation per work item and dispatches the Triage, Spec, Implement, and Review agents as the work needs them. See [factory agents](/factories/factory-agents/) and the stages below.
+* **Human handoff** - The factory opens a pull request with evidence, updates the original work item, and you review and merge.
+* **Factory definition** - Version-controlled agents, automations, runners, and skills define the factory, either Warp-managed or in a GitHub repository your team owns. See [definitions as code](/factories/factory-as-code/).
+* **Execution** - Every stage runs as a cloud agent run on Warp-hosted or [self-hosted](/platform/self-hosting/) compute, with the workspace from the factory's repositories and each stage's configured model and [harness](/platform/harnesses/).
+* **Factory dashboard** - Metrics, work items by stage, and runs and costs. See the [factory dashboard](/factories/factory-dashboard/).
+* **Measure and improve** - [Scorers](/factories/measure-and-improve/) grade completed work, benchmarks compare configurations, and self-improvement turns repeat failures into follow-up pull requests for your review.
+
 ## How a work item moves through the factory
 
 The foreman coordinates every work item. It routes work between the factory's agents, passes each one the context it needs, and continues existing agent conversations instead of starting new ones. See [factory agents](/factories/factory-agents/) for what each agent does.

src/content/docs/factories/infrastructure-and-security.mdx

@@ -29,6 +29,10 @@ flowchart LR
 
 Self-hosting moves only the execution plane: with a managed self-hosted worker, repository checkouts, command execution, and the sandbox filesystem stay on machines you control, but content that enters prompts, results, transcripts, attachments, artifacts, or telemetry still flows through Warp and the providers you configure. See [deployment patterns](/platform/deployment-patterns/) and [self-hosting security and networking](/platform/self-hosting/security-and-networking/) for the broader data model.
 
+The diagram below maps those boundaries for self-hosted execution; factory runs follow the same data model. See the [data security and boundaries](/platform/architecture/#data-security-and-boundaries) reference for a description of each data class.
+
+![Self-hosted data security and boundaries diagram showing what stays in customer infrastructure, what Warp retains, and what transits Warp to model providers](../../../assets/agent-platform/data-security-boundaries.png)
+
 ## Runners
 
 A runner defines the compute a factory's agents work on: the operating system and architecture, the sandbox image, and the instance shape (vCPUs and memory). It's the infrastructure choice you make for a factory. The workspace itself — repositories, setup commands, and secrets — comes from the factory's [definition](/factories/factory-as-code/), and Warp keeps it in step for you. See the [runner reference](/platform/runners/) for the available compute options.