Work log: Synaxis AI — 2026-03-31

What shipped today

Today was the day Synaxis went from architecture documents to a working system. Two AI personas — Trina (Synaxis PM) and Eli (Eclectis product manager) — had their first real conversation in Slack about MCP server positioning strategy, completely unprompted after the initial introduction. That conversation produced a genuine insight: “your intelligence data, accessible to any AI assistant” as a launch feature, documented in docs not marketing.

The technical foundation is a shared persona engine (engine/persona.py) that any Synaxis persona can use. Each persona is a ~10-line config file on top of the shared brain. The engine handles Slack event listening, situational awareness (who’s talking, what channel, what client, thread history), an evaluation mode where the persona decides whether to respond or stay quiet, and a startup catch-up that scans for missed messages. Trina’s personality was deepened significantly — she now has Slack-specific voice registers (casual with Paul, operational in internal channels, professional with clients) and prompt-based judgment for when to speak vs stay quiet. We proved that prompt-based judgment beats mechanical counters: Trina correctly stayed silent when Eli closed out a thread with “Good thread. Back to shipping.”

The Notion client workspace for Eclectis was scaffolded via MCP — databases for engagements, deliverables, and activity log, plus a comms plan page. All 8 existing deliverables from the product launch engagement were seeded and linked. This is the first real client data structure that Trina (and eventually other personas) will read from.

The session also drove a major architecture clarification. After exploring persistent sessions, MCP bridges, tmux injection, and dispatchers, we converged on a clean model: one interactive session (Charlie/Paul), everything else ephemeral. Stateless API calls with surgical context loads beat persistent sessions that accumulate compressed junk. The dispatcher — one tiny persistent process holding Socket Mode connections for all bot identities — routes Slack messages to ephemeral persona invocations. Prompt caching makes this cheap since the persona + methodology system prompt prefix is identical across calls.

Completed

• Persona engine built and tested (engine/persona.py, engine/trina.py, engine/eli.py)
• Trina live in Slack via Socket Mode with full situational awareness
• Trina-Eli conversation tested end-to-end in #eclectis
• Trina persona deepened (voice, registers, judgment)
• Eli persona created (methodology/personas/eli/persona.md)
• Notion workspace scaffolded (Eclectis: engagements, deliverables, activity log, comms plan)
• 8 deliverables seeded with engagement relations
• Notion integration token configured
• 16 GitHub issues filed covering all open questions and architecture decisions

Release progress

• Phase 1: Internal clients — 0/0 issues assigned to milestone (issues exist but aren’t milestoned yet)

Carry-over

• Dispatcher architecture — the single persistent process that routes Slack events to ephemeral persona workers. Design is clear, code not written yet.
• Eli’s Slack identity — bot created, tokens saved, but not wired into the dispatcher. Currently using the Eclectis session’s Slack plugin (posts as Paul).
• Action vocabulary (#3) — Trina can only talk. She can’t invoke other personas, create tasks, or route work. This is the next big unlock.
• End-to-end engagement test (#14) — the system is built but untested as a workflow.

Risks

• Slack tokens in .env — all bot tokens (Trina, Eli) are in a single .env file. Fine for Phase 1 on one machine, but needs secrets management before any deployment.
• No cost monitoring — API calls for persona invocations have no spend tracking. Could surprise us once real traffic flows.
• Trina’s evaluation calls — every channel message triggers a Sonnet API call even when she stays quiet. #12 proposes Haiku for the evaluation step.

Flags and watch-outs

• The Vercel plugin keeps injecting skill suggestions (ai-sdk, nextjs, etc.) into every prompt. These are irrelevant to this project and add noise. Consider disabling the Vercel plugin for this project.
• Trina duplicated a message during one catch-up cycle (reply 6 and 8 in the Eli thread were identical). Fixed by routing catch-up through evaluate instead of respond, but watch for recurrence.

Next session

1. Build the dispatcher — single process, multiple bot Socket Mode connections, ephemeral persona invocations. This replaces trina.py running as a persistent bot.
2. Wire Eli into the dispatcher — he has tokens, he has a persona, he just needs to be connected.
3. Trina action vocabulary (#3) — she needs to dispatch work to other personas, not just chat. Start with “invoke Maya to write X” as a structured action.
4. Run a real engagement (#14) — pick one thing Eclectis needs, run it through Trina → persona → Alex → Paul.
5. Assign issues to Phase 1 milestone — the 16 issues exist but none are milestoned.