Ecosystem Evaluations
April 22, 2026 · View on GitHub
Every external project considered for absorption into EvanCore — and every one that was declined — is logged here. This log exists so the project's scope stays defensible.
The framework (5 dimensions)
When a candidate repo is proposed, it's evaluated against:
-
Fit — Which EvanCore line does this land on?
assembly(HarnessSpec / Assembler / validator)delivery(SpecStore / release / overlay / promote / upgrade / registry / signing / trust)observability(EventBus / exporter / OTel)open foundation(Role / Skill / Memory / Tool backend)runtime— off-scope by default (v1 strategic lock, 2026-04-21)
-
Gap reality — Is this a known gap, or a new scope?
- Known gaps: MCP hot-reload, B3 Phase C (CRL / cross-host revocation / registry self-signing), second Memory backend, B3 Phase A.2 (
_index.jsonper-spec current / retry jitter) - Anything else = new scope, requires explicit acknowledgment
- Known gaps: MCP hot-reload, B3 Phase C (CRL / cross-host revocation / registry self-signing), second Memory backend, B3 Phase A.2 (
-
Absorption form — pick one:
- (a) idea reference only (cheapest, most common)
- (b) vendor subset into EvanCore
- (c) optional dependency (pyproject.toml extras)
- (d) decline (off-fit / too costly / conflicts with invariants)
-
Cost side — license compat / activity / API stability / dependency footprint
-
Invariant conflict check — per-backend instance (no process-level singletons), harness/team atomic release unit,
assemble ≠ release, Tool reverse-lookup vs Role/Skill/Memoryscheme://forward-dispatch split,_async_*monkey-patch hook points, silent degradation semantics (MCP unreachable → 0 tools + warn, not crash)
Default bias: (a) or (d). (b) and (c) require a specific justification.
Evaluated candidates (2026-04-22 batch)
Eleven repos evaluated in one sitting, during the robust-phase kickoff.
Accepted as reference ideas
| Repo | Line | Verdict | Reason |
|---|---|---|---|
vectorize-io/hindsight | Memory (open foundation) | (a) idea reference, (c) candidate if/when second Memory gap activated | MIT, Python, v0.5.3. retain/recall/reflect three-op model + biomimetic structure + LongMemEval benchmark. Integration shortcut: Hindsight ships its own MCP server — can be consumed via EvanCore's existing mcp:// Tool backend with zero EvanCore changes (lands on Tool line, not Memory line). Won't push absorption until second-Memory gap is user-activated. |
| LLMWiki v2 (gist) | Memory (open foundation) — concept only | (a) idea reference | Conceptual blueprint (not code): memory consolidation tiers (working → episodic → semantic → procedural), confidence scoring, supersession tracking, retention decay. Useful primitives for a future second Memory backend. Copying verbatim would balloon scope into PKM territory — not doing that. |
Declined
Each of these declines for one of three reasons: off-fit (lands on runtime or outside any EvanCore line), wrong abstraction layer (solves a problem EvanCore doesn't own), or terminology collision (uses "spec" or "harness" to mean something incompatible).
| Repo | Category | Decline reason |
|---|---|---|
EvoAgentX/EvoAgentX | Agent framework | Runtime concern — off-fit with v1 scope lock. |
multica-ai/multica | Multi-agent orchestration | Runtime + orchestration — both off-fit. |
VectifyAI/PageIndex | Document indexing | Solves a different problem (retrieval over docs), doesn't intersect the lifecycle. |
safishamsi/graphify | Graph-based agent flow | Orchestration DAG primitive — wrong layer. |
alibaba/page-agent | Web-automation agent runtime | Pure runtime. |
thedotmack/claude-mem | Claude Code memory wrapper | Tool/UX wrapper, not a reusable backend. If users want it, they plug it in via their own environment — EvanCore doesn't need to know. |
shanraisshan/claude-code-best-practice | Practice collection | Documentation, not a component. No absorption shape. |
gsd-build/get-shit-done | Spec-driven coding workflow | Terminology collision warning: uses "spec" and "harness" to mean prompts for code generation, not agent configuration. Same words, different products. External messaging needs to pre-empt this confusion. |
snarktank/ralph | Agent orchestration loop | Runtime / orchestration — off-fit. |
Why the default is decline
EvanCore's v1 scope lock (2026-04-21) excludes runtime concerns. The robust phase explicitly does not proactively expand into runtime capabilities or pre-conditional gap items (MCP hot-reload, distribution Phase C).
Most repos that look "AI-adjacent" land on runtime or orchestration, which are already well-served by frameworks whose primary job is exactly that. Absorbing them would dilute EvanCore's one defensible position: the delivery layer between spec and running agent.
Declining a promising repo is not a rejection of the repo — it's a refusal to let EvanCore drift.
What would change a verdict
A future candidate gets a stronger look if it:
- Lands on an activated gap (second Memory backend, B3 Phase A.2, distribution Phase C, MCP hot-reload)
- Introduces a new lifecycle primitive that EvanCore's current assemble/release/promote/rollback/upgrade shape doesn't cover — and the primitive is general (not vendor-locked)
- Offers a signature / trust / revocation improvement that's strictly additive to the current Ed25519 + per-host trust + revocation v2 model
Anything else stays at (a) or (d).