fix: various tweaks

docs/v2/documentation/core-concepts/architecture.mdx

@@ -71,7 +71,7 @@ TODO: devs tell me if this section is legit or not pls
 
 At a high level, Honcho has three main components that work together.
 
-The API layer is your primary interface--a REST API for managing workspaces, peers, sessions, and messages, plus specialized endpoints for querying representations. The chat endpoint (`/peers/{peer_id}/chat`) gives you theory-of-mind informed responses about a peer, and the get_context endpoint (`/sessions/{session_id}/context`) retrieves relevant context for generating agent responses. Authentication uses JWTs that can be scoped to workspace, peer, or session level for fine-grained access control.
+The API layer is your primary interface--a REST API for managing workspaces, peers, sessions, and messages, plus specialized endpoints for querying representations. The chat endpoint (`/peers/{peer_id}/chat`) gives you reasoning-informed responses about a peer, and the get_context endpoint (`/sessions/{session_id}/context`) retrieves relevant context for generating agent responses. Authentication uses JWTs that can be scoped to workspace, peer, or session level for fine-grained access control.
 
 Storage runs on PostgreSQL with pgvector for semantic search. All the structured data--workspaces, peers, sessions, messages--lives in relational tables, while reasoning outputs are stored as vectors in internal collections for similarity search. Token counts are tracked automatically for usage monitoring, and JSONB metadata fields let you extend primitives with custom data.
 
@@ -83,7 +83,7 @@ Understanding how data moves through Honcho helps clarify the architecture.
 
 When you create messages, they're immediately written to PostgreSQL and reasoning tasks are added to background queues. Background workers then generate logic, summaries, and new insights to improve representations. These conclusions and insights get stored in vector collections for retrieval. This async approach ensures fast writes while still providing rich reasoning capabilities.
 
-When you need context from Honcho, you query through the chat endpoint or get_context endpoint. Honcho retrieves relevant observations and conclusions from vector storage along with recent messages, then assembles everything into coherent context ready to inject into agent prompts.
+When you need context from Honcho, you query through the "Chat" endpoint or "Get Context" endpoint. Honcho retrieves relevant observations and conclusions from vector storage along with recent messages, then assembles everything into coherent context ready to inject into agent prompts.
 
 ![Honcho Architecture](/images/architecture.png)
 

docs/v2/documentation/core-concepts/reasoning.mdx

@@ -52,7 +52,7 @@ Here's an example of the data structure the reasoning models generate:
 }
 ```
 
-The reasoning models output their "thinking" followed by things that were explicitly stated, which serve as premises to scaffold deductive conclusions. It's on top of this reasoning foundation that further reasoning is scaffolded. Currently that includes peer cards (personality summaries and psychological profiles), duplicate checking (identifying redundant or contradictory information), induction (pattern recognition across multiple messages), and abduction (inferring the simplest explanations for observed behavior).
+The reasoning models output their "thinking" followed by things that were explicitly stated, which serve as premises to scaffold deductive conclusions. It's on top of this reasoning foundation that further reasoning is scaffolded. Currently that includes peer cards (key biographical information about the peer), duplicate checking (identifying redundant or contradictory information), induction (pattern recognition across multiple messages), and abduction (inferring the simplest explanations for observed behavior).
 
 The reasoning that Honcho does is something we're constantly iterating and improving on. Our goal is simple--provide the richest, most relevant context in the fastest, cheapest way possible in order to simulate statefulness in whatever setting you need.
 

docs/v2/documentation/features/advanced/configuration.mdx

@@ -395,4 +395,4 @@ import { Honcho } from "@honcho-ai/sdk";
 
 <Note>
 Message configuration only supports `deriver` and `peer_card` settings. Summary and dream configurations are session/workspace-level only.
-</Note>
+</Note>

docs/v2/documentation/features/chat.mdx

@@ -1,15 +1,15 @@
 ---
-title: "Dialectic Endpoint"
+title: "Chat Endpoint"
 description: "An endpoint for reasoning about your users"
-sidebarTitle: "Dialectic Endpoint"
+sidebarTitle: "Chat Endpoint"
 icon: "message-question"
 ---
 
-The Dialectic endpoint (`peer.chat()`) is the natural language interface to Honcho's reasoning. Instead of manually retrieving facts or observations, your LLM can ask questions and get synthesized answers based on all the reasoning Honcho has done about a peer. Think of it as agent-to-agent communication.
+The Chat endpoint (`peer.chat()`) is the natural language interface to Honcho's reasoning. Instead of manually retrieving observations or conclusions, your LLM can ask questions and get synthesized answers based on all the reasoning Honcho has done about a peer. Think of it as agent-to-agent communication.
 
 ## How It Works
 
-Honcho builds a *representation*(TODO: link to concept page) for each peer--a collection of conclusions drawn from continuous reasoning over context. The most flexible way to query representations is through the `chat()` method. Some examples:
+Honcho builds a [*representation*](/v2/documentation/core-concepts/representation)for each peer--a collection of conclusions drawn from continuous reasoning over context. The most flexible way to query representations is through the `chat()` method. Some examples:
 
 - "What is the user's preferred communication style?"
 - "Has the user mentioned any dietary restrictions?"

docs/v2/documentation/features/get-context.mdx

@@ -648,4 +648,4 @@ The `get_context()` method is essential for integrating Honcho sessions with LLM
 - Manage token limits and summaries
 - Handle multi-turn conversations
 
-You can build sophisticated AI applications that maintain conversation history and context across interactions while integrating seamlessly with popular LLM providers.
+You can build sophisticated AI applications that maintain conversation history and context across interactions while integrating seamlessly with popular LLM providers.

docs/v2/documentation/introduction/overview.mdx

@@ -6,13 +6,22 @@ sidebarTitle: "Overview"
 
 Honcho is an open source memory library with a managed service for building stateful agents. Use it with any model, framework, or architecture. You can represent any kind of entity as a stateful agent--users, AIs, groups of users, and more. Using Honcho as your memory system will earn your agents higher retention, more trust, and help you build data moats to out-compete incumbents.
 
+<CardGroup cols={2}>
+  <Card title="Get an API Key" icon="key" href="https://app.honcho.dev">
+    Sign up and start building with Honcho
+  </Card>
+  <Card title="Quickstart" icon="rocket" href="/v2/documentation/introduction/quickstart">
+    Build your first stateful agent in minutes
+  </Card>
+</CardGroup>
+
 <Note>
 Honcho is a memory system that reasons. Read more on the approach [here](https://blog.plasticlabs.ai/blog/Memory-as-Reasoning).
 </Note>
 
 ## What Can I Use Honcho For?
 
-Honcho streamlines the agent building process by offering elegant, flexible primitives for managing context. It also reasons over that context to give developers access to far richer insights only accessible through formal logical reasoning. Take the following scenario:
+Honcho streamlines the agent building process by offering elegant, flexible primitives for managing context. It also reasons over that context to give developers access to far richer insights only accessible through reasoning. Take the following scenario:
 
 - You find a use case for LLMs that you want to build an application or agent around
 - It performs well but fails to retain state on the task, customers, or itself over time
@@ -30,11 +39,11 @@ All the while usage dwindles, customers churn, and motivation to solve the probl
 Honcho has four core primitives that work together:
 
 - **Workspaces** - Top-level containers that isolate different applications or environments
-- **Peers** - Any entity that persists over time (users, agents, or any identity)
+- **Peers** - Any entity that persists over time (users, agents, objects, and more)
 - **Sessions** - Interaction threads between peers with temporal boundaries
-- **Messages** - Units of data that trigger reasoning and build peer [representations](/v2/documentation/core-concepts/representation)
+- **Messages** - Units of interaction that trigger reasoning
 
-When you write messages to Honcho, they're stored and processed in the background. Custom reasoning models perform formal logical reasoning (deduction, induction, abduction) to generate insights about each peer. These insights--observations, conclusions, summaries--are stored as peer representations that you can query to provide rich context for your agents.
+When you write messages to Honcho, they're stored and processed in the background. Custom reasoning models perform formal logical [*reasoning*](/v2/documentation/core-concepts/reasoning) (deduction, induction, abduction) to generate insights about each peer. These insights--observations, conclusions, summaries--are stored as peer [*representations*](/v2/documentation/core-concepts/representation) that you can query to provide rich context for your agents.
 
 ![Honcho Architecture](/images/architecture.png)
 
@@ -48,9 +57,9 @@ Honcho uses formal logic to generate new insights by combining premises. This re
 
 ## Get Started
 
-Honcho gives you maximum control over your agent's memory. The data model is flexible and composable, the reasoning layer is powerful yet cost-effective, and everything is built to give developers control over token usage, latency, and personalization depth.
+Honcho gives you maximum control over your agent's context and memory. The data model is flexible and composable, the reasoning backend is powerful yet cost-effective, and everything is built to give developers control over token usage, latency, and personalization depth.
 
-We're just scratching the surface here. Dive into the quickstart to see Honcho in action, explore the architecture to understand how it all fits together, or jump straight to building.
+We're just scratching the surface. Dive into the quickstart to see Honcho in action, explore the architecture to understand how it all fits together, or jump straight to building.
 
 Welcome to Honcho. We're excited to have you at the frontier of AI with us 🫡.
 

docs/v2/documentation/introduction/quickstart.mdx

@@ -236,7 +236,7 @@ The response will look something like this:
 
 > User is a personal finance app developer building a personalized finance assistant that's generating real demand (friends are already asking when they can pay). They're notably thoughtful about product design, carefully considering the UX balance between making users feel "known" versus "surveilled" when their app proactively surfaces remembered context like savings goals and spending regrets. They're business-minded and working through unit economics early, exploring a $5/month subscription model with usage-based cost structure focused on insight generation frequency rather than data storage—though they wish they had more time to dedicate to the project.
 
-Honcho synthesizes the signal based on the conclusions it was able to come to on the backend. Not only does it capture the basics of the conversation, but it reasons about the user to come to further conclusions. It identifies the user as "notably thoughtful about product design", "business-minded" from the discussion of unit economics, and surfaces the signal that they desire to work on the project more.
+Honcho synthesizes signal by reasoning about the user to draw conclusions beyond what was explicitly stated. It identifies the user as "notably thoughtful about product design", "business-minded" from the discussion of unit economics, and surfaces the signal that they desire to work on the project more.
 
 This is rich personal context for domain-specific agents to do what they want with.
 - A life coach agent might see "they wish they had more time to dedicate to the project" and "friends are already asking when they can pay" and ask "have you thought about what it would take to go full-time?"

docs/v2/documentation/reference/sdk.mdx

@@ -949,4 +949,4 @@ for await (const peer of await honcho.getPeers()) {
   // Process one peer at a time without loading all into memory
 }
 ```
-</CodeGroup>
+</CodeGroup>

docs/v2/documentation/scratch/working-rep.mdx

@@ -344,4 +344,4 @@ Working representations provide fast access to cached psychological models that
 - Handle cases where representations aren't available
 - Combine cached and fresh analysis appropriately
 
-You can build efficient applications that leverage Honcho's continuous learning about peer knowledge and mental states without the latency of real-time generation.
+You can build efficient applications that leverage Honcho's continuous learning about peer knowledge and mental states without the latency of real-time generation.

docs/v2/guides/storing-data.mdx

@@ -58,4 +58,4 @@ In this case you can simply
 - Make a `Peer` for the AI
 
 Then you can make a `Session` for each thread of conversation and save
-`Messages` from the user and assistant in each turn of conversation
+`Messages` from the user and assistant in each turn of conversation