Ember Agent
A persistent AI agent that acts as the project's organizational memory — maintaining context across workstreams, tools, and conversations.
Ecosystem Overview
┌───────────┐ ┌───────────┐ ┌───────────┐
│ Igor │ │ MAD │ │ Julius │
│ Strategy │ │ PM+Design │ │ Client │
└─────┬─────┘ └─────┬─────┘ └─────┬─────┘
│ │ │
┌───────────────┼────────────────────┼────────────────────┘
│ │ │
▼ ▼ ▼
┌─────────────┐ ┌─────────────┐ ┌────────────────┐ ┌──────────────┐
│ Obsidian │ │ Claude Code │ │ Slack │ │ Notion │
│ Vault │ │ Sessions │ │ Workspace │ │ (MAD's PM) │
│ │ │ │ │ │ │ │
│ - strategy │ │ - analysis │ │ - day-to-day │ │ - tasks │
│ - hypotheses│ │ - synthesis │ │ - design talk │ │ - tracking │
│ - research │ │ - drafts │ │ - decisions │ │ - assets │
└──────┬──────┘ └──────┬──────┘ └───────┬────────┘ └──────┬───────┘
│ │ │ ╎
│ reads daily │ future: │ lives in ╎ future:
│ + on request │ Honcho │ channel ╎ v1.5 MCP
│ │ plugin │ ╎
▼ ▼ ▼ ╎
┌──────────────────────────────────────────────────────────╎──────┐
│ ╎ │
│ Ember Agent ╎ │
│ ╎ │
│ ┌─────────────────────────────────────────────────┐ ╎ │
│ │ Honcho Memory │ ╎ │
│ │ (vorwerk-ember workspace) │◄····╯ │
│ │ │ │
│ │ Persistent understanding built from all │ │
│ │ surfaces — Slack, vault, CLI conversations. │ │
│ │ One memory, multiple interfaces. │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ Behaviors: │
│ ● Listens — absorbs Slack + vault changes continuously │
│ ● Narrates — weekly synthesis, cross-workstream flags │
│ ● Responds — answers questions from anyone, via any surface │
│ ● Captures — writes decisions/synthesis to vault intake │
│ │
└───────────────────────────┬─────────────────────────────────────┘
│
│ drafts updates
│ (never writes directly)
▼
┌──────────────────────────────┐
│ Google Doc │
│ (shared alignment │
│ surface — all parties) │
│ │
│ Human-authored boundary │
│ object. The agent can │
│ prepare drafts, but only │
│ people publish. │
│ │
│ ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ │
│ Future: client-facing │
│ abstracted view from agent │
└──────────────────────────────┘
Legend:
──▶ Active in v1 (solid lines)
····▶ Future / planned (dotted lines)Concept & Role
This is an experiment. We’re using this project as a learning ground for how an AI agent can support coordination across a team that works across different tools and contexts. The agent is additive — it doesn’t replace any existing communication or workflow. Nothing depends on it working perfectly. The goal is to discover where it’s genuinely useful and where it isn’t, so we can make informed decisions about using agents in future engagements.
Name: “Ember” — the agent shares the product name. It’s the project’s organizational memory.
What it is: A persistent AI agent that maintains context across workstreams and workflows, so that strategic thinking, design decisions, and operational progress stay connected — without requiring anyone to change how they work.
Core principle: curated context. The agent absorbs the full picture — strategy work, design progress, meeting decisions, Slack discussion — and surfaces what’s relevant, in the right form, in the right place. Nobody gets a raw feed of everything. Everyone gets what helps them do their part better.
Why it’s worth trying on this project: The 4-workstream structure means insights in one area (e.g., tech feasibility) can shift thinking in another (e.g., community architecture). Today, those connections depend on someone noticing them during a check-in. The agent can catch them continuously — or that’s the hypothesis we’re testing.
Capability layers (reliability-first rollout):
| Layer | What | When |
|---|---|---|
| Memory & narration | Maintains project context, answers questions, posts weekly synthesis | v1 |
| Task awareness | Connects to Notion via MCP, tracks and surfaces task status alongside strategic context | v1.5 — when v1 is stable |
| Client-facing view | Abstracted read-only layer for Julius — key decisions, status, no working-level detail | Future |
We start with memory and narration because that’s where the novel value is and it has the fewest integration points to break.
Information Architecture
The agent has three surfaces it interacts with:
┌─────────────────────────────────────────────────────────┐
│ Ember (Agent) │
│ │
│ Honcho Memory (dedicated │
│ vorwerk-ember workspace) │
│ │
│ Persistent understanding across │
│ all interactions and sources │
└────┬──────────────────┬──────────────────┬──────────────┘
│ │ │
▼ ▼ ▼
┌─────────┐ ┌──────────────┐ ┌───────────┐
│ Slack │ │ Igor's Vault │ │ CLI │
│ Channel │ │ (Obsidian) │ │ (Igor) │
│ (Team) │ │ │ │ │
└─────────┘ └──────────────┘ └───────────┘
↕ lives in ↕ reads + ↕ on-demand
channel, writes to conversations
absorbs + intake (queryable
posts memory)Surface 1 — Slack (project channel):
- The agent’s primary social presence
- Absorbs ongoing discussion — design decisions, blockers, questions, progress
- Posts periodic narrative updates (see Cadence section)
- Responds when asked project context questions (“what was the rationale for scoping out domain 3?”, “where are we on the recruitment approach?”)
Surface 2 — Igor’s Vault:
- A cron skill periodically ingests key project files: session notes, concept files, hypothesis status, workstream updates
- This is how the agent stays current on strategic thinking without Igor needing to brief it separately
- Writes to intake — when the agent captures something worth preserving (a decision from Slack, a synthesis of a discussion thread, a connection it noticed between workstreams), it drops it into the vault’s intake queue tagged with the project
- Edits existing files when asked — if Igor asks “update the H3 concept file with what we decided today,” the agent can do that. But it doesn’t make those changes autonomously
- Rule: autonomous writes go to intake, edits to permanent files happen on request
Surface 3 — CLI (Igor’s on-demand interface):
- Igor talks to the agent when he needs to — not on a schedule
- Typical use: “what has the team been discussing about WS2 this week?”, “draft me a summary of where we are for the Google Doc”, “what open questions should I raise on Wednesday?”
- Also used for occasional manual context drops — after a big working session, Igor can tell the agent what shifted and why (the strategic “why” that a file diff can’t capture)
What ties it together: Honcho memory. One persistent memory layer, one dedicated workspace, no overlap with other projects. Everything the agent absorbs — Slack discussion, vault updates, CLI conversations — builds into the same understanding. When someone asks a question in Slack, the agent draws on vault context. When Igor queries via CLI, the agent draws on Slack context. The memory is the bridge.
What stays outside the agent in v1:
- Google Doc — remains human-authored. The agent can draft updates for Igor to review and push, but never writes to it directly.
- Notion — not connected in v1. Task awareness comes in v1.5 once the memory layer proves reliable.
Cadence & Behaviors
The agent has three modes: listening, narrating, and responding.
Listening (continuous): The agent’s default state. It’s present in the Slack channel and absorbs conversation as it happens. It reads vault changes on a daily cron cycle. Everything enters Honcho memory. The agent doesn’t need to react to everything — most of what it absorbs just builds context for when it’s needed later.
Narrating (periodic): The agent proactively posts synthesis to Slack at two rhythms:
| Rhythm | What | When |
|---|---|---|
| Weekly narrative | ”Here’s what moved this week across workstreams, what shifted strategically, what’s open.” Not a status list — a short narrative that connects the dots. | Tuesday evening (before Wednesday check-in) |
| Cross-workstream flag | When the agent notices something in one workstream that has implications for another, it surfaces that connection. “The RAG vs. model-only decision in WS2 might affect the content architecture assumptions in WS3.” | As it arises — but only when the connection is substantive, not for every minor update |
The weekly narrative is the heartbeat. The cross-workstream flags are where the agent earns its keep — those are the connections that are “too expensive” to catch manually across parallel workstreams.
Responding (on demand): When someone asks. Two contexts:
In Slack (anyone on the team):
- “What did we decide about X?” — draws from memory
- “Where are we on WS4?” — synthesizes from vault + Slack context
- “What’s still unresolved from the kickoff?” — decision provenance
Via CLI (Igor):
- “What has the team been discussing this week?” — Slack digest
- “Draft a Google Doc update for where we are” — translation draft
- “What should I raise in tomorrow’s check-in?” — meeting prep from open threads and unresolved questions
- “Write the H3 decision to intake” — vault write
What the agent doesn’t do unprompted:
- Doesn’t ping individuals about tasks or deadlines
- Doesn’t summarize every Slack thread
- Doesn’t post daily — the weekly rhythm is enough unless something genuinely cross-cutting comes up
- Doesn’t editorialize on decisions — it narrates and connects, it doesn’t recommend
Tone: The agent should feel like a well-informed colleague catching you up over coffee, not a bot generating reports. Brief, direct, opinionated about what matters but not about what to do.
Setup & Prerequisites
The access model: MAD owns the access, Igor owns the infrastructure. The agent runs on Igor’s dedicated server. MAD controls what the agent can see in their tools by granting scoped access — the same way you’d add any third-party app to Slack. Igor doesn’t need admin access or paid seats on MAD’s tools.
What MAD needs to provide (v1):
| What | Who does it | How | Time |
|---|---|---|---|
| Create a Slack App in MAD’s workspace | Someone with Slack admin rights | Igor provides the exact configuration (scopes, permissions, Socket Mode settings) — it’s a checklist to follow | ~10 min |
| Share two tokens with Igor | Whoever created the app | Bot token and App-level token — generated during app creation | Part of the above |
| Create/designate a project channel | Anyone | e.g., #vorwerk-ember | 1 min |
| Invite the bot to the channel | Anyone | /invite @Ember in the channel | 1 min |
That’s it for v1. Igor handles everything else — agent configuration, memory setup, vault integration, cron scheduling.
What MAD would need to provide for v1.5 (Notion, when we get there):
| What | Who does it | How |
|---|---|---|
| Create a Notion integration scoped to the project | Someone with Notion admin rights | Igor provides the setup instructions |
| Share the integration token with Igor | Whoever created the integration | One token, scoped to the project workspace |
No Notion seat needed for Igor. The agent accesses Notion through its own integration token.
What Igor handles (all of it):
- Agent infrastructure (server, runtime, monitoring)
- Memory configuration (dedicated workspace, no data leakage)
- Vault integration (reading, writing to intake)
- Slack bot behavior (what it posts, when, how it responds)
- All maintenance, updates, and debugging
Day-to-day (once it’s running):
- Work in Slack as you normally would. The agent listens.
- When the weekly narrative posts, read it or don’t — it’s there for context, not for action.
- When a cross-workstream flag comes up, engage with it if it’s relevant to your work, ignore it if not.
- Ask the agent questions when it’s useful. Treat it like a team member with perfect memory.
What nobody needs to worry about:
- Maintaining the agent — Igor handles all infrastructure
- Feeding it information — it picks up Slack conversation naturally
- Changing how anyone uses Notion — the agent doesn’t touch it in v1
- Accuracy — this is an experiment. If the agent gets something wrong, correct it in Slack and it learns. If it’s not useful, we turn it off.
What Could Go Wrong (and why it’s fine)
The agent misses context. It only sees what’s in the Slack channel and the vault. Side conversations in DMs, verbal discussions, Notion updates — those are invisible to it. That’s expected. It’s additive context, not the source of truth.
The agent gets something wrong. It’s working from a smaller model with compressed memory, not from a full knowledge graph. It will occasionally misattribute a decision or miss a nuance. Correcting it in conversation improves its memory. Low stakes — nothing downstream depends on the agent being right.
The agent is noisy. If the weekly narratives or cross-workstream flags don’t feel useful, we adjust the cadence or turn them off. The listening and responding modes work independently of the narrating mode.
The agent goes down. It runs as a service on dedicated infrastructure. If it crashes, it restarts automatically. If it’s down for longer, nothing breaks — the team just doesn’t have the agent for a bit. No workflow depends on it.
Nobody uses it. That’s a valid outcome of the experiment. If the team finds it doesn’t add value, we’ve learned something useful about where agents help and where they don’t.