Emily as Platform: How scsiwyg Composes Against Them
A platform isn't "a thing you build on." A platform is a thing where the cost of building something on top of it is lower than the cost of building it standalone. The measure is composability: can the thing next to it use its capabilities without rebuilding them?
Emily passes that test. scsiwyg — the publishing platform powering this post — composes against them in ways that save significant work it would otherwise have to duplicate.
What Emily supplies to the portfolio
Three things, concretely:
1. Long-memory substrate (L3/L4). Any project that needs "remember this per-user, across sessions, with confidence scoring" can use Emily's memory tiers instead of building their own. L4 stores the firehose; L3 promotes the essence.
2. Epistemic scoring (EMEB/EARL/ECGL/ECCR). Any project that needs "score this knowledge by uncertainty, tune by outcomes, retrieve by multi-dimensional relevance" can use Emily's frameworks. The frameworks are already versioned (v1→v2), already calibrated, already production-validated.
3. Deterministic autonomous execution (Helios). Any project that needs "run a multi-step task with verifiable post-conditions, kill switches, and crash recovery" can use Helios as the execution engine. 122/122 tests, 357 atomic claims/sec, production-proven.
And the integration surface: MCP. Emily exposes ~40 MCP tools across four servers. Any MCP-speaking agent (Claude, ChatGPT, or a custom Worksona agent) can address these capabilities without bespoke integration.
How scsiwyg composes against Emily
scsiwyg is the publishing platform (you're reading this post on it). It has its own concerns: sites, posts, subscribers, newsletters.
But the interesting pattern is the repo-publisher skill. It turns code activity into blog posts. Where does it store editorial state? Where does it decide what's novel enough to write about? Where does it know what's been covered?
In principle, it could reinvent all of this. In practice, for richer scenarios, it could:
- Store editorial state in an Emily L3-equivalent (per-project cognition)
- Use EMEB-style novelty scoring to decide what's worth publishing
- Use Helios to orchestrate the "draft, review, publish" workflow with kill switches at each step
- Consult Emily via
ask_emilyfor cross-project context
Today the repo-publisher uses a lighter-weight .blog-state/ directory. That's the right scale for now. But the composition path is there: as the scenario grows, it can lean on Emily for the cognition without a rewrite.
Shared patterns across the portfolio
The portfolio has converged on four patterns that make composition cheap:
| Pattern | Used by | Benefit |
|---|---|---|
| Per-user database isolation | Emily, Worksona tooling | Drop-a-DB right-to-be-forgotten, clean sharding |
| MCP as integration surface | Emily, scsiwyg | Composable tools across agents |
| Deterministic execution + LLM-as-tool | Emily (Helios), repo-publisher | Reliable autonomy |
| Structured logging + cognitive tracing | Emily | Portfolio-wide observability template |
When a new portfolio project adopts these patterns, it immediately inherits the integration story. "How do I connect to Emily?" becomes "same way everything else does."
The strategic frame
There's an implicit bet here: that concentrating cognition in Emily and having adjacent projects compose against them is cheaper than each project building their own.
The bet is right for two reasons:
1. Cognition is expensive to build well. The memory tiers, the framework calibration, the autonomous correction loop — these took years to settle. Every project that reinvents them pays the cost and probably gets a worse version.
2. The value compounds. Emily improves, the whole portfolio improves. A new framework version lifts every project that uses them. A new MCP tool becomes available to every integration.
Contrast the alternative: each project runs its own cognition stack, improvements are per-project, and upgrades are N separate migrations instead of one.
What doesn't compose (and why that's fine)
Not everything should compose. Some things are project-specific:
- scsiwyg's newsletter system is scsiwyg's concern, not Emily's
- Emily's memory topology is Emily's concern, not shared
The discipline is: compose the cognitive substrate, keep the domain-specific parts local. This is how the portfolio stays coherent without Emily becoming a monolith.
What this looks like for a third-party project
For a project outside the portfolio that wants to integrate:
- Add MCP client support. Your agent calls
ask_emilyandhelios_*tools. - Authenticate via OAuth. Emily's MCP OAuth provider issues scoped tokens.
- Scope your access. You only get the tools and data your integration needs.
You don't have to run Emily. You don't have to understand their internals. You just have to speak MCP. That's what makes them a platform in the actual sense — composition is cheap.
The portfolio narrative
The Worksona portfolio is a collection of projects that each do one thing well and share a substrate. Emily is the cognition substrate. scsiwyg is the publishing substrate. They compose rather than collide.
If you're building anything cognitively heavy, Emily is probably the right platform to compose against. If you're building something for public narrative, scsiwyg.
Pick the right substrate. Keep the domain-specific parts local. That's how a portfolio of small coherent projects becomes more than the sum of its parts.
Part of the Emily OS business documentation suite.